Client message format

From ioquake3 wiki

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.

Contents 1 Structures 1.1 top-level format 1.2 client-command 1.3 move 1.4 move-no-delta 1.5 user-commands 1.5.1 comments 2 See also

Structures

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
<client-command>*
(<move> | <move-no-delta>)?
8 bits	0x05 EOF indicator

client-command

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

move

8 bits	0x02 move indicator
<user-commands>

move-no-delta

8 bits	0x03 move-no-delta indicator
<user-commands>

user-commands

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 else: 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.

comments

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

• Netchan message
• Server message format