Wintermute Engine Forum

Wintermute Engine => WME Lite => Topic started by: HCDaniel on August 12, 2014, 06:43:33 AM

Title: WMELite settings.xml handling
Post by: HCDaniel on August 12, 2014, 06:43:33 AM

I wonder whether the logic in

Code: [Select]
CBRegistry::ReadString(const AnsiString& subKey, const AnsiString& key, const AnsiString& init)

is actually correct, w.r.t. the order of the values of both xml files being checked for the matching key:

Code: [Select]
ret = GetValue(m_LocalValues, subKey, key, found);
if (!found) ret = GetValue(m_Values, subKey, key, found);

The settings.xml that will be read into the "m_LocalValues" map is a "readonly" version (e.g. one that you might distribute with the game), because these values will never be written to nor saved.

The settings.xml that will be read into "m_Values", however, is the one where values are updated and that is saved for every user/player.

If an item is present in both maps, a user-defined redefinition should override the read-only "default". If I read the code of the original WME correctly, there it is done as I would expect, checking "HKEY_CURRENT_USER" before "HKEY_LOCAL_MACHINE" when reading, and writing always to "HKEY_CURRENT_USER". But in WMELite it is reversed. Is this intended behaviour or can I savely reverse this? (BTW I would then change the wording for the "local" values/settings, to clarify these are read-only global defaults).
Title: Re: WMELite settings.xml handling
Post by: Mnemonic on August 13, 2014, 07:56:45 AM
The idea in WME Lite is that the engine only ever works with the settings stored in user's profile directory.
The "local" values, i.e. the ones stored in a file which is in the game directory are meant for temporarily overriding some settings, mainly for debugging purposes.

It does not map to the LOCAL_MACHINE / CURRENT_USER logic in Windows, rather it maps to the registry/wme.ini logic in the original WME - normally WME only works with registry settings, but you can override those by placing wme.ini file to the game directory.
Title: Re: WMELite settings.xml handling
Post by: HCDaniel on August 13, 2014, 08:56:40 AM
So when I want to make wmelite behave like WME in this regard I need to think about something else.

What I need is that the installer of the game generates a "settings.xml" with some sane defaults (in our case, the default language of the game), which can then be overridden by every user of the game. Because such a setting shall not be in the savegames, the registry is the correct place.

This works with WME already, when I put a registry key into either HKCU or HKLM during installation, WME will pick it up. Once a user decides to change the language, it is placed in HKCU (either replacing the original setting or "overriding" the default in HKLM).

I could, for instance, add a third settings.xml, to have this logic:

1) "local" settings.xml (searched in ".", read-only)
2) "global" settings.xml (generated during install or packaged with the game, read-only)
3) "user" settings.xml (stored in user account, read-write)

Any other idea (maybe less complex) to achieve this?
Title: Re: WMELite settings.xml handling
Post by: metamorphium on August 29, 2014, 10:58:24 PM
How about having per user settings in that xml file?

Btw. you are my personal hero, Daniel for spotting the crash in ConvertUtf.h I was pulling my hair over that one. :) I owe you a few   ::beer ::beer ::beer