Make the default settings easily discoverable again
Since !822 (merged), the default settings have been base64 encoded and packed into defaults.bin
instead of left as settings-default.cfg
. This is because the only legitimate time to edit the default settings is when shipping a new game with OpenMW, but no one's done that yet and lots of people were editing them anyway. Sometimes it was as a crutch for there being no proper support for a sensible workflow (in which case we should implement it properly) but usually, it was because people mistakenly thought that was the right settings file to edit.
To prevent this, we wanted a solution that made them impossible to edit (or think you'd edited) except in the one situation where it was supported (when we wanted it to be easy) while still keeping the defaults discoverable. The solution did a good job of the first two (particularly the think-you-should/have-edit(ed)-it case - people aren't going to jump into a base64-encoded file and think they're supposed to meddle), but hurt the last goal. This wasn't the end of the world as there are still a few ways to do it:
-
Look at the ReadTheDocs documentation. This is sometimes missing, though, and requires an internet connection.
-
Look at
settings-default.cfg
in the source repo. This requires more hunting and either an internet connection or an existing local clone. -
Unpack the file with a base64 decoder. This could be done in several ways:
- sh
base64 -d defaults.bin > settings-default.cfg
- PowerShell
[io.file]::WriteAllBytes("$pwd\settings-default.cfg", [Convert]::FromBase64String((Get-Content .\defaults.bin)))
- Any number of online base64-decoding tools that show up when googling base64 decode like https://www.base64decode.org/
This is still a pain if you're not used to command-line shells and don't want to open a browser.
- sh
In theory, there should be a way to display the contents of settings-default.cfg
/defaults.bin
that doesn't give the false impression it's okay/possible to edit them and is less of a pain. A good metric for doing so is the duck test (from duck typing) - if it looks like a duck and quacks like a duck, it's a duck.
Examples of looking like a replacement for settings-default.cfg
:
- Being a file with
settings
orconfiguration
or something like that in the name. - Having a configuration-like file extension, e.g.
.cfg
,.ini
,.yaml
,.json
,.txt
. I think.txt
is fair to include in this list as users are quite used to anything with a text editor as the default file handler can be a configuration file. Reddit and then the gaming press went bananas over a CSV file that shipped with Cyberpunk 2077 with some numbers they didn't think looked right and started recommending people change them, despite it not being a file the game ever loaded. - Suddenly appearing after it disappeared.
Examples of quacking like a replacement for settings-default.cfg
:
- Containing a list of human-readable settings.
- Being editable (as in you can open it, type stuff in, and save the changes).
- Actually affecting the engine's behaviour if it's edited, even if it's only sometimes.
Solutions suggested so far include:
-
Add a tab to the launcher called View Default Settings (or similar) that shows a
QTextEdit
with itsreadOnly
property set to false. This would be easy to view and would still allow copying and pasting without editing, but IMO is still a bit of a pain - I'd still just use the sh/PowerShell solution and use my regular editor.Maybe we could expand this into a textual settings editor that automatically makes all settings editable from the launcher - it could fairly easily list all settings and their default values just by reading the defaults file and highlight any that'd been changed in the user config with no need for manual GUI creation.
-
As well as having
defaults.bin
, also have a file that's got the same contents assettings-default.cfg
used to that doesn't actually get loaded and has a new name, new extension and/or lives in a subdirectory. This still looks and quacks like a duck as far as I'm concerned:- I think someone looking for where
settings-default.cfg
went while under the impression it's the only settings file (a completely reasonable thing to think asMorrowind.ini
was analogous to it in every way except you were actually supposed to edit it) is more likely to check in subdirectories of the installation root than inDocuments\My Games\OpenMW
- I think anything we do with file naming will continue looking like it might contain a settings file just as long as it looks like it contains settings documentation. The whole reason this issue report exists is that there's not much point having documentation if it's so obfuscated that no one can find it.
- If someone finds the file, it's literally got the same contents as
settings-default.cfg
, so they're going to think it's the replacement and start editing it and nothing can stop them.
These limitations mean there's still a chance people will try and do what they've always done, i.e. put user settings in the wrong file, and they'll continue not working, just like if they'd tried to enable full screen in
settings-default.cfg
. It'll stop some users from running into the problem, but we'll still have to ask anyone reporting any problem if they've made sure to edit the right file because someone might have, and that means it doesn't do much to help with the support burden. We've got enough users that if there's a probability that a user will do a thing, the law of large numbers dictates that some of them will do the thing.Something related to this idea might be viable, though. We could maybe process the file a bit into something obviously less editable, e.g.:
- an HTML document that looks just like
settings-default.cfg
if opened in a browser, but not so much if opened in a text editor. - A PDF, ESP or something like that that basically appears like a binary file unless opened in a reader, and for which readers are ubiquitous and editors are rare.
- I think someone looking for where
-
Keep
settings-default.cfg
but make it less obviously a file full of settings.- Having the don't edit me preamble between each setting was suggested in the past, but makes the version in source control a pain to edit and also means you have to scroll through crap when using it as documentation.
- Having a few tens of thousands of lines of whitespace (or maybe binary-looking nonsense in comments) at the top of the file would mean the bottom of the file was intact, so doesn't have the problems above, but has all the original problems if someone's brave enough to grab the scrollbar and drag down or press the End key twice.
-
Keep
settings-default.cfg
with just some text inside sayingsettings-default.cfg
is gone but settings can be changed in the right file, and you can read about what settings are available, but not change them in another file. This should hopefully intercept some people who'd otherwise find the other file and think it was editable, but probably won't catch anyone who genuinely can't/won't read as they'll just be unable to translate or totally ignore the new text just like they did with the old preamble. -
Ignore the problem - it's not that hard to copy and paste a shell snippet and there aren't that many people who actually used
settings-default.cfg
as documentation. This should only be considered the solution if we fail to come up with anything we can actually implement that's less hassle for users than opening a terminal and copying and pasting something into it. So far, I don't think we have managed to come up with anything easier, though. It only takes me twelve seconds.