Message Boards

I think the layout of our server response packet structure could use a bit of organization for 0.5.

//--- Main Response
Tag - Unsigned 32bit Integer
Version - Unsigned 32bit Integer
Protocol version - Unsigned 32bit Integer

//--- Server information Related
Password MD5 hash - ASCIIZ String
Current map - ASCIIZ String
Time Left - Unsigned 16bit Integer

//--- CVAR Related
Cvar Count - Unsigned 8bit Integer
+Cvar name (Cvar Count) - ASCIIZ String
+Cvar value - ASCIIZ String

//--- WAD Related
WAD Count - Unsigned 8bit Integer
+WAD filename (WAD Count) - ASCIIZ String
+WAD MD5 Hash - ASCIIZ String

//--- Team Related
Teams Enabled - Boolean
Team Count - Unsigned 8bit Integer
+Team Name - ASCIIZ String
+Team Color - Unsigned 32bit Integer
+Team Score - Signed 16bit Integer

//--- Player Related
Player Count - Unsigned 8bit Integer
+Player Ping - Unsigned 16bit Integer
+Player Time - Unsigned 32bit Integer
+Spectator - Boolean
+Player Team - Unsigned 8bit Integer
+Player Color - Unsigned 32bit Integer
+Player Score - Signed 32bit Integer
+Player Fragcount - Unsigned 16bit Integer
+Player Deathcount - Unsigned 16bit Integer
You might notice some odd changes in here. They're optional, but here's why I did them:

* Now that we've made the team structure a little less hardcoded (with our teamsinplay cvar), we can treat the number of teams like we would number of cvars/wads/players. We should also be prepared if we want to make teams customizable to the server. (Custom names and colors... but CTF will still remain RED/BLUE)
* If it won't increase the size of the packets too much, I was thinking that the server could submit the color of each team and player to the launcher. I'm not sure if wx's Color (or Colour, it's very picky sometimes) supports RGB values, but it would be nice to support it. (Maybe add a color square next to the name a la the odascoreboard)
* Replaced player killcount with player score so we can use it for other game modes. Making it 32bit is overkill, I know, I'm just putting it in there in case we decide to further implement my "replace monster kills with damage inflicted" patch.
* I was thinking maybe we have player fragcount an unsigned value that doesn't decrease due to suicides and use player score for DM matches. (where it's the fragcount - suicides) Ralphis kinda doesn't like the idea of the scoreboard showing Score / Frags / Deaths instead of Frags / Deaths, so we could either disguise the scoreboard Frags as Score or make it optional to display Score / Deaths.

I don't think any of us have any idea what dynamic resolution is.

I agree with this.

Hey man, that's pretty cool.

We should also establish and document which of the server cvars can be read by the client, even if these cvars do nothing to the client.

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.

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.