UT2004 Query Protocol – Practical Reference
This document describes the Unreal Tournament 2004 (UT2004) UDP query protocol as observed from real server responses. It focuses on three key query types: Server Info, Server Rules, and Player List. All examples below are based on actual captured packets and include decoded values for clarity.
Note: All packets shown are sent via UDP to the server’s query port (typically gameport + 1).
Hex values are written as space-separated byte pairs, and numeric values are little-endian unless stated otherwise.
Ignored values are likely unknown or unused fields and can be treated as padding or reserved data.
1. Client Query Packets
The client sends small 5-byte packets to request information from the UT2004 server. The first byte is always
0x79, followed by four bytes indicating the query type.
| Purpose | Hex Packet | Description |
|---|---|---|
| Server Info | 79 00 00 00 00 |
Requests basic server information such as hostname, map, game type, and player counts. |
| Server Rules | 79 00 00 00 01 |
Returns key/value pairs describing server settings (mutators, limits, modes, etc.). |
| Player List (Single Packet) | 79 00 00 00 02 |
Returns a single player list packet. |
| Player List (Multi‑Packet) | 79 00 00 00 03 |
Returns two packets: rules (0x01) and players (0x02). |
2. Common Response Header
All UT2004 query responses begin with a 5-byte header. The first four bytes are a fixed signature
80 00 00 00. The fifth byte indicates the response type.
| Response Type | Header Hex | Meaning |
|---|---|---|
| Server Info | 80 00 00 00 00 |
Response to the Server Info query. |
| Server Rules | 80 00 00 00 01 |
Response to the Server Rules query. |
| Player List | 80 00 00 00 02 |
Response to the Player List query. |
3. Server Info Response (Decoded)
The Server Info response provides hostname, map, game type, and player counts. Below is a captured example with key
fields decoded. Length-prefixed strings use: [length][ASCII bytes][00].
80 00 00 00 00 00 00 00 00 00 00 6C 1E 00 00 00 00 00 00 18 47 72 69 6D 6D 73 2D 49 6E 73 74 61 2D 44 65 61 74 68 6D 61 74 63 68 00 10 44 4D 2D 31 6F 6E 31 2D 53 71 75 61 64 65 72 00 0C 78 44 65 61 74 68 4D 61 74 63 68 00 04 00 00 00 0A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 30 00 00 00
3.1 Decoded Fields
| Field | Raw Bytes | Decoded Value / Meaning |
|---|---|---|
| Header | 80 00 00 00 00 |
Server Info response header. |
| Unknown block 1 | 00 00 00 00 00 00 |
Ignored (likely unknown or unused). |
| Unknown block 2 | 6C 1E 00 00 00 00 00 00 |
Ignored (likely unknown or unused). |
| Hostname length | 18 |
24 bytes follow for hostname (excluding the null terminator in the count). |
| Hostname | 47 72 69 6D ... 63 68 00 |
Grimms-Insta-Deathmatch |
| Map name length | 10 |
16 bytes follow for map name. |
| Map name | 44 4D 2D 31 6F 6E 31 2D 53 71 75 61 64 65 72 00 |
DM-1on1-Squader |
| Game type length | 0C |
12 bytes follow for game type. |
| Game type | 78 44 65 61 74 68 4D 61 74 63 68 00 |
xDeathMatch |
| Current players | 04 00 00 00 |
4 players online. |
| Max players | 0A 00 00 00 |
10 player slots. |
| Trailing block | 00 ... 30 00 00 00 |
Ignored (likely unknown or unused). |
4. Server Rules Response (Decoded)
The Server Rules response returns a list of key/value pairs. Each key and value is stored as a length-prefixed ASCII string followed by a null terminator:
- 1 byte: length of key
- N bytes: key
- 1 byte: 0x00 (null terminator)
- 1 byte: length of value
- M bytes: value
- 1 byte: 0x00 (null terminator)
80 00 00 00 01 0B 53 65 72 76 65 72 4D 6F 64 65 00 0A 64 65 64 69 63 61 74 65 64 00 0A 41 64 6D 69 6E 4E 61 6D 65 00 06 47 72 69 6D 6D 00 0B 41 64 6D 69 6E 45 6D 61 69 6C 00 00 0E 53 65 72 76 65 72 56 65 72 73 69 6F 6E 00 05 33 33 33 39 00 0A 47 61 6D 65 53 74 61 74 73 00 06 46 61 6C 73 65 00 0E 4D 61 78 53 70 65 63 74 61 74 6F 72 73 00 02 32 00 0A 4D 61 70 56 6F 74 69 6E 67 00 05 74 72 75 65 00 0B 4B 69 63 6B 56 6F 74 69 6E 67 00 06 66 61 6C 73 65 00 08 4D 75 74 61 74 6F 72 00 0C 4D 75 74 49 6E 73 74 61 47 69 62 00 0B 4D 69 6E 50 6C 61 79 65 72 73 00 02 34 00 0D 45 6E 64 54 69 6D 65 44 65 6C 61 79 00 05 34 2E 30 30 00 0A 47 6F 61 6C 53 63 6F 72 65 00 03 33 30 00 0A 54 69 6D 65 4C 69 6D 69 74 00 03 31 35 00 0D 54 72 61 6E 73 6C 6F 63 61 74 6F 72 00 06 46 61 6C 73 65 00 0B 57 65 61 70 6F 6E 53 74 61 79 00 06 46 61 6C 73 65 00 0D 46 6F 72 63 65 52 65 73 70 61 77 6E 00 06 46 61 6C 73 65 00 08 6D 75 74 61 74 6F 72 00 0A 44 4D 4D 75 74 61 74 6F 72 00
4.1 Decoded Key/Value Pairs
| Key | Value |
|---|---|
| ServerMode | dedicated |
| AdminName | Grimm |
| AdminEmail | (empty) |
| ServerVersion | 3339 |
| GameStats | False |
| MaxSpectators | 2 |
| MapVoting | true |
| KickVoting | false |
| Mutator | MutInstaGib / DMMutator |
| MinPlayers | 4 |
| EndTimeDelay | 4.00 |
| GoalScore | 30 |
| TimeLimit | 15 |
| Translocator | False |
| WeaponStay | False |
5. Player List Response (Decoded)
The Player List response returns one or more player records. Each record has a fixed structure following the common Player List header.
80 00 00 00 02 07 00 00 00 0B 49 6C 6F 76 65 64 69 63 6B 73 00 1C 00 00 00 00 00 00 00 00 00 00 00
5.1 Player Entry Structure
- Header (packet):
80 00 00 00 02(Player List response) - 4 bytes: Unknown / skip (ignored)
- 1 byte:
nameLen(name length including null terminator) - nameLen bytes: ASCII name followed by
00 - 4 bytes: Ping (32-bit little-endian)
- 4 bytes: Score (32-bit little-endian)
- 4 bytes: Unknown / skip (ignored)
5.2 Decoded Player Example
| Field | Raw Bytes | Decoded Value / Meaning |
|---|---|---|
| Header | 80 00 00 00 02 |
Player List response header. |
| Skip (unknown) | 07 00 00 00 |
Ignored (likely unknown / unused). |
| Name length | 0B |
11 bytes including null terminator. |
| Name | 49 6C 6F 76 65 64 69 63 6B 73 00 |
“Ilovedicks” (null-terminated string, dont ask). |
| Ping | 1C 00 00 00 |
28 ms (0x1C in little-endian). |
| Score | 00 00 00 00 |
0 (no score). |
| Trailing skip | 00 00 00 00 |
Ignored (likely padding / unused). |
6. Multi‑Packet Player Query (0x03)
Unreal Tournament 2004 supports a multi‑packet version of the player list query using the packet:
79 00 00 00 03.
Unlike the standard single‑packet player query (0x02), this version returns two separate packets.
The client must continue reading until the final packet is received.
Note: Multi‑packet responses always end with a packet whose header byte is
0x02.
Any earlier packets (usually one) will use header 0x01.
Ignored values are likely unknown or unused fields.
6.1 Multi‑Packet Query Request
| Purpose | Hex Packet | Description |
|---|---|---|
| Player List (Multi‑Packet) | 79 00 00 00 03 |
Requests the extended multi‑packet player list. |
6.2 Response Structure
The server responds with two packets:
- Packet 1: Header
80 00 00 00 01— contains server rules (same as0x01query) - Packet 2: Header
80 00 00 00 02— contains the actual player list
The client must continue receiving packets until the final header 0x02 is encountered.
6.3 Example Multi‑Packet Response (Captured)
Below is a real multi‑packet response captured from a UT2004 server.
Packet 1 — Rules (Header 0x01)
80 00 00 00 01 0B 53 65 72 76 65 72 4D 6F 64 65 00 0A 64 65 64 69 63 61 74 65 64 00 0A 41 64 6D 69 6E 4E 61 6D 65 00 06 47 72 69 6D 6D 00 0B 41 64 6D 69 6E 45 6D 61 69 6C 00 00 0E 53 65 72 76 65 72 56 65 72 73 69 6F 6E 00 05 33 33 33 39 00 ...
Packet 2 — Player List (Header 0x02)
80 00 00 00 02 00 00 00 00 0B 49 6C 6F 76 65 64 69 63 6B 73 00 1C 00 00 00 06 00 00 00 00 00 00 00
6.4 Client Handling Requirements
- The client must keep reading packets until the final header
0x02is received. - Packet 1 (
0x01) contains rules, not players. - Packet 2 (
0x02) contains the actual player list. - Ignored values are likely unknown or unused fields.
This multi‑packet behavior is required for some servers and mods, and must be supported by any UT2004 query tool.
