Menu
▾
▴
#130 Read multiple cfg files
Hi there,
This patch changes how config files are chosen to read.
The primary reason for this patch is to allow separation between game and gemrb install information. This makes it possible to have a system gemrb.cfg file detailing the install paths etc (which will always be the same for all games), and have a separate, far smaller gamename.cfg file for each game, storing game type, paths, video settings etc.
Basically this means gemrb doesn't quit looking for config files after it's loaded one successfully, allowing more than 1 cfg to load, with different info in each. It also means that if for example you want to use the system config but with your own override directory, you can just put the override directory in your ~/.gemrb.cfg.
Note that it also works just great with one config file, as before, so it won't break anyone's existing setups.
Hope you enjoy!
This would give yet another config file to care for.
We are supposed to handle the original game's config file which would store the video settings and such for that game.
On the other hand, some might not want gemrb to overwrite a file in their installed game, and would rather like to have their config stored with gemrb. In any case, this needs some more consideration.
I don't want to have 3 config files (four if we consider the gametype based ini file too).
Well some of the config files it looks for are expected to fail, so I don't expect many people would actually manage & load 3 or 4 configs.
A major use could be to have a game installer offer to copy the game-install-specific parts to /etc/games/gamename.cfg , which could then be expected to work with a standard gemrb.cfg (whether installed locally (~/.gemrb/gemrb.cfg) or globally (/etc/games/gemrb.cfg)) being loaded first, without the user having to touch a .cfg themselves. If they wanted to change the default system-wide config, they just create a ~/.gemrb/gamename.cfg file and only fill it with the settings they want to override.
That's the sort of usage I want to enable with this patch. And as I said, it'll still work just fine if you want to keep with one large config file per game.
P.S. regarding "some might not want gemrb to overwrite a file in their installed game, and would rather like to have their config stored with gemrb", this would be an easy fit with the above patch, as gemrb could just append / overwrite the settings to the user config (~/.gemrb/gamename.cfg), even if the game was loaded with settings from a unwritable cfg in /etc
I know, but in that case the original game's config should be ignored to keep the number of config files the same.
So, i would look for the game specific cfg only if gemrb.cfg has a flag in it like: ownconfig=1
Which would instruct gemrb to ignore the game's config and load its own.
Another idea is to add support for including/sourcing configs. That way the default number stays the same, but the upper limit is gone, which would allow for all kinds of flexible setups.