Difference between revisions of "Pre-release protocol"

From wiki.vg
Jump to navigation Jump to search
Line 318: Line 318:
 
| class="col1 centeralign" | short
 
| class="col1 centeralign" | short
 
| class="col2 centeralign" | 15
 
| class="col2 centeralign" | 15
| class="col3" | Bitmask with 1 for every 16x16x16 chunk which data follows in Compressed data.
+
| class="col3" | Bitmask with 1 for every 16x16x16 chunk which data follows in the compressed data.
 
|- class="row5"
 
|- class="row5"
| class="col0 centeralign" | Unknown, secondary bit map
+
| class="col0 centeralign" | Add bit map
 
| class="col1 centeralign" | short
 
| class="col1 centeralign" | short
 
| class="col2 centeralign" | 0
 
| class="col2 centeralign" | 0
| class="col3" | I've only seen <code>0</code>. Used after (presumably) block ids, metadata, lighting, etc.
+
| class="col3" | Same as above, but this is used exclusively for the 'add' portion of the payload
 
|- class="row6"
 
|- class="row6"
 
| class="col0 centeralign" | Compressed size
 
| class="col0 centeralign" | Compressed size
Line 330: Line 330:
 
| class="col3" | Size of compressed region data.
 
| class="col3" | Size of compressed region data.
 
|- class="row7"
 
|- class="row7"
| class="col0 centeralign" | Unused Int
+
| class="col0 centeralign" | Unused int
 
| class="col1 centeralign" | int
 
| class="col1 centeralign" | int
 
| class="col2 centeralign" | 0
 
| class="col2 centeralign" | 0
Line 344: Line 344:
 
|}
 
|}
  
(Unconfirmed, guess) '''Height bit map''' where each bit indicates which vertical chunk it contain.
+
The payload is a set of 16x16x16 chunks, sharing the same X and Z chunk coordinates. What is and isn't sent is provided by the two bitmask fields. The least significant bit is '1' if the chunk spanning from Y=0 to Y=15 is not completely air, and so forth. For block IDs, metadata, and lighting, the primary bitmask is used. A secondary bitmask is used for 'add' data, which is mojang's means of provided Block IDs past 256. In vanilla minecraft, you can expect this to always be zero.
Counting the number of binary 1's indicate the number of vertical chunks(16x16x16) of the uncompressed
 
  
N = number of vertical chunks.
+
The data is compressed using the deflate() function in [http://www.zlib.net/ zlib]. After uncompressing, the data consists of five sequential sections, in order:
  
{| class="wikitable"
+
* Block type array (1 byte per block)
|- class="row0"
+
* Block metadata array (half byte per block)
! class="col0" | Size
+
* Block light array (half byte per block)
! class="col1" | Name
+
* Sky light array (half byte per block)
! class="col2" | Example
+
* Add array (half byte per block, uses second bitmask)
! class="col4" | Notes
 
|- class="row1"
 
| class="col0 centeralign" | 16*16*16*N
 
| class="col1 centeralign" | Block ID
 
| class="col2" | 7(bedrock)
 
| class="col4" | 1 byte per block.
 
|- class="row2"
 
| class="col0 centeralign" | 16*16*16*N
 
| class="col1 centeralign" | Add Block ID
 
| class="col2" | 0
 
| class="col4" | (unconfirmed)1 byte per block.
 
|- class="row2"
 
| class="col0 centeralign" | 16*16*8*N
 
| class="col1 centeralign" | Unknown
 
| class="col2" | 255
 
| class="col3" | (unconfirmed) Biome? Skylight?
 
|- class="row9"
 
! class="col0" | Total Size:
 
| class="col1 rightalign" colspan="3" | 16*16*16*N*2 + 16*16*8*N bytes (uncompressed)
 
|}
 
 
 
That would make the boolean mean "Contiguous?". Possibly a memory optimisation? The bit shifting in the chunk loading code makes this idea seem likely to me - good thought! [[User:Barneygale|Barneygale]] 08:37, 15 February 2012 (MST)
 
: It could be an indicator that non included chunks are assumed to be empty/air, a guess --[[User:Ceiru|Ceiru]] 09:14, 15 February 2012 (MST)
 
 
 
:(edit conflict, lol)
 
:The first part of the uncompressed data is the chunk block ids (I think), which as you say are loaded based on the bitmask. Each chunk is 4096 bytes.
 
:Three near identical loops follow, iterating over the column of chunks. They all set the .a property of a qi - and I'm not sure what this is. I'm guessing it's a handler for chunk attributes like metadata, skylight and blocklight.
 
:Next there's a loop that bears a striking similarity to the first, but uses the second short as a bitmask. For each chunk, if it's mentioned in the mask, it will initialise or use the existing .e (another qi) of that chunk and copy data to it. Here's where the bool comes in. If the chunks are contiguous, and the current chunk is both loaded and has .e set, it will set .e to null.
 
:Then there's some chunk initialisation stuff I don't understand. [[User:Barneygale|Barneygale]] 09:25, 15 February 2012 (MST)
 
 
 
Data is:
 
 
 
Blocks (4096 bytes per chunk)
 
Metadata (2048 per chunk) [uhg...]
 
Blocklight (2048 per chunk)
 
Skylight (2048 per chunk)
 
 
 
Add (2048 per chunk)
 
  
Everything apart from Blocks is in nibbles, hence this.a = new byte[paramInt1 >> 1]; in qi. [[User:Barneygale|Barneygale]] 10:00, 15 February 2012 (MST)
+
In each section, your loop should look something like this:
 +
<code>
 +
  for (i=0;i<16;i++) {
 +
    if (bitmask & 1 << i) {
 +
      data = io.read(4096); //2048 for the other arrays, where you'll need to split the data
 +
     
 +
      for(int j=0; j<len(data); j++) {
 +
       
 +
        //Block data
 +
        x = (j & 0xF0) >> 4;
 +
        y = j & 0x0F;
 +
        z = j >> 8;
 +
 +
        //Nibble arrays
 +
        k = 2*j;
 +
       
 +
        d1 = data[j] & 0x0F;
 +
        x1 = (k & 0xF0) >> 4;
 +
        y1 = k & 0x0F;
 +
        z1 = k >> 8;
 +
       
 +
        k++;
 +
       
 +
        d2 = data[j] >> 4;
 +
        x2 = (k & 0xF0) >> 4;
 +
        y2 = k & 0x0F;
 +
        z2 = k >> 8;
 +
      }
 +
    }
 +
  }
 +
</code>
  
[[User:Barneygale|Barneygale]] 10:00, 15 February 2012 (MST)
+
The 'add' array is specified at the very end, but uses the second bitmask. Block IDs are presumed to be <code>block_id | add << 8</code>
  
 
== Other changes ==
 
== Other changes ==

Revision as of 17:51, 15 February 2012

This page documents the changes from the last stable Minecraft release (currently 1.1) to the current pre-release

New packets

Entity Head Look (0x23)

Changes the direction an entity's head is facing.

Packet ID Field Name Field Type Example Notes
0x23 Entity ID int
Head Yaw byte Head yaw in steps of 2π/256
Total Size: 6 bytes

Update Tile Entity (0x84)

Essentially a block update on a tile entity.

Packet ID Field Name Field Type Example Notes
0x84 X int
Y short
Z int
Action byte The type of update to perform
Custom 1 int Varies
Custom 2 int Varies
Custom 3 int Varies
Total Size: 24 bytes

Actions

  • 1: Set mob displayed inside a mob spawner. Custom 1 contains the mob type

Changed packets

Login Request (0x01)

World height was changed to an integer. -- Please verify, I found world height to still be a byte but set to 0.

Packet ID Field Name Field Type Example Notes
0x01 Entity ID int 1298 The Players Entity ID
Not used string (empty string) Not used
Map Seed long 971768181197178410 The server's map seed. Must be sent in respawn packets by the client.
Level Type string DEFAULT DEFAULT or SUPERFLAT; level-type in server.properties
Server mode int 0 0 for survival, 1 for creative
Dimension byte 0 -1: The Nether, 0: The Overworld, 1: The End
Difficulty byte 1 0 thru 3 for Peaceful, Easy, Normal, Hard
World height int 256 Defaults to 256
Max players unsigned byte 8 Used by the client to draw the player list
Total Size: 28 bytes + length of strings

Handshake (0x02)

Client to Server

The hostname and port were added to this packet, most likely to allow virtual hosting .(sample implementation)

Packet ID Field Name Field Type Example Notes
0x02 UsernameAndHost string TkTech;localhost:25565 The username of the player attempting to connect, and the host he is connecting to, seperated by a semicolon.
Total Size: 3 bytes + length of strings

Respawn (0x09)

Dimension is now an int, slightly bizarrely. I wonder if they intended to make world_height an int, in line with 0x01 login?

Packet ID Field Name Field Type Example Notes
0x09 Dimension int 1 -1: The Nether, 0: The Overworld, 1: The End
Difficulty byte 1 0 thru 3 for Peaceful, Easy, Normal, Hard. 1 is always sent c->s
Creative mode byte 1 0 for survival, 1 for creative.
World height short 128 Defaults to 128
Map Seed long -3815848935435401459 The server's map seed.
Level Type string DEFAULT See 0x01 login
Total Size: 19 bytes + length of string

Mob Spawn (0x18)

New byte field: head yaw

This needs confirmation!

Packet ID Field Name Field Type Example Notes
0x18 EID int 446 Entity ID
Type byte 91 The type of mob. See Entities#Mobs
X int 13366 The Absolute Integer X Position of the object
Y int 2176 The Absolute Integer Y Position of the object
Z int 1680 The Absolute Integer Z Position of the object
Yaw byte -27 The yaw in steps of 2π/256
Pitch byte 0 The pitch in steps of 2π/256
Head Yaw byte Head yaw in steps of 2π/256
Metadata Metadata 127 Varies by mob, see Entities
Total Size: 21 bytes + Metadata (at least 1)

Map Chunk (0x33)

This is currently a best guess

Here's a packet capture: https://gist.github.com/1835702

Packet ID Field Name Field Type Example Notes
0x33 X int Chunk X Coordinate (*16 to get true X)
Z int Chunk Z Coordinate (*16 to get true Z)
Ground-up contiguous boolean This is True if the chunks consists of a contiguous column of non-air (i.e., indicated with a '1' in the bitmask) chunks starting at Y=0, followed by any number of unsent chunks containing only air.
Primary bit map short 15 Bitmask with 1 for every 16x16x16 chunk which data follows in the compressed data.
Add bit map short 0 Same as above, but this is used exclusively for the 'add' portion of the payload
Compressed size int Size of compressed region data.
Unused int int 0 Doesn't seem to be used by the client. Always 0. I expect this is Mod API stuff.
Compressed data unsigned byte array The region data is compressed using ZLib Deflate function. Confirmed!
Total Size: 22 bytes + Compressed chunk size

The payload is a set of 16x16x16 chunks, sharing the same X and Z chunk coordinates. What is and isn't sent is provided by the two bitmask fields. The least significant bit is '1' if the chunk spanning from Y=0 to Y=15 is not completely air, and so forth. For block IDs, metadata, and lighting, the primary bitmask is used. A secondary bitmask is used for 'add' data, which is mojang's means of provided Block IDs past 256. In vanilla minecraft, you can expect this to always be zero.

The data is compressed using the deflate() function in zlib. After uncompressing, the data consists of five sequential sections, in order:

  • Block type array (1 byte per block)
  • Block metadata array (half byte per block)
  • Block light array (half byte per block)
  • Sky light array (half byte per block)
  • Add array (half byte per block, uses second bitmask)

In each section, your loop should look something like this:

 for (i=0;i<16;i++) {
   if (bitmask & 1 << i) {
     data = io.read(4096); //2048 for the other arrays, where you'll need to split the data
     
     for(int j=0; j<len(data); j++) {
       
       //Block data
       x = (j & 0xF0) >> 4;
       y = j & 0x0F;
       z = j >> 8;

       //Nibble arrays
       k = 2*j;
       
       d1 = data[j] & 0x0F;
       x1 = (k & 0xF0) >> 4;
       y1 = k & 0x0F;
       z1 = k >> 8;
       
       k++;
       
       d2 = data[j] >> 4;
       x2 = (k & 0xF0) >> 4;
       y2 = k & 0x0F;
       z2 = k >> 8;
      }
   }
 }

The 'add' array is specified at the very end, but uses the second bitmask. Block IDs are presumed to be block_id | add << 8

Other changes

Protocol version is now 27.

Protocol History

2012-02-15

  • 12w07a
  • Protocol version is now 27
  • Updated packets: 0x01, 0x09, 0x33

2012-02-09

  • 12w06a
  • Protocol version is now 25
  • New packet: 0x84

2012-01-26

  • 12w04a
  • Protocol version has not been changed
  • Handshake Packet by client (0x02) now contains the server host and port
  • Window Open Packet (0x64): WindowTitle is now longer than accepted by older clients. Contains a keyword such as "container.furnace"

2012-01-19

  • 12w03a
  • Protocol version is now 24
  • New packet: 0x23
  • MobSpawn: new field, 1 byte inserted before metadata.