RFC Do we even need a local/global openmw.cfg for a non-portable install

What the local/global openmw.cfg does

This is the openmw.cfg in the same directory as the openmw binary (if one exists), or the one in a system-wide directory like /etc/openmw if there isn't one next to the binary. This openmw.cfg can contain stuff specific to an individual OpenMW build, so needs to either be at a fixed relative path to the binary, or at a fixed absolute path and be managed by the system package manager.

By default, this file contains the following local or global. The only difference is that for the global variant, ${OPENMW_RESOURCE_FILES} is set by CMake, whereas for the local variant, it's just ./resources.

This breaks down into two categories:

• A long list of entries that should be overwritten by what the INI importer gets from Morrowind.ini.
• A few actual settings we expect to use.

The list of Morrowind.ini settings are there basically so that the Example Suite doesn't have a requirement on Morrowind.ini. There's a decent argument to be made that these shouldn't be here and should instead come from the OpenMW Template. How that would take shape is a little unclear, just like with many things about distributing the Example Suite. A bunch of these settings are potentially going to disappear over time anyway as they're more sensible as part of a content file, but that's a discussion for elsewhere.

The remaining few settings are as follows:

data-local="?userdata?data"
user-data="?userdata?"
config="?userconfig?"
resources=./resources
data=./resources/vfs-mw

data-local="?userdata?data" and user-data="?userdata?"

I'm not sure there's a particularly good reason not to set this default value in the engine. Other settings have sensible defaults set in the engine, e.g. encoding and random-seed.

resources=./resources

This is already set by default in the engine, so the config line is already redundant in the local openmw.cfg. The global openmw.cfg sets it to whatever CMake sets ${OPENMW_RESOURCE_FILES} to, so it possibly makes a difference for some platforms.

config="?userconfig?"

Unlike the above settings, this is a composing entry, so if you have a value from a lower-priority source, it'd get appended to instead of replaced (like we're all used to with data and content). We've got a couple of options here:

• just have this as a default that works in the default boost::program_options default way, i.e. if nothing else sets it, we use the default, but if something else does set it, we only use this value. This gets a little complicated to explain in the documentation as that would mean the defaults don't just count as a lower-priority config source, and there's the ambiguous case of if the ?userconfig?openmw.cfg has a config line whether it should retroactively be interpreted as meaning that we shouldn't load the config we're loading that gave us that instruction.
• for this one setting, make the default value work a little differently from how boost::program_options handles defaults by default, i.e. treat it like it had come from a low-priority config source, and just append any extra paths. This wouldn't break portable installs, as they could just put replace=config in their local openmw.cfg to discard the lower-priority values, which is an existing working feature we've had for ages.

I think the latter's probably pretty easy to do and it's not like our public documentation says we do exactly the default boost::program_options behaviour without deviation, because we already don't.

data=./resources/vfs-mw

I think this line is very naughty and shouldn't be in this file whether or not we keep the rest. It enables Morrowind-specific stuff, so if we're making a multi-game engine, we don't want this to be enabled globally by a system-protected config file. In my mind, it makes more sense for the wizard to put this line in the user config file when it's setting up Morrowind. That has the obvious problem that the relative path will be wrong, but it's simple enough to add another path slug called ?resources? that evaluates to whatever we're using as the resources directory. The one problem that leaves is users potentially removing it from their user config because they don't know what it is, but then we don't see that as a concern for the bazillion Morrowind.ini settings that also go into that file.

The directory's also a little bit OpenMW-version-specific, but maybe not enough to cause a problem.

In the global openmw.cfg, it's set to what CMake evaluates ${OPENMW_RESOURCE_FILES}/vfs-mw as, so the details here may be different on different platforms.

Why might we want rid of this file

The main reason is that users keep editing the wrong openmw.cfg file. On the face of it, this is kind of fine - as long as they're not editing a protected system file, this is something we support, and how you're meant to set up a portable install. However some users, in particular Windows users who think Windows Vista is some far off future operating system and haven't kept up with the bits of the Windows developer manual that say not to put user-editable config files in C:\Program Files, and, more numerously, users who've spent years using software written by people in the previous category who've had to learn to bypass any permissions hurdle they encounter automatically without even realising they've done anything, keep bypassing their OS' permissions system and editing it anyway. Also, users running dev builds don't typically run the installer, so don't end up with OpenMW in a protected system directory, and a bunch of people have published guides telling people incorrect ways to use OpenMW that include editing the wrong file.

It's kind of no big deal if users edit the wrong file, as it's a perfectly cromulent location to enable mods etc., but it can really easily lead to load order problems, e.g. if you've got content=Morrowind.esm in your user openmw.cfg and content=somemod.esp in your local openmw.cfg, then somemod.esp loads first, and if it depends on Morrowind.esm, that will just lead to an error being emitted. That's less bad than overwriting default settings in settings-default.cfg as it's easy to undo, but it's still a nuisance.

'alternatives' to getting rid of it

Give it a different name

This did nothing to stop users insisting that settings.cfg and settings-default.cfg were the same file even after we'd explicitly told them otherwise. I think this would be pointless, and make the config system more complicated.

Put it in a different place

The local openmw.cfg has to be at a fixed relative path to the OpenMW binary because it contains things specific to that OpenMW commit. Users will find the new place and then break things just like before, and then say it's our fault for moving the file they've always edited.

Aggressively obfuscate it à la defaults.bin

Not viable as users with a portable install are explicitly supposed to edit the file themselves (provided they've installed OpenMW itself to a user-writable directory).

Use the OS permissions system to stop users editing it

We already do. It doesn't stop anyone.

Set the file as hidden (and let portable users unhide it)

• People will write guides saying to unhide it.
• Windows users who like to bypass the permissions system are disproportionately likely to have hidden folders visible.
• We can't do this for dev builds as they just get unzipped, so we can't use fancy file attributes.

Just stop telling users to install your mod by editing their config files and suggest they use the launcher - people who know they can edit their config file instead should already know which file to edit

I think this would definitely dent the problem, but probably wouldn't solve it. Also, the launcher's not entirely great for this UX-wise.

Make the installer let users pick between a system-wide and portable install, and explain which config paths they'll need to edit with each option

If we explicitly support users editing the config file they gravitate towards, but only in a particular mode, it'd obviously cause fewer problems if they're already using that mode. This will do nothing for the users who refuse to read anything other than stab at the Next or OK button.

Why might we want to keep this file

We intend third-party games that use OpenMW to not need to recompile the engine if they're not meddling with its guts

I can't think of anything such a game would want to put in the local/global openmw.cfg, so I don't think we need to worry about this. I've not thought too hard about it, so could be wrong.

We want it to be easy to set up a portable install, and having the file already there to make a small edit to is pretty easy

It'd be even easier if we provided separate portable and system-wide packages, or an installer that did both and let you pick at install time. If we're ditching loads of stuff anyway, the magic openmw.cfg a user would need to create to turn an install portable would only be four lines long anyway, so hardly a monumental task to create.

It's how we've always done things, and there must have been a good reason at the start for the file to exist

This is a fair comment, but the config system's evolved quite a lot in the last decade, so the current file isn't really doing what its original incarnation did. It used to just be

data=./data
resources=./resources

and we've got rid of the random data directory in the install path years ago, and the engine already sets that resources directory by default if it's not in any openmw.cfg.

Things we've removed since this RFC was opened:

content=builtin.omwscripts
script-blacklist=Museum
script-blacklist=MockChangeScript
script-blacklist=doortestwarp
script-blacklist=WereChange2Script
script-blacklist=wereDreamScript2
script-blacklist=wereDreamScript3

The descriptions that were originally in the list above (but with the tenses corrected so things in the past aren't phrased like they're in the future)

content=builtin.omwscripts

!3925 (merged) zapped this as it's what told the engine to load game-independent parts of the engine, so it always needed to be loaded and should be done implicitly within the engine, just like the game-independent resources/vfs directory is. Side note: currently the file isn't entirely game-independent, but there's nothing stopping resources/vfs containing a game-independent builtin.omwscripts and resources/vfs-mw containing a Morrowind-specific builtin.omwscripts if we want to go for that approach.

script-blacklist=...

I'm told this was a silly setting that we could do without, but several other team members presented slightly different ways to get rid of it, and I don't care enough to learn and reiterate the details. It was exterminated by !4440 (merged)