Message Boards

Okay, as from discussion on irc, we have a problem.

Firstly, Cvars are console variables, which reside on the client and server, they are the ones that affect gameplay and other things.

The problem is: our current implementation.
As of late commits (below r951), we send all server cvars to the client, which results in perfect sync of the client side values. This is what was needed to be done eventually.

However, we have a naming problem, the freelook bug is a good example of this: we have a cvar named allowfreelook, which existed on both client and server, but the clients version was affected by the servers version "through proxy" by changing the sv_freelook cvar, the client could toggle freelook on or off using cl_freelook.

There lies the problem, we now send allowfreelook, which is used by the client and server, it is a variable in the common codebase as well.

We can't:
a) Stop sending allowfreelook (its has a CVAR_SERVERINFO and is needed), that is downright hacky as well.
b) Remove cl_freelook and sv_freelook, then the server would force freelook on or off, depending on its setting.
c) Countless other ways that results in hacky/buggy code.

Now, you may think this only affects freelook overall, but it doesn't, it affects a LARGE amount of other things as well, so what I and others of the team propose is this:

A) Put every single cvar in a single file that exists in the common codebase.
B) Bring back namespaces (cl_* and sv_* prefixes) for cvars (we could use CVAR_SERVERINFO and CVAR_CLIENTONLY instead, but I have not thought this through completely)
C) <add anything else>

There is one disadvantage to all of this, we break alot of older cfg's, BUT, because we aren't at 1.0 and not stable, we can do all of this.

Suggestions, opinions, criticisms?

Some proposed changes to client cvars:

Automap
Change all am_* prefixes to map_* as it's more user friendly.

am_ovteleportcolor becomes map_ovteleportcolor
am_ovexitcolor becomes map_ovexitcolor
am_ovlockedcolor becomes map_ovlockedcolor
am_ovnotseencolor becomes map_ovnotseencolor
am_ovxhaircolor becomes map_ovxhaircolor
am_ovgridcolor becomes map_ovgridcolor
am_ovthingcolor becomes map_ovthingcolor
am_ovcdwallcolor becomes map_ovcdwallcolor
am_ovfdwallcolor becomes map_ovfdwallcolor
am_ovtswallcolor becomes map_ovtswallcolor
am_ovwallcolor becomes map_ovwallcolor
am_ovyourcolor becomes map_ovyourcolor
am_teleportcolor becomes map_teleportcolor
am_exitcolor becomes map_exitcolor
am_lockedcolor becomes map_lockedcolor
am_notseencolor becomes map_notseencolor
am_xhaircolor becomes map_xhaircolor
am_gridcolor becomes map_gridcolor
am_thingcolor becomes map_thingcolor
am_cdwallcolor becomes map_cdwallcolor
am_fdwallcolor becomes map_fdwallcolor
am_tswallcolor becomes map_tswallcolor
am_wallcolor becomes map_wallcolor
am_yourcolor becomes map_yourcolor
am_backcolor becomes map_backcolor
am_ovshare becomes map_ovshare
am_usecustomcolors becomes map_usecustomcolors
am_classicmapstring becomes map_classicmapstring
am_showtime becomes map_showtime
am_showmonsters becomes map_showmonsters
am_showsecrets becomes map_showsecrets
am_overlay becomes map_overlay
am_rotate becomes map_rotate

Developer Cvars
I propose that all cvars that won't affect the common user and were designed for developers in particular take on the dev_* prefix.

ticker becomes dev_ticker
developer becomes dev_mode
noise becomes dev_noise


Video
fullscreen becomes vid_fullscreen


That's all I've got in me tonight, time to get some sleep. Please comment on these proposals with constructive criticism. If you disagree, please explain an alternative or argue why the command should stay the same.

Also feel free to propose your own changes. Remember that organization and user-friendliness are two key things to take into account while we tackle this so its best not to add too many new prefixes while still being able to explain the cvar in the shortest way possible.

We have another problem.. What do we do with stuff like BEGIN_CUSTOM_CVAR (.. ?

The client cvarlist should be split up into two lists:

- A list of actual client cvars.
- A list of read-only server info cvars.

I'll look into the cvars later.

Ralphis and I think it's a good idea to merge the deathmatch, teamplay, and usectf/ctf cvars into one cvar: gamemode.

gamemode (int) - Common cvar. (Read-only for client) Distributed to launchers as an integer. (Will require protocol bump)

gamemode 0 - Coop
gamemode 1 - DM
gamemode 2 - TDM
gamemode 3 - CTF
gamemode 4+ - New gametypes. (Would show up as "unknown" for outdated clients/launchers)

This would eliminate the hassle of juggling multiple cvars (deathmatch and teamplay do what for usectf?) while paving a smooth way for potential new gametypes.

deathmatch and teamplay do what for usectf?

Well... when you put it that way I realised UT's Assault mode is just two teams playing CTF/TDM on the same map.

But yeah, I agree too. The separate cvars are a leftover from DOS days IMO.

Okay, so Ralphis wants a step-by-step guide on how we're going to implement this. This is the best way to go about this:

1) Create a branch called 'gamemode', exactly like trunk.

2) Remove gamemode cmd from client.

3) Rename all instances of the gamemode var with 'doommode'. And to keep with consistency, rename 'gamemission' to 'doommission', the GameMode_t enum to 'DoomMode_t', and the GameMission_t enum to 'DoomMission_t'. Not much more than simple find and replace.

4) Create a new CVAR_FUNC_IMPL in the common cvarlist: gamemode. Default value is "0", CVAR_SERVERINFO, CVAR_LATCHED, CVAR_NOENABLEDISABLE. The reason it's not standard CVAR is because we should do the following:

* Make it so when the client or server simply types in "gamemode", the console will read all supported values.

* We should add in value translation so that inputting "gamemode ctf" should do "gamemode 3".

5) Create #defines (or whatever is best) for

0 - GM_COOP
1 - GM_DM
2 - GM_TDM
3 - GM_CTF

It would be much better in the long run for us coders. (example: if (gamemode == GM_COOP))

6) Remove the 'deathmatch', 'teamplay', 'ctf', and 'usectf' cvars and, at the same time, replace all instances with the appropriate gamemode cvars.

7) Change launcher protocol to reflect the new cvar.

8) Run it by denis, fix bugs, merge to trunk when ready.

EDIT: We should also create two flags, CVAR_SERVERARCHIVE and CVAR_CLIENTARCHIVE for the common cvars. Same as CVAR_ARCHIVE but just for either server or client.

Here's the latest for the gamemode patch. It's not heavily tested, so there might be a few bugs with it. But overall it's pretty smooth.