gameplay: to hard-code or to not hard-code, that is the question

[illwieckz]

That doesn't tell the cvar type neither the cvar description.

And one would still need a lot of boilerplate code to declare all cvars in c++ code.

[Sweet]

The wording might be a little confusing to some people. Cvars on a server are typically set in "config files", like config/map/default.cfg. These are different from "config files" like game/configs/weapon/blaster.attr.cfg, which are sent to clients in some package. Changing blaster.attr.cfg is much more tedious indeed.

[Viech]

There would be only one default value, the one from config file; there would be no define and no declaration in code.

Any system is acceptable where users can clearly tell that and how a server is modded from vanilla gameplay. This is a hard requirement to make progress from the three systems already in place and to really settle the discussion that spawned this thread.

Your proposal ensures the first aspect (unlike cvars) but possibly makes the second hard as the client would know only about the modded value. Or do you propose that config files are loaded from all .dpks in order and then merged into one programmatically, with the first one being the default that the gamelogic can thus know about? This might be really good (thanks to unvanquished_src.dpkdir not being a submodule anymore!), if technically feasible from a .dpk loading perspective.

[killing time]

I would like to retract my previous full-throated support for cvars as I remembered one thing that's a little broken about them... If you load mod A and then mod B without shutting down the engine in between, then the cvar values from mod A will persist in memory, even if none was changed from the default, and take precedence over cvar default values of mod B. This could be pretty bad if used for important gameplay stuff like max HP. So I guess I just want hard-coding now, at least if I have to choose from currently-existing systems.

The idea to have a globally-unique identifier like buildables.hive.buildTime for each config setting, and allow setting any value from any file, has some potential. But maybe it's better to do it without cvars due to the problem described above. If we have a single "mods" config file that is allowed to override the other ones then that would make the packaging annoyance less since there is only one file to package. If people used that then we would have the summary of changes like Viech wants and people would be likely to use it if we make it less inconvenient than the alternatives.

The thing that would still be annoying despite this is being unable to grep values within the codebase.