This document is incomplete, inaccurate and only applies to versions 0.91, 0.92, 1.00 and 1.01 of QUAKE. The data on this document was gathered from mail/postings by John Cash of idsoftware and studying data from the wires.
QUAKE uses UDP only -- meaning packets may get lost in transit. All numbers are in big-endian order unless otherwise stated.
Remember that this is all subject to change, but we'll only change it to make it better. And please don't ask why some of this is the way that it is. -- John Cash.
All packets start with a 4-byte header. The first 2 bytes is the packet type. The next 2 bytes is the packet length, including the header.
type name value short packet_type packet type short packet_len packet length including headerThe known packet types are:
0x80 0x00 - Control Packet 0x00 0x01 - Reliable? Packet (message block chunk) 0x00 0x09 - Reliable? Packet (end of message block) 0x00 0x02 - Reliable? Packet Acknowledgement 0x00 0x10 - Unreliable? Packet
The operation code of the control packet is specified by a single byte following the packet header. There are 9 known types of control packets: 4 requests and 5 responses. Control packets are sent to the UDP port 26000 (default) of the server.
short packet_type 0x8000 - Control Packet short packet_len packet length including header byte operation_code operation code ...
byte operation_code 0x01 - CCREQ_CONNECT string game_name "QUAKE" byte net_protocol_version NET_PROTOCOL_VERSIONSample byte stream:
80 00 00 0c 01 51 55 41 4b 45 00 03Connection Request Replies
The port number is used by the client for sending/receiving game packets.
The port number given by the server
byte operation_code 0x81 - CCREP_ACCEPT short port UDP port number to use (little-endian) short unknown unknownSample byte stream:
80 00 00 09 81 34 12 ?? ??
byte operation_code 0x82 - CCREP_REJECT string reason reason for rejectionSample byte stream:
80 00 00 1c 82 49 6e 63 6f 6d 70 61 74 69 62 6c 65 20 76 65 72 73 69 6f 6e 2e 0a 00
byte operation_code 0x02 - CCREQ_SERVER_INFO string game_name "QUAKE" byte net_protocol_version NET_PROTOCOL_VERSIONSample byte stream:
80 00 00 0c 02 51 55 41 4b 45 00 03Server Info Reply
byte operation_code 0x83 - CCREP_SERVER_INFO address server_address IP:port number of server string host_name from the console command hostname string level_name current map on the server byte current_players 0-16 - current number of players byte max_players 0-16 - maximum number of players byte net_protocol_version NET_PROTOCOL_VERSIONSample byte stream:
80 00 00 2b 83 31 36 35 2e 32 32 30 2e 31 36 2e 36 3a 32 36 30 30 30 00 6e 6f 69 64 65 6e 74 69 74 79 00 65 31 6d 32 00 04 08 03The Network Protocol Version "is there both directions so we can upgrade the network protocol and have the option of supporting older versions".
byte operation_code 0x03 - CCREQ_PLAYER_INFO byte player_number 0-15Player Info Reply
shirt_color and pants_color range from 0-13. frags and connect_time are in little-endian order. frags is a signed number. Typing "TEST servername" from the console (while connected to the server) will display this info. (all the players?) --FIX
byte operation_code 0x84 - CCREP_PLAYER_INFO byte player_number 0-15 string name name/alias of the player byte colors (shirt_color << 4) + pants_color byte unused ? byte unused ? byte unused ? long frags number of frags (little-endian) long connect_time connection time (secs)(little-endian) address client_address IP:port (local, IPX#, serial port?)
byte operation_code 0x04 - CCREQ_RULE_INFO string rule rule nameRule Info Reply
byte operation_code 0x85 - CCREP_RULE_INFO string rule rule name string value value of the ruleYou must first issue a request with the null rulename to get the first variable:
80 00 00 06 04 00The server will reply with a rulename which you must use for the next request. You will get a reply packet with only 5 bytes if no more rules are available for query:
80 00 00 05 85Ugly, but that's how it works. -- Cash
Typing "TEST2 servername" from the console of the client (while connected to the server) will display this info.
Game packets contain a 4-byte packet number, immediately following the packet length. For reliable and unreliable packets, following the packet number is the message block, which is contain messages that are identical (server to client only?) with the DEM format description by Uwe Girlich.
Game packets use the port number from the Connection Accepted reply of the server.
Packet numbers start from zero (0) (wrap?). The client and server keep track of four packet numbers (incoming/outgoing reliable/unreliable streams).
short packet_type 0x0001 or 0x0009 - Reliable Packet short packet_len packet length including header long packet_number serial packet number mesgblk message_block message block composed of message(s)
A reliable packet has a packet type of 0x0001 or 0x0009. If the message block is long (>1024), it will be split into 1024 byte chunks (packet length == 1032) with a packet type of 0x0001. The last chunk will have a packet type of 0x0009. Message blocks with less than or equal to 1024 bytes have a packet type of 0x0009.
Reliable Packet Acknowledegemnt
Reliable packets are acknowledged by an 8-byte 0x0002 type packet. The packet number of the last received reliable packet is included in the acknowledgement. (window?)
short packet_type 0x0002 - Reliable Packet Ack short packet_len 0x08 - packet length including header long packet_number packet number of last recvd reliable packet
Unreliable packets are used for non-critical game data. The sender does not require any acknowledgement for the packet. The only known client to server message type that uses unreliable packets is 0x03.
short packet_type 0x0010 - Unreliable Packet short packet_len packet length including header long packet_number serial packet number mesgblk message_block message block composed of message(s)
Following the packet number in reliable and unreliable packets is the message block. A message consists of a one-byte message type followed by the message data. A message block is composed of several variable length messages.
mesg message1 message mesg message2 message mesg message3 message ... mesg messageN messageMessage
byte message_type type of message mesgdata message_data message dataServer to Client Messages
Server to client messages are identical to the messages in the DEM format description.
Client to Server Messages
Little is known of the messages from client to server.
Client to Server Message Types
byte message_type 0x04 - Execute Command string command server command
All numbers are in big-endian, unless otherwise stated.
byte 8 bits short 2 bytes long 4 bytes mesgblk see message block mesgdata variable length, depends on message type mesg variable length, depends on message type string null-terminated string address null terminated string connect type format sample string local "LOCAL" "LOCAL" TCP/IP IP:port "188.8.131.52:1037" IPX IPX address "00000002:0020AF6D6733" serial ??? ???
value QUAKE version 0x01 qtest1 0x02 unknown 0x03 0.91, 0.92, 1.00, 1.01
# R G B desc 0 123 123 123 gray 1 83 59 27 brown 2 79 79 115 blue-violet? 3 55 55 7 green? 4 71 0 0 red 5 95 71 7 ? 6 143 67 51 ? 7 127 83 63 light brown 8 87 55 67 violet? 9 95 51 63 ? 10 107 87 71 ? 11 47 67 55 green? 12 123 99 7 yellow 13 47 47 127 blue