Unify User.cfg, Local.cfg, Mod.cfg

[Stan]

Currently we have three files to store game values if you don't count default.cfg

All the usage of those variables can be found using the following links.

Since we only use CFG_GET_VAL which is a macro:

g_ConfigDB.GetValue(CFG_USER, name, destination)

We could nuke the other two files as we barely read nor need them.

Usage across the codebase

• ​https://github.com/0ad/0ad/search?utf8=%E2%9C%93&q=CFG_GET_VAL&type=
• ​https://github.com/0ad/0ad/search?utf8=%E2%9C%93&q=CFG_MOD&type=
• ​https://github.com/0ad/0ad/search?utf8=%E2%9C%93&q=CFG_USER&type=
• ​https://github.com/0ad/0ad/search?l=C%2B%2B&q=CFG_SYSTEM&type=&utf8=%E2%9C%93
• ​https://github.com/0ad/0ad/search?utf8=%E2%9C%93&q=g_ConfigDB&type=

Since we use g_ConfigDB everywhere else we could also nuke the macro

[elexis]

We could nuke the other two files as we barely read nor need them.

Are you sure there wasn't a good reason for the split?

[Anil Eapen]

Replying to elexis:

We could nuke the other two files as we barely read nor need them.

Are you sure there wasn't a good reason for the split?

Im not able to find Local.cfg, Mod.cfg in the Config folder.

[Anil Eapen]

Replying to stanislas69:

We could nuke the other two files as we barely read nor need them - In progress(Local.cfg, Mod.cfg)

Since we use g_ConfigDB everywhere else we could also nuke the macro - In progress

[elexis]

The question should be answered before something is done. In particular I would like to know the reasoning the authors of the files had to split them.

[Stan]

Looking at the blame report in that file one should ask olsner from 14 years ago or Philip

[smiley]

According to r6919, it seems that local.cfg was meant to be used as how the current user.cfg is being used.

[Anil Eapen]

Replying to elexis:

The question should be answered before something is done. In particular I would like to know the reasoning the authors of the files had to split them.

"Since we use g_ConfigDB everywhere else we could also nuke the macro" -

There is a use of both the macro and g_ConfigDB across files.

Should the macro be removed ?

[elexis]

I still don't know if two of the files could be unified.

But the GetValue(file, key) function can be useful to read the default.cfg value in order to display the default option value in the options dialog.

[Itms]

It looks like the files shouldn't be unified:

• local.cfg is not needed (I never used it) but using it instead of user.cfg is a good idea! We could add that trick to the Getting Started page for developers.
• mod.cfg is needed for modders to change the CFG_MOD layer of the conf
• user.cfg is, of course, needed and used.

Basically local and mod should be manually edited and should behave as read-only files, just like default.cfg.

If the macro is never used, we could indeed scrap it and continue using ConfigDB.GetValue.

Replying to elexis:

But the GetValue(file, key) function can be useful to read the default.cfg value in order to display the default option value in the options dialog.

It sounds like we should have a GetDefaultValue that does not bypass the whole abstracted hierarchy of config values (SYS/MOD/USER). For instance, if a mod adds a config entry, the default value should be taken from the mod.cfg. And a mod could also want to mod the default value (less likely).

[elexis]

As far as I see this is a won't fix for the previous design, whichever it was, and a won't fix for new designs either:

• local.cfg must be different from user.cfg. It should allow manual config edits that cannot be modified by the options GUI page, nor change the default.cfg. This way the defaults file will contain the same defaults globally without reducing any configuration abilities. From the above cited r6919:

  	// Try loading the local system config file (which doesn't exist by
  	// default) - this is designed as a way of letting developers edit the
  	// system config without accidentally committing their changes back to SVN.
  	g_ConfigDB.SetConfigFile(CFG_SYSTEM, L"config/local.cfg");
  

• I suppose mod.cfg should be different from local.cfg and user.cfg, because it relates to default configuration values of a mod that isn't the public mod. It sounds like it should become a distinct file per mod. Also worthy to question whether public mod configuration values and modded configuration values should be stored in the same user.cfg or not rather yet another config file.

We also need support of different users, at least for the lobby it would be very useful, since we want to store which terms and conditions were accepted per user. It could then also store passwords of multiple users and possibly multiple lobby servers.

Depending on how many new files or configuration dependencies there are, we might think about using XML or JSON in order to support nested structures. (The buddy list is also stored with a custom language.)

(refs ​Phab:rP21036)

[elexis]

There were two days with relevant IRC discussions with wraitii and me on ​Phab:D1930, ​Phab:D1931.

I came to the conclusion that we don't have a real use case for local.cfg.

Advantages of having it:

• allows the user to create a file that is not overwritten by the program
• thus allows arbitrary whitespace, arbitrary order of arguments, storing comments

Disadvantages of having it:

• more code complexity (priority and order of launched config namespaces)
• confusing users with multiple config files that dont have clearly distinguishable use cases

Historic reasons for introduction of local.cfg:

The commit by Philip and the realworld use cases of why it was introduced is that developers changed the default.cfg to test their options and accidentally committed them. But they could have used the user.cfg instead of creating a new local.cfg.

So it appears that the discovered advantages of having local.cfg are too insubstantial to justify the added complexity. If the file is considered useful enough to be kept, the use cases should be worked out and displayed more. If it's for the purpose of having an editable cfg file, then it should be described as that being the reason for its existence in code comments about the config namespace, in the default.cfg comment, and in the trac wiki pages speaking about config files.