{"id":1625,"date":"2026-01-01T23:17:35","date_gmt":"2026-01-01T23:17:35","guid":{"rendered":"https:\/\/grimms3dworlds.ddns.net\/?page_id=1625"},"modified":"2026-01-02T01:20:31","modified_gmt":"2026-01-02T01:20:31","slug":"1625-2","status":"publish","type":"page","link":"https:\/\/grimms3dworlds.ddns.net\/index.php\/1625-2\/","title":{"rendered":""},"content":{"rendered":"\n
\n\n

\n UT2004 Query Protocol \u2013 Practical Reference\n <\/h1>\n\n

\n This document describes the Unreal Tournament 2004 (UT2004) UDP query protocol as observed from real server responses.\n It focuses on three key query types: Server Info<\/strong>, Server Rules<\/strong>, and Player List<\/strong>.\n All examples below are based on actual captured packets and include decoded values for clarity.\n <\/p>\n\n

\n Note:<\/strong> All packets shown are sent via UDP to the server\u2019s query port (typically gameport + 1).\n Hex values are written as space-separated byte pairs, and numeric values are little-endian unless stated otherwise.\n

\n Ignored values are likely unknown or unused fields and can be treated as padding or reserved data.<\/strong>\n <\/p>\n\n \n\n

\n 1. Client Query Packets\n <\/h2>\n\n

\n The client sends small 5-byte packets to request information from the UT2004 server. The first byte is always\n 0x79<\/code>, followed by four bytes indicating the query type.\n <\/p>\n\n \n \n \n \n \n \n \n \n
Purpose<\/th>\n Hex Packet<\/th>\n Description<\/th>\n <\/tr>\n <\/thead>\n
Server Info<\/td>\n 79 00 00 00 00<\/code><\/td>\n Requests basic server information such as hostname, map, game type, and player counts.<\/td>\n <\/tr>\n
Server Rules<\/td>\n 79 00 00 00 01<\/code><\/td>\n Returns key\/value pairs describing server settings (mutators, limits, modes, etc.).<\/td>\n <\/tr>\n
Player List (Single Packet)<\/td>\n 79 00 00 00 02<\/code><\/td>\n Returns a single player list packet.<\/td>\n <\/tr>\n
Player List (Multi\u2011Packet)<\/strong><\/td>\n 79 00 00 00 03<\/code><\/strong><\/td>\n Returns two packets: rules (0x01) and players (0x02).<\/strong><\/td>\n <\/tr>\n <\/tbody>\n <\/table>\n\n\n\n \n\n

\n 2. Common Response Header\n <\/h2>\n\n

\n All UT2004 query responses begin with a 5-byte header. The first four bytes are a fixed signature\n 80 00 00 00<\/code>. The fifth byte indicates the response type.\n <\/p>\n\n \n \n \n \n \n \n \n
Response Type<\/th>\n Header Hex<\/th>\n Meaning<\/th>\n <\/tr>\n <\/thead>\n
Server Info<\/td>\n 80 00 00 00 00<\/code><\/td>\n Response to the Server Info query.<\/td>\n <\/tr>\n
Server Rules<\/td>\n 80 00 00 00 01<\/code><\/td>\n Response to the Server Rules query.<\/td>\n <\/tr>\n
Player List<\/td>\n 80 00 00 00 02<\/code><\/td>\n Response to the Player List query.<\/td>\n <\/tr>\n <\/tbody>\n <\/table>\n\n \n\n

\n 3. Server Info Response (Decoded)\n <\/h2>\n\n

\n The Server Info response provides hostname, map, game type, and player counts. Below is a captured example with key\n fields decoded. Length-prefixed strings use: [length][ASCII bytes][00]<\/code>.\n <\/p>\n\n 

\n80 00 00 00 00\n00 00 00 00 00 00\n6C 1E 00 00 00 00 00 00\n18 47 72 69 6D 6D 73 2D 49 6E 73 74 61 2D 44 65 61 74 68 6D 61 74 63 68 00\n10 44 4D 2D 31 6F 6E 31 2D 53 71 75 61 64 65 72 00\n0C 78 44 65 61 74 68 4D 61 74 63 68 00\n04 00 00 00\n0A 00 00 00\n00 00 00 00 00 00 00 00 00 00 00 02 30 00 00 00\n<\/pre>\n\n    
\n        3.1 Decoded Fields\n    <\/h3>\n\n    \n        \n            \n                \n            \n                \n                \n                \n                \n                \n                \n                \n                \n                \n                \n                \n                
Field<\/th>\n                Raw Bytes<\/th>\n                Decoded Value \/ Meaning<\/th>\n            <\/tr>\n        <\/thead>\n        
Header<\/td>\n                80 00 00 00 00<\/code><\/td>\n                Server Info response header.<\/td>\n            <\/tr>\n            
Unknown block 1<\/td>\n                00 00 00 00 00 00<\/code><\/td>\n                Ignored (likely unknown or unused).<\/td>\n            <\/tr>\n            
Unknown block 2<\/td>\n                6C 1E 00 00 00 00 00 00<\/code><\/td>\n                Ignored (likely unknown or unused).<\/td>\n            <\/tr>\n            
Hostname length<\/td>\n                18<\/code><\/td>\n                24 bytes follow for hostname (excluding the null terminator in the count).<\/td>\n            <\/tr>\n            
Hostname<\/td>\n                47 72 69 6D ... 63 68 00<\/code><\/td>\n                Grimms-Insta-Deathmatch<\/td>\n            <\/tr>\n            
Map name length<\/td>\n                10<\/code><\/td>\n                16 bytes follow for map name.<\/td>\n            <\/tr>\n            
Map name<\/td>\n                44 4D 2D 31 6F 6E 31 2D 53 71 75 61 64 65 72 00<\/code><\/td>\n                DM-1on1-Squader<\/td>\n            <\/tr>\n            
Game type length<\/td>\n                0C<\/code><\/td>\n                12 bytes follow for game type.<\/td>\n            <\/tr>\n            
Game type<\/td>\n                78 44 65 61 74 68 4D 61 74 63 68 00<\/code><\/td>\n                xDeathMatch<\/td>\n            <\/tr>\n            
Current players<\/td>\n                04 00 00 00<\/code><\/td>\n                4 players online.<\/td>\n            <\/tr>\n            
Max players<\/td>\n                0A 00 00 00<\/code><\/td>\n                10 player slots.<\/td>\n            <\/tr>\n            
Trailing block<\/td>\n                00 ... 30 00 00 00<\/code><\/td>\n                Ignored (likely unknown or unused).<\/td>\n            <\/tr>\n        <\/tbody>\n    <\/table>\n\n    \n\n    
\n        4. Server Rules Response (Decoded)\n    <\/h2>\n\n    
\n        The Server Rules response returns a list of key\/value pairs. Each key and value is stored as a\n        length-prefixed ASCII string followed by a null terminator:\n    <\/p>\n\n    
    \n        
  • 1 byte:<\/strong> length of key<\/li>\n        
  • N bytes:<\/strong> key<\/li>\n        
  • 1 byte:<\/strong> 0x00 (null terminator)<\/li>\n        
  • 1 byte:<\/strong> length of value<\/li>\n        
  • M bytes:<\/strong> value<\/li>\n        
  • 1 byte:<\/strong> 0x00 (null terminator)<\/li>\n    <\/ul>\n\n    
    \n80 00 00 00 01\n0B 53 65 72 76 65 72 4D 6F 64 65 00 0A 64 65 64 69 63 61 74 65 64 00\n0A 41 64 6D 69 6E 4E 61 6D 65 00 06 47 72 69 6D 6D 00\n0B 41 64 6D 69 6E 45 6D 61 69 6C 00 00\n0E 53 65 72 76 65 72 56 65 72 73 69 6F 6E 00 05 33 33 33 39 00\n0A 47 61 6D 65 53 74 61 74 73 00 06 46 61 6C 73 65 00\n0E 4D 61 78 53 70 65 63 74 61 74 6F 72 73 00 02 32 00\n0A 4D 61 70 56 6F 74 69 6E 67 00 05 74 72 75 65 00\n0B 4B 69 63 6B 56 6F 74 69 6E 67 00 06 66 61 6C 73 65 00\n08 4D 75 74 61 74 6F 72 00 0C 4D 75 74 49 6E 73 74 61 47 69 62 00\n0B 4D 69 6E 50 6C 61 79 65 72 73 00 02 34 00\n0D 45 6E 64 54 69 6D 65 44 65 6C 61 79 00 05 34 2E 30 30 00\n0A 47 6F 61 6C 53 63 6F 72 65 00 03 33 30 00\n0A 54 69 6D 65 4C 69 6D 69 74 00 03 31 35 00\n0D 54 72 61 6E 73 6C 6F 63 61 74 6F 72 00 06 46 61 6C 73 65 00\n0B 57 65 61 70 6F 6E 53 74 61 79 00 06 46 61 6C 73 65 00\n0D 46 6F 72 63 65 52 65 73 70 61 77 6E 00 06 46 61 6C 73 65 00\n08 6D 75 74 61 74 6F 72 00 0A 44 4D 4D 75 74 61 74 6F 72 00\n<\/pre>\n\n    
    \n        4.1 Decoded Key\/Value Pairs\n    <\/h3>\n\n    \n        \n            \n                \n            
    Key<\/th>\n                Value<\/th>\n            <\/tr>\n        <\/thead>\n        
    ServerMode<\/td>dedicated<\/td><\/tr>\n            
    AdminName<\/td>Grimm<\/td><\/tr>\n            
    AdminEmail<\/td>(empty)<\/td><\/tr>\n            
    ServerVersion<\/td>3339<\/td><\/tr>\n            
    GameStats<\/td>False<\/td><\/tr>\n            
    MaxSpectators<\/td>2<\/td><\/tr>\n            
    MapVoting<\/td>true<\/td><\/tr>\n            
    KickVoting<\/td>false<\/td><\/tr>\n            
    Mutator<\/td>MutInstaGib \/ DMMutator<\/td><\/tr>\n            
    MinPlayers<\/td>4<\/td><\/tr>\n            
    EndTimeDelay<\/td>4.00<\/td><\/tr>\n            
    GoalScore<\/td>30<\/td><\/tr>\n            
    TimeLimit<\/td>15<\/td><\/tr>\n            
    Translocator<\/td>False<\/td><\/tr>\n            
    WeaponStay<\/td>False<\/td><\/tr>\n        <\/tbody>\n    <\/table>\n\n    \n\n    
    \n        5. Player List Response (Decoded)\n    <\/h2>\n\n    
    \n        The Player List response returns one or more player records. Each record has a fixed structure following the\n        common Player List header.\n    <\/p>\n\n    
    \n80 00 00 00 02\n07 00 00 00\n0B 49 6C 6F 76 65 64 69 63 6B 73 00\n1C 00 00 00\n00 00 00 00\n00 00 00 00\n<\/pre>\n\n    
    \n        5.1 Player Entry Structure\n    <\/h3>\n\n    
      \n        
    • Header (packet):<\/strong> 80 00 00 00 02<\/code> (Player List response)<\/li>\n        
    • 4 bytes:<\/strong> Unknown \/ skip (ignored)<\/li>\n        
    • 1 byte:<\/strong> nameLen<\/code> (name length including null terminator)<\/li>\n        
    • nameLen bytes:<\/strong> ASCII name followed by 00<\/code><\/li>\n        
    • 4 bytes:<\/strong> Ping (32-bit little-endian)<\/li>\n        
    • 4 bytes:<\/strong> Score (32-bit little-endian)<\/li>\n        
    • 4 bytes:<\/strong> Unknown \/ skip (ignored)<\/li>\n    <\/ul>\n\n    
      \n        5.2 Decoded Player Example\n    <\/h3>\n\n    \n        \n            \n                \n            \n                \n                \n                \n                \n                \n                \n                
      Field<\/th>\n                Raw Bytes<\/th>\n                Decoded Value \/ Meaning<\/th>\n            <\/tr>\n        <\/thead>\n        
      Header<\/td>\n                80 00 00 00 02<\/code><\/td>\n                Player List response header.<\/td>\n            <\/tr>\n            
      Skip (unknown)<\/td>\n                07 00 00 00<\/code><\/td>\n                Ignored (likely unknown \/ unused).<\/td>\n            <\/tr>\n            
      Name length<\/td>\n                0B<\/code><\/td>\n                11 bytes including null terminator.<\/td>\n            <\/tr>\n            
      Name<\/td>\n                49 6C 6F 76 65 64 69 63 6B 73 00<\/code><\/td>\n                “Ilovedicks” (null-terminated string, dont ask).<\/td>\n            <\/tr>\n            
      Ping<\/td>\n                1C 00 00 00<\/code><\/td>\n                28 ms (0x1C in little-endian).<\/td>\n            <\/tr>\n            
      Score<\/td>\n                00 00 00 00<\/code><\/td>\n                0 (no score).<\/td>\n            <\/tr>\n            
      Trailing skip<\/td>\n                00 00 00 00<\/code><\/td>\n                Ignored (likely padding \/ unused).<\/td>\n            <\/tr>\n        <\/tbody>\n    <\/table>\n
      \n    6. Multi\u2011Packet Player Query (0x03)\n<\/h2>\n\n
      \n    Unreal Tournament 2004 supports a multi\u2011packet version of the player list query using the packet:\n    79 00 00 00 03<\/code>.  \n    Unlike the standard single\u2011packet player query (0x02<\/code>), this version returns two separate packets<\/strong>.\n    The client must continue reading until the final packet is received.\n<\/p>\n\n
      \n    Note:<\/strong> Multi\u2011packet responses always end with a packet whose header byte is\n    0x02<\/code>.  \n    Any earlier packets (usually one) will use header 0x01<\/code>.  \n    Ignored values are likely unknown or unused fields.\n<\/p>\n\n
      \n    6.1 Multi\u2011Packet Query Request\n<\/h3>\n\n\n    \n        \n            \n        \n            
      Purpose<\/th>\n            Hex Packet<\/th>\n            Description<\/th>\n        <\/tr>\n    <\/thead>\n    
      Player List (Multi\u2011Packet)<\/td>\n            79 00 00 00 03<\/code><\/td>\n            Requests the extended multi\u2011packet player list.<\/td>\n        <\/tr>\n    <\/tbody>\n<\/table>\n\n
      \n    6.2 Response Structure\n<\/h3>\n\n
      \n    The server responds with two packets<\/strong>:\n<\/p>\n\n
        \n    
      • Packet 1:<\/strong> Header 80 00 00 00 01<\/code> \u2014 contains server rules (same as 0x01<\/code> query)<\/li>\n    
      • Packet 2:<\/strong> Header 80 00 00 00 02<\/code> \u2014 contains the actual player list<\/li>\n<\/ul>\n\n
        \n    The client must continue receiving packets until the final header 0x02<\/code> is encountered.\n<\/p>\n\n
        \n    6.3 Example Multi\u2011Packet Response (Captured)\n<\/h3>\n\n
        \n    Below is a real multi\u2011packet response captured from a UT2004 server.\n<\/p>\n\n
        Packet 1 \u2014 Rules (Header 0x01)<\/h4>\n\n
        \n80 00 00 00 01\n0B 53 65 72 76 65 72 4D 6F 64 65 00 0A 64 65 64 69 63 61 74 65 64 00\n0A 41 64 6D 69 6E 4E 61 6D 65 00 06 47 72 69 6D 6D 00\n0B 41 64 6D 69 6E 45 6D 61 69 6C 00 00\n0E 53 65 72 76 65 72 56 65 72 73 69 6F 6E 00 05 33 33 33 39 00\n...\n<\/pre>\n\n
        Packet 2 \u2014 Player List (Header 0x02)<\/h4>\n\n
        \n80 00 00 00 02\n00 00 00 00\n0B 49 6C 6F 76 65 64 69 63 6B 73 00\n1C 00 00 00\n06 00 00 00\n00 00 00 00\n<\/pre>\n\n
        \n    6.4 Client Handling Requirements\n<\/h3>\n\n
          \n    
        • The client must keep reading packets until the final header 0x02<\/code> is received.<\/li>\n    
        • Packet 1 (0x01<\/code>) contains rules, not players.<\/li>\n    
        • Packet 2 (0x02<\/code>) contains the actual player list.<\/li>\n    
        • Ignored values are likely unknown or unused fields.<\/li>\n<\/ul>\n\n
          \n    This multi\u2011packet behavior is required for some servers and mods, and must be supported by any UT2004 query tool.\n<\/p>\n\n<\/div>\n\n\n\n
          <\/p>\n","protected":false},"excerpt":{"rendered":"
          UT2004 Query Protocol \u2013 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 […]<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-1625","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/grimms3dworlds.ddns.net\/index.php\/wp-json\/wp\/v2\/pages\/1625","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/grimms3dworlds.ddns.net\/index.php\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/grimms3dworlds.ddns.net\/index.php\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/grimms3dworlds.ddns.net\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/grimms3dworlds.ddns.net\/index.php\/wp-json\/wp\/v2\/comments?post=1625"}],"version-history":[{"count":8,"href":"https:\/\/grimms3dworlds.ddns.net\/index.php\/wp-json\/wp\/v2\/pages\/1625\/revisions"}],"predecessor-version":[{"id":1644,"href":"https:\/\/grimms3dworlds.ddns.net\/index.php\/wp-json\/wp\/v2\/pages\/1625\/revisions\/1644"}],"wp:attachment":[{"href":"https:\/\/grimms3dworlds.ddns.net\/index.php\/wp-json\/wp\/v2\/media?parent=1625"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}