Streamlining of gamelogic configuration, player awareness

[Viech]

The configuration for the gamelogic is spread over three places:

• cvars

• definitions (unvanquished.h)

• config files

This in itself is already bad but it's made worse by the fact that settings are spread more or less arbitrarily over these places and each of them has a drawback of its own. Players can be lucky if their client isn't out-of-sync but it's impossible for them to see whether or how a server is modified. Let's clean this up.

The half-assed approach

Basically, there are things we want server admins to configure and stuff they should better not touch, since it would confuse people used to the default gameplay. For instance, everything related to build points and building limitations is configurable via cvars to allow for UBP or Tremulous-like configurations but I don't want server admins to tweak damage values without the user being informed. While modifications that are easily visible to both teams (build point generation, stage thresholds) can stay in the volatile form of cvars, we should have a single, well organized place for all the other settings.

Config files can, in theory, contain most of the stuff that is currently located in unvanquished.h. However, when we give them a greater importance we should allow them to be automatically synchronized with the client as the cgame needs some of those values for display purposes (an out-of-sync visualization is worse than having none at all). It would also be very nice for players to be able to see a list of modifications on a given server.

Forcing server admins to create a mod and packaging the config files in a pk3 is nearly as bad a solution as baking them into the client vm. Instead, I could imagine config files being parsed into read-only cfg_* cvars at the beginning of a match and using the cvar's synchronization abilities. This requires some network traffic on client connect but it would be trivial to display a list of modifications to the player that way. The naming of the cvars could be derived directly from the directory structure of the configs, e.g. cfg_weapon_lcannon_attr_maxAmmo. Configuration cvars don't have a default value in the code but the game will refuse to start if not all of them are set in the config files.

The radical approach

Put all gamelogic settings, including those that might change on a per-map basis, in config files. Instead of per-map or per-layout .cfg files, a map can be started with a given profile. A profile is a directory that has the same structure as the configs folder where individual config files can be overwritten. A server can set a default profile.

Please discuss this here!

[kangz]

When you say "without the user being informed" I'll assume you are talking about cgame and not the player. It is the server's owner's responsability to advertise the changes. My idea with config files was to make it easy for us, the devs of the main mod, to change the gameplay. I was kind of hoping that kharnov will give it a try and come up with crazy things. If we say to server owners that they can change these values it is another problem.

Personnaly I'd make people use a mod for significant (ie related to prediction) changes to the config variables. Because it is actually a modification of the game. No need to add a ton of cvars or a special protocol for that.

I'm not sure it is a good idea to allow maps to change the configs; it would makes the game harder to learn, with mechanics that changes on a per-map basis.

[Viech]

I was talking about the player. Server owners have virtually no tool to inform players about all the small value tweaks they did. I don't like these kind of changes either but we can't prevent them and I'd rather like to see them streamlined so that when a server is moded in that way, it is visible to the player.

The config files give the impression that creating a real mod isn't necessary and server owners won't be aware of the fact that changing them just on the server side will mess with prediction.