Better ruleset support
It has been mentioned by @martin-t that right now ruleset support is very limited. I propose to make a clean way of handling rulesets by making a system where we give server admins a very specific and well documented framework for managing rulesets and custom changes.
Terminology: ruleset: something that has it's defaults, has been tweaked to almost perfection, can (and should) be played as is with the exact settings the creator(s) came up with but they should also allow experiments based on top of them. Vanilla, XPM, insta, Overkill, XDF, CRA (not official) are all rulesets.
- As little hardcoding as possible
- Rulesets don't need to know about each other when switching
- Easy switching between rulesets both locally (campaign, different tutorials, create menu,
mapcommand) and on servers with no accidental leftovers from previous rulesets
- No change in config structure for single-ruleset servers -
- Admins of ruleset-votable servers might want to share any part of the config between rulesets (server name, MOTD, hats and other easter eggs, votes), what is shared and what is per ruleset is up to them (e.g. votable nades in insta but always on in overkill).
- Easy experimentation with different cvar values (offline and online) that is undone when switching rulesets
- Custom games with rulesets from the menu (both unchanged rulesets or with additional customization)
Consider a hypothetical
exec_ruleset command with invocation
exec_ruleset Overkill. It would
- Execute all config files that are executed right now at the server start but before
Of course, the last pattern is subject to bikeshedding.
How to avoid infinite loop when the server's starting ruleset is not vanilla (putting
exec_ruleset at the top of
server.cfg would recurse forever)?
ruleset-*.cfg files reset server cvars to defaults, then apply their changes - rulesets only need to know about vanilla, not each other.
Single-ruleset servers put e.g.
exec ruleset-overkill.cfg at the top of
g_overkill and similar cvars are deprecated - description tells them to use
Ruleset-votable servers use this scheme:
server.cfg is moved to
server-custom.cfg (or any other name).
server.cfg execs the starting rulesets (doesn't have to be vanilla) ruleset-*.cfg file and custom config - e.g.
exec ruleset-overkill.cfg; exec server-custom.cfg.
Votes for switching ruleset call the new ruleset file and and custom config - e.g.
exec ruleset-CRA.cfg; exec server-custom.cfg.
The split is necessary to avoid an infinite loop while allowing servers to be votable without starting as vanilla.
This scheme would be documented at the bottom of the example server.cfg and/or wiki. There is no magic and it already works (only insta is missing a
ruleset-insta.cfg file). Easily extensible - just exec all your configs after the
Menu support: Similar to graphics presets but because there can always be hidden state here, use dropdown/listbox instead of buttons to indicate currently selected ruleset. Changing the ruleset execs its
ruleset-*.cfg. Additional cvar/mutator switches are below and can be changed on top of the ruleset's config - changing ruleset automatically resets them.