The Configuration Situation

Everything about development and the OpenMW source code.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

The Configuration Situation

Post by Zini »

A while back I wrote that I wanted to propose some improvements to the configuration system once 0.11.0 is done. But it seems we are not making any progress with it, so I can write down my thoughts as well now.

It seems that some of our developers haven't fully understand how the configuration system is supposed to work. Also, it is a bit overcomplicated in some places and incomplete in others (we have still some open issues on the tracker).

What I am going to do is sum up how the system is working now. Then I will make a list of proposals how to improve it (feel free to discuss). I haven't thought much about the schedule. We may add the issues to 0.12.0 for now. But if we do, I will keep them in a separate branch besides main and next, because they mostly depend on each other and we can't release the configuration improvements in a partial complete state.


Where we are now

(note that on the launcher side the implementation isn't fully functional)

There are four configuration locations (given with increasing priority):

- global: A system-wide accessible location, meant for user-independent files when OpenMW is installed.
- local: Alongside the binary. Only to be used when OpenMW is uninstalled. I think on Windows global and local locations are identical.
- user: A special per-user location.
- command line: Command-line switches; only for openmw.cfg.

We have 3 configuration files (not counting additional tools like editor or launcher):

- plugins.cfg

OGRE plugin system configuration. User will not change these, unless he installs a new version of OGRE. If there is more than one file, the file in the location with the highest priority is used.

- ogre.cfg

Render-settings for OpenMW. User may change these.

If the launcher is run and there is no openmw.cfg file in the user location, the launcher will create one.

If OpenMW is run and there is no openmw.cfg file, OpenMW will run through the OGRE-settings dialogue and create one in the user location.

If there is more than one file, the file in the location with the highest priority is used.

- openmw.cfg

Non-render OpenMW settings. User may change these. If the launcher is run and there is no openmw.cfg file in the user location, the launcher will create one.

If there is more than one file (let's call the command line arguments a file too for now), the settings are merged, with settings in locations with higher priority taking priority over settings in locations with lower priority.

Note that settings that consist of several entries will not merge, e.g. if the global location has a list of data directories and the user location has one too, only the list form the user location will be used and not a merged list (otherwise it would not be possible to remove an unwanted entry for the global settings).


An important setting is the data directory (found as mentioned above in openmw.cfg. We have:

--data: a list of directories
--data-local: a single location with higher priority than data. Must be writeable (the editor will write its files to here).

The data directories contain the esx-files and the resources. If there is more than one data directory, all data directories are considered (that does not work for resources right now; I think).

Improvements #1: Global/Local

We had some variations in global/local handling and I am not entirely sure what is currently implemented (there were even some changes between master and next). I would suggest that local is always replacing global (instead of merging in the case of openmw.cfg).

As I wrote above it is possible that this is already implemented.

Improvements #2: Simplify Location Handling

Currently our location handling is complicated and a bit inconsistent (openmw.cfg merging, plugins.cfg/ogre.cfg not merging).

Having plugins.cfg in the user location is mostly pointless, because changing the plugins.cfg will most likely mean using a different version of OpenMW. The end user has no need to change plugins.cfg. He will either install a new version of OpenMW, in which case the global location will be used. Or he runs OpenMW uninstalled, in which case the local location will be used. Therefore I propose not to check for plugins.cfg in the user location anymore.

Having ogre.cfg in the global location is also useless, since we can't provide a reasonable default file when installing OpenMW. Since we are not merging this file anyway, having more than one is a bit confusing and mostly useless. And since we can't/don't need to provide a default file, we also don't need to check the local location (for playing OpenMW without installing). Therefore I propose not to check for ogre.cfg in the global and local location any more.

Together with #1 this change means that non-merging cfg files will be stored in only a single location each from now on.

Improvements #3: Configuration of a newly created install

There were some discussion about automatically picking up existing MW installations and at a time we considered letting the launcher handle this task. I like to propose something different now:

Deliver the global openmw.cfg file with some pre-set values for --data and --data-local:

(1) --data=Default location for a normal MW install (Windows only)
(2) --data=Default location for a Steam MW install (Windows only)
(3) --data=Default location for a MW install under WINE (not 100% sure, if there is such a thing, Linux and OS X only)
(4) --data=A suitable global location (varying per OS). On Linux that might be /usr(/local)/share/openmw or something (I am open for other suggestion)
(5) --data-local= $HOME/OpenMW.

With this setup at least on Windows OpenMW should work out of the box without the user having to do any openmw.cfg fiddling. The user also has a nice location for adding downloaded plugins on a per-user basis and a good setup for the editor (5).

On Linux this will also allow modders to build packages from plugins and to distribute them over the regular package manager (by placing files into (4)).
User avatar
lgromanowski
Site Admin
Posts: 1193
Joined: 05 Aug 2011, 22:21
Location: Wroclaw, Poland
Contact:

Re: The Configuration Situation

Post by lgromanowski »

Thanks for clarification, I will update configuration manager code (probably in this weekend or on the beginning of next week).
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: The Configuration Situation

Post by Zini »

Okay. With "update" you mean the "Where we are now" part or the "Improvements" part?

In case of the later: There are some additional implications:

1. The data directory handling should handle missing directories gracefully (so we don't get into problems with the pre-set locations).

2. The path-handling must be able to cope with environment variables.

3. Maybe (on Windows) we also need the ability to embed registry keys into the paths (for picking up Morrowind installations). I am not sure how useful/necessary that would be and I would like a statement from our Windows developers here.
User avatar
lgromanowski
Site Admin
Posts: 1193
Joined: 05 Aug 2011, 22:21
Location: Wroclaw, Poland
Contact:

Re: The Configuration Situation

Post by lgromanowski »

Zini wrote:Okay. With "update" you mean the "Where we are now" part or the "Improvements" part?

In case of the later: There are some additional implications:

1. The data directory handling should handle missing directories gracefully (so we don't get into problems with the pre-set locations).

2. The path-handling must be able to cope with environment variables.

3. Maybe (on Windows) we also need the ability to embed registry keys into the paths (for picking up Morrowind installations). I am not sure how useful/necessary that would be and I would like a statement from our Windows developers here.
I mean "improvements" part mostly, because "where we are now" is done - with some exceptions:
- openmw.cfg is merged and if i.e. there are two "data" variables then the one which was loaded last will be used
- ogre.cfg / plugins.cfg - it needs cleanup according to your guidelines
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: The Configuration Situation

Post by Zini »

Okay. We probably should adjust the tracker accordingly. We have a couple of issues related to this tasks and we need to add the remaining tasks/features. Also, these all should be moved to openmw-0.12 for now and maybe somehow grouped together (a tag or a common parent issue?).

These are the issues I found:

* Automatically pick up the path of existing MW-installations
* Generate a suitable default-value for --data-local
* Handle resources across multiple data directories

And somewhat related:

* Need to create app bundle using CMake, not by hand
* Automate Packaging

From the comments in my release preparation thread I read that some of the packages were delivered with odd configurations, that might cause problems once we implement these changes. We probably should try to get the packaging process automated once and for all (and for all platforms). This would include using CPack to generate a Windows installer.

P.S.: Not sure how much that will affect your work. But in case you don't know, I guess I should mention that we currently generate two openmw.cfg files when building. One for local use (uninstalled) and one for global use (installed).
User avatar
lgromanowski
Site Admin
Posts: 1193
Joined: 05 Aug 2011, 22:21
Location: Wroclaw, Poland
Contact:

Re: The Configuration Situation

Post by lgromanowski »

Zini wrote: (3) --data=Default location for a MW install under WINE (not 100% sure, if there is such a thing, Linux and OS X only)
This works for me (probably it could be simplified):

Code: Select all

$ wine regedit /E system.reg.tmp "HKEY_LOCAL_MACHINE\\Software\\Bethesda Softworks\\Morrowind" && grep "INSTALLED PATH" ~/.wine/system.reg.tmp | sed s/\"INSTALLED\ PATH\"\=//;
output wrote: "C:\\Program Files\\Morrowind"
K1ll
Posts: 184
Joined: 06 Aug 2011, 21:54

Re: The Configuration Situation

Post by K1ll »

That doesn't work for me since INSTALLED PATH is Installed Path so if it's case insensitive it'll work.
User avatar
lgromanowski
Site Admin
Posts: 1193
Joined: 05 Aug 2011, 22:21
Location: Wroclaw, Poland
Contact:

Re: The Configuration Situation

Post by lgromanowski »

This one should work for you too (not tested):

Code: Select all

wine regedit /E system.reg.tmp "HKEY_LOCAL_MACHINE\\Software\\Bethesda Softworks\\Morrowind" && grep -i "INSTALLED PATH" ~/.wine/system.reg.tmp | sed -e's/^.*=//' 
User avatar
lgromanowski
Site Admin
Posts: 1193
Joined: 05 Aug 2011, 22:21
Location: Wroclaw, Poland
Contact:

Re: The Configuration Situation

Post by lgromanowski »

Following script extracts Morrowind data path from wine registry and write an output in INI-file configuration format:

Code: Select all

#!/bin/bash

homedir=~
eval homedir=$homedir

datadir="/Data Files"
winedir="/.wine/dosdevices/"

morrowinddir=`wine regedit /E system.reg.tmp "HKEY_LOCAL_MACHINE\\Software\\Bethesda Softworks\\Morrowind" && grep -i "INSTALLED PATH" ~/.wine/system.reg.tmp | sed -e's/^.*=//'`
morrowinddir=${morrowinddir//\"/}
morrowinddir=${morrowinddir,}                                           # make first letter lower case (drive letter)
morrowinddir=${morrowinddir//\\\\/\/}                                   # replace \\ with /
morrowinddir=${morrowinddir:0:${#morrowinddir}-1}                       # remove eol
morrowinddir=${morrowinddir}${datadir}                                  # concatenate "morrowinddir" and "datadir"

echo data=\"${homedir}${winedir}${morrowinddir}\"

I think it should be run by dpg/rpm/whatever install scripts.

// EDIT: Added quotation marks around directory path because boost config parser return error without it.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: The Configuration Situation

Post by Zini »

I think it should be run by dpg/rpm/whatever install scripts.
Sounds difficult. Can cmake handle this task? If it can, I don't know how. Originally the idea was to embed a special escape sequence into the path string, that would be interpreted as a registry key, which then would have been inserted by OpenMW after somehow fetching the matching data from the registry.

I have no fundamental objections to doing it during install instead of during runtime, but if we go down this route we need to have a proper installer for Windows for the next release.
Post Reply