Client message format

From ioquake3 wiki
Jump to: navigation, search

At its basic level, a client message consists of the server ID, the sequence number of the last server netchan message received, the ID of the last server command received, a list of client commands, and optional movement data. Since there can be a variable number of client commands and the movement data is optional, these operations start with an 8-bit identifier code to disambiguate between them. The end of the list is identified with a special EOF code.


top-level format

32 bits server ID
32 bits sequence number of last server netchan message received
32 bits ID of last server command received
(<move> | <move-no-delta>)?
8 bits 0x05 EOF indicator


8 bits 0x04 client-command indicator
32 bits command ID
string command


8 bits 0x02 move indicator


8 bits 0x03 move-no-delta indicator


8 bits num user commands
loop {num user commands} times:
1 bit time-is-delta indicator
if time-is-delta == 0x1:
8 bits time delta
32 bits time
1 bit changed-command indicator
if changed-command == 0x1:
1 bit angle-0-changed indicator
if angle-0-changed == 0x1:
16 bits encoded angle[0] value
1 bit angle-1-changed indicator
if angle-1-changed == 0x1:
16 bits encoded angle[1] value
1 bit angle-2-changed indicator
if angle-2-changed == 0x1:
16 bits encoded angle[2] value
1 bit forward-moved indicator
if forward-moved == 0x1:
8 bits encoded forward move value
1 bit right-moved indicator
if right-moved == 0x1:
8 bits encoded right move value
1 bit up-moved indicator
if up-moved == 0x1:
8 bits encoded up move value
1 bit buttons-changed indicator
if buttons-changed == 0x1:
16 bits encoded buttons value
1 bit weapon-changed indicator
if weapon-changed == 0x1:
8 bits encoded weapon value

User command values are doubly-encoded with a key that is different than the key used to encode the entire netchan message. Also, unlike the netchan message encoding, the values are encoded before they are compressed. This second key is generated by xor'ing the netchan message key with the time value. See MSG_WriteDeltaUsercmdKey() and CL_WritePacket() for details.


One interesting effect of encoding the user command values is that because they are encoded before they are compressed, it potentially degrades the compressibility of the values. If, however, the values are effectively random numbers to begin with, then they aren't very compressible anyway, so encoding them wouldn't hurt much.

One suspects that user command encoding is a remnant of legacy code. It seems as if user commands alone were encoded in earlier versions of the code. Later versions may have then encoded the entire message after compression, but left this existing code in place.

See also