# 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](https://gitlab.com/OpenMW/openmw/-/blob/master/files/openmw.cfg.local) or [global](https://gitlab.com/OpenMW/openmw/-/blob/master/files/openmw.cfg). 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 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