[X] I have added a changelog entry about what my pull request accomplishes, or it is an internal change
Description
Adds a new command /set that allows the player to manipulate the configuration options at runtime. Some of the options require a game re-launch. The options themselves are not documented, but they match the JSON structure.
Changes the way the config map is defined, to use X-Macros similar to the game_string.def file. I believe this approach is more readable.
Changes the *_bar_showing_mode to *_bar_show_mode after all, and adds some code to maintain backwards compatibility with the previous names. This is chiefly done to make sure that the variable names in the g_Config global variable match the option names in the JSON, and make exceptions to this more visible.
Since some of the g_Config options are put in nested namespaces (for example: g_Config.rendering.fps, but the option in the config is called "fps"), a new function Config_ResolveOptionName is introduced to translate one into another by stripping the namespace away. However, eventually, I'd like to change the JSON config structure to actually introduce nesting, and reorganize the existing g_Config variables in namespaces that'd likely reflect the config tool structuring.
Argument parsing remains shitty and manual.
This PR makes some of the existing commands become redundant. For example, /vsync on is now the same /set vsync on. The first instinct is to remove these dupes, however, in most cases the usage would become more awkward: /wireframe on would have to become /set enable-wireframe on and /speed 2 would become /set turbo-speed 2. This is pretty wordy IMO. LMK your thoughts. Maybe we should introduce command aliases, but I'd make that a separate initiative.
Checklist
Description
/setthat allows the player to manipulate the configuration options at runtime. Some of the options require a game re-launch. The options themselves are not documented, but they match the JSON structure.game_string.deffile. I believe this approach is more readable.*_bar_showing_modeto*_bar_show_modeafter all, and adds some code to maintain backwards compatibility with the previous names. This is chiefly done to make sure that the variable names in theg_Configglobal variable match the option names in the JSON, and make exceptions to this more visible.g_Configoptions are put in nested namespaces (for example:g_Config.rendering.fps, but the option in the config is called"fps"), a new functionConfig_ResolveOptionNameis introduced to translate one into another by stripping the namespace away. However, eventually, I'd like to change the JSON config structure to actually introduce nesting, and reorganize the existingg_Configvariables in namespaces that'd likely reflect the config tool structuring.This PR makes some of the existing commands become redundant. For example,
/vsync onis now the same/set vsync on. The first instinct is to remove these dupes, however, in most cases the usage would become more awkward:/wireframe onwould have to become/set enable-wireframe onand/speed 2would become/set turbo-speed 2. This is pretty wordy IMO. LMK your thoughts. Maybe we should introduce command aliases, but I'd make that a separate initiative.