Message Boards

We have a bit of a situation regarding the launcher protocol it seems, here is a small list of issues I have outlined below:

• Client uses exactly the same information as the launcher does, (probably implementation from the old csdoom days), so if we change information for the launcher, we could break the client (or vice versa) if we change it
• Current protocol has no real versioning and is a mess, period.

So firstly we need to create a new function in the server for new protocol requests and keep the old one for backwards compatibility between old clients and launchers (0.4.0 and 0.4.1 for now)

After that, it gets trickier, you can have a look at the current proposed solution for above when I post it soon

EDIT: Just to clear things up, there is no intention of getting rid or changing the latter, the old function will still exist and remain the same until we decide to dump it.

Client uses exactly the same information as the launcher does, (probably implementation from the old csdoom days)

fyi, csdoom client didn't have this feature, but it is quite old :)

Cool :)

A bit of work went into the versioning thing, which allows us to have:

255 major versions
255 minor "    "
255 patch "    "
and 65535 launcher protocol versions under 1 minor version.

More or less ;)

I don't know what to include in the contents of the packet yet for the first version, the arbitrary length cvar field was included at the last minute. It makes a couple of things above it redundant though.

So, open to ideas :P

I agree...

Also, you may want to include masking, maybe 2 32-bit fields for 64-flags that it can be kept simple. The Server list the main page doesn't care for scores and all, maybe send RQ_SERVERNAME and just get the server name back, same can also go for launchers (i.e. partial refresh instead of a full one) then send the mask back of what is actually in that packet data. Can also save some space for useless stuff like in DM who cares for team scores yknow?.

Omission/inclusion of fields based on masks can complicate:
1) We may or may not include a field in the next protocol version (eg included/removed team scores), then we have to say that the flag is available/not
2) If that were the case, we would also have to maintain a list of flags supported for each protocol version in the current minor version we are working with

However, you are right in that it would leave more space for certain game modes to have more information available later on.

It isn't necessarily a bad idea and it can always be added in later on (thanks to versioning)

EDIT: I found an article today which is "similar" to what we are discussing here: http://blogs.msdn.com/johnmil/archive/2006/01/11/511527.aspx

I can't see any obvious errors in it, though I have a suggestion for the master protocol if anyone's interested:

If it was changed to send each IP once with an array of ports, instead of sending a full ip+port for each server, the current server list would be about half the size. It's not much of a difference now but it might be useful later on.

From what you've got there, the total size only increases if the ip:server ratio is less than about 1:1.3. After that it's a gain.

I was thinking of it using 16-bit array sizes when I said about half in my first post, but nobody's ever going to run that many servers from one IP anyway.

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.

Would this be of any use here?