Improve configuration system

[historic_bruno]

• Unify command line options, config files, overrides, and console/GUI
• Organize config files, possibly like ​INI files
• Support overriding user config, preventing other based on system capabilities, etc. - important for graphics config
• Allow e.g. hotkey sets
• Create decent API for scripts to access and modify config
• Some settings might take precedence over others, e.g. high/medium/low graphics settings vs. shadow map detail, filtering, etc.
• Better detection of GPU/driver capability, see also #145
• Support mod config files
  • Examples: a mod that overrides default camera settings, or a mod that defines its own completely new settings

See IRC discussion on ​2013-01-03 around 17:41. Some thoughts from Philip ​here.

[kingadami]

I would also like to have a --help command line option which would print out info about command line options and then exits. This is the convention most programs use (at least on linux).

[historic_bruno]

Yes, that's a good idea too. Would it be enough to display the contents of readme.txt​ or similar? Or should it be integrated with the config system itself?

We could have a data file or script that defines all the possible options and descriptions, then we'd never have to worry about maintaining a separate list. As a bonus, it would also allow us to reject invalid options. We'd have to consider the impact on modding (what if a mod needs to add new options?) and development (what if you want to play with a new option while the game is running, via hotloading).

[historic_bruno]

I guess the integrated approach would give us something like what fabio suggested here without cluttering up the actual config files.

[zoot]

I guess the "schema" could be defined in XML, while the actual config files could be .ini or something equally simple.

[kingadami]

Replying to historic_bruno:

Yes, that's a good idea too. Would it be enough to display the contents of readme.txt​ or similar? Or should it be integrated with the config system itself? We could have a data file or script that defines all the possible options and descriptions, then we'd never have to worry about maintaining a separate list. As a bonus, it would also allow us to reject invalid options. We'd have to consider the impact on modding (what if a mod needs to add new options?) and development (what if you want to play with a new option while the game is running, via hotloading).

I like the contents of readme.txt because it explains the commandline options. If someone wants help on all of the available configuration options in the config files then there can me another method (for instance in linux you would use the man pages or info pages for details but the --help option just shows overviews like your readme file). Whatever is done the help should only be kept in one place (preferably the act of adding a command line option would force the person to add the help information.  Using a library like Boost.Program_options might be useful instead of custom string parsing. It allows you to specify the description and helps in handling the help option.

[fabio]

A man page should eventually be provided since it's usually required by some linux distributions. Debian man pages (0ad and pyrogenesis, the latter being a link to the former) are available here: ​http://anonscm.debian.org/viewvc/pkg-games/packages/trunk/0ad/debian/

Having the man page generated by the same process by WFG itself would be nice, so it will available to all Linux distributions and can be keep updated from a single place.

[historic_bruno]

leper, any progress on this?

[leper]

In 14437:

Make ConfigDB properly thread-safe.
Replace CreateValue with SetValueString so we don't pass pointers to internal

ConfigDB structures around. Refs #1810.

Remove some splash screen related functions since we can achieve the same

with the ConfigDB functions exposed to scripts.

[leper]

In 15980:

Use an FSM to parse our config files instead of using CParser. Refs #2589.

Properly write config settings with multiple values back to files. Refs #1810.
Print error messages if we encountered an invalid setting.

[leper]

In 15986:

Extend the config parser to support ini-style config files. Refs #1810.

Config settings in a section are stored as "sectionname.setting" internally.
Do not write section headers when writing config files as we would need to write
settings without a dot first or ignore them. This can be changed once all settings
belong to a section.

[wraitii]

In 24215:

Let players remap hotkeys in-game, fix default hotkeys being qwerty-specific.

• Provide a "Hotkey" screen to let players remap hotkeys in-game using a convenient setup.
• Make all .cfg hotkeys refer to scancodes (i.e. position on the keyboard), so that default hotkeys now translate correctly for AZERTY, QWERTZ and other layouts.
• 'BackSpace' is now an alias for 'Delete', and works for killing units. This fixes #1917, as macs don't have a proper delete key and would need to use Fn+Del otherwise. This shifts "timewarp" to Shift+BackSpace.

Functionally, this switches hotkeys to scancodes, as that makes more sense (they are combinations of key positions, not actual text output).
SDL includes are cleaned and key names are reused.

Fixes #2850, Fixes #2604, Refs #1810, Fixes #1917.

Follows work in rP19624.

Various diffs tested by: Angen, Stan, Freagarach

Comments by: Nescio

Differential Revision: ​https://code.wildfiregames.com/D2814

[Dunedan]

I'd also appreciate a command line option to specify the location of the config file. That'd make some testing with multiple configs much easier.