Eliminate magic strings as CVar names

[JordanLongstaff]

Just like SoH, 2S2H uses magic strings for so many CVar names, only even worse because it doesn't even have the CVar prefix macros, as far as I can find. Devise a system that allows all of the CVar names to be macros or constants. Bonus points if the system employs code generation.

[Eblo]

Yep, we've got CVar literal vomit. A recent PR came up that addresses this in a manner similar to SoH #1339. That PR prompted discussions over whether that approach is what we want and what other paths we might take. We haven't landed on an answer yet, which is why that PR has not been reviewed.

A related concern is defining default values for CVars. You have a default value argument when calling CVarGetInteger, which we often pass literals into, and then also DefaultValue for the same in the menus.

Bonus points if the system employs code generation.

What are you thinking here, from a high level?

[JordanLongstaff]

What are you thinking here, from a high level?

I've had a couple of ideas in the past. At my last job, we had our own CLI tool that we used to add translatable string IDs to our app's lexicon. We used i18n. The tool would generate a large JSON file with all the string IDs in a list. We'd add strings by specifying the ID and the English text, and they'd later be translated into other languages. The app then fetches the text from the specified ID, translated according to the locale.

I thought we could do a similar setup where we start from a JSON file containing all the CVar definitions, and create a CLI tool to add CVars as needed (migration might be a necessary feature too if we ever want to rename them). Then the tool could autogenerate, say, a header file with macro definitions for each CVar encapsulating names, getters and default values. The only thing we'd need to decide on is the JSON file's structure, which could be as simple as, for example:

[
  {
    "name": "gEnhancements.Player.SomeCVar",
    "macro": "SOME_MACRO",
    "type": "int",
    "defaultValue": 0
  },
  // ...
]

The macros would be generated like this:

#define CVAR_SOME_MACRO_NAME "gEnhancements.Player.SomeCVar"
#define CVAR_SOME_MACRO CVarGetInteger(CVAR_SOME_MACRO_NAME, 0)

This is just one idea. I've also considered having a GUI application.

[garrettjoecox]

I have a branch that does basically that, and uses a standard 2ship2harkinian.json

It works, but it's still not my favorite. Nor are the patterns that we've adopted on SoH. I really think we just need to rethink configs in general, and optimize for C++ usage over C, but I don't know how soon that will happen, and if we should do anything about cvars until then.

I will say, I don't see the current patterns as very problematic, not even close to how bad SoH used to be prior to us migrating to hooks and now individual enhancements in their own file, we're not using these cvar strings loosy goosy all over the codebase like we used to, the risk of a typo happening is fairly low.