Revision as of 23:19, 30 January 2011 by Thejoshwolfe (talk | contribs) (→‎Absolute integer relation to absolute position: my bad)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Too Large?

MediaWiki gave me a warning about this page being too large for some browsers. Perhaps it should be split in half? --SpaceManiac 00:44, 6 November 2010 (EDT)

Player Position (0x0B) really absolute position?

As of version 1.2.0_02, I was watching the packets my server software was receiving while walking around, and the xyz coordinates of packet type 0x0b appear to correlate 1:1 with where a player is in block coordinates, not pixel coordinates. Yen

Absolute position position is specified as block coordinates, It appears this has changed before the move, I put in these definitions originally to clarify such things, absolute double's should be block coordinates, with the fraction being the offset in the block. ReDucTor

So "Absolute" is in meters, but "Absolute integer" is in pixels? Can't we come up with better names? I propose we name coordinates by the size of 1 unit. We change the names like this: Absolute -> meters; Absolute integer -> pixels; Block -> meters; Chunk -> chunks. Currently, the only two "units of measurement" with the same name are in fact different units of measurement. The focus of the current names seems to be the precision of the types, which seems less important to convey to readers than the scale of each unit relative to one another. --Thejoshwolfe 22:55, 25 January 2011 (MST)

New Server Packet 0x1c

The 11/10/2010 update has a new server to client packet (0x1c) 11 bytes long, the first field appears to be an EID. The packet is sent when a pickup is spawned in the world, either by throwing something, or mining. If the packet is ignored, the pickups never appear on the client. Jorgon3d 20:34, 10 November 2010 (EST)

New Client Packet 0x15

The 11/10/2010 update has a new client to server packet (0x15). It appears to be exactly as the Server to Client packet "Pickup Spawn". Jorgon3d 20:34, 10 November 2010 (EST)

Version 4

I've added the new packets from Version 4, and what I believe they match with, if people could please match these with what they see. And a Grammar Nazi fix up my failures. Please join / #mcc to discuss this new protocol. ReDucTor

C->S Block change with direction=-1

(Client to server) It appears now after a block change is sent there is another block change that follows this with all values -1 except block id of the change, from what I can determine this causes the players selected inventory to be changed if needed from this block change. Anyone looked into this? ReDucTor

New packets introduced in SMP Health update

Looking at the new server JAR I've seen three new packets. IDs are 0x08(<byte>), 0x09(), and 0x26(<int>,<byte>).

0x08 I'm thinking could be the players health update packet, 0x26 perhaps the 'hit entity' packet, 0x09 I'm not sure.

I'll confirm what these packets do tonight when I get back from work.

The 0x09 packet is for respawning. It is sent in both directions for when the player should respawn. 0x08 is the health, yes. Haven't gotten to 0x26 yet. Blixt 08:17, 24 November 2010 (EST)
Packet 0x07 from client to server has a new field of 1 byte. Its value is usually 1 which would make your client try to read a 0x01 packet, which includes a string, so that explains why you're getting errors about negative lengths, unicode or simply if the client stops reading more data. Blixt 10:01, 24 November 2010 (EST)
I believe I found a VERY subtle change that caused my client to crash when proxied through a wrapper that reads and writes packets: The packet for animating (0x12) now supports values other than 0 and 1 (bool): I got 2 for some packets. Blixt 10:14, 24 November 2010 (EST)
The 0x07 packet has a new bool for attacking_animal. It is 0 when using things vs air or blocks, and 1 when used on zombies, animals, and probably players (haven't tested yet). benmanns 10:24, 24 November 2010 (EST)
0x07 is never sent when you hit normal blocks or air. It's for interacting with an entity (thus it also has an entity id). I do get true whenever I hit a mob though, so that part seems correct. Blixt 10:59, 24 November 2010 (EST)
0x26 appears to be sent when an entity dies. The last byte seems to be 3 most of the time. No idea what that means. My wrapper ( is working fine now, but there seems to be a few bugs relating to burning mobs... don't know why. Blixt 10:59, 24 November 2010 (EST)
Never mind, I was forcing the client to think it was day, so during the night (on the server) the client thought the monsters should burn so they started burning, then the server said they weren't burning so they stopped burning. :) Blixt 14:15, 24 November 2010 (EST)

Complex entity packet (0x3B) client->server

Is this new? Wasn't it only server->client before? The client is sending 0x3B to the server whenever you put stuff in a chest now, anyways. Blixt 11:37, 29 November 2010 (EST)

Nov 30 update

Today's update seems to change the following:

  • The 0x26 packet now sends values other than 3 for the byte field. The value 2 means an entity was hurt. The value 3 means an entity died. The value 4 is sent the moment a creeper starts flashing.
  • There is a new packet 0x3C. I haven't investigated this yet but my guess is it's got to do with sound. It appears to be sent when a creeper is about to explode.
  • There are a lot of new values for packet 0x12 (animate), such as 104 for crouching, 105 for standing up.

- Blixt 17:58, 30 November 2010 (EST)

Has anyone looked into this? I am starting to suspect that 0x3C is a packet specific to explosions... It seems to have a structure similar to 0x34 / Multi Block Change. – Blixt 05:12, 1 December 2010 (EST)
The packet structure is like this: double, double, double, float, n = integer, n * 3 bytes. The first three doubles correspond well with X, Y, Z. The float is currently unknown. It was 3.0 for me, might be a radius or something. The list of bytes appears to be a bunch of block offsets, presumably the blocks that were destroyed in the explosion. The range of the values seems to be a bit strange though, I got the X offset as -6 up to 3, which means the explosion wouldn't be centered on the X, Y, Z coordinates. Also, the list seems to include air blocks, which seems a bit unnecessary. More investigation needed. – Blixt 18:04, 1 December 2010 (EST)

Map chunks vs. mini chunks

I'd like to make a distinction between "mini chunks" and "map chunks". Mini chunks are updates that have the same purpose as "multi block updates". The X/Y/Z size and position can be anything. Map chunks are complete 16x128x16 pieces of the map. Mini-chunk updates can arrive before map chunk updates.

"Prechunk" packet marks where a map chunk will be visible to the client, eventually. It can come well before the client should draw, though. My client will only draw a map chunk that has had a full 16x128x16 chunk update (loaded), and a prechunk packet (visible). Mini-chunks might come before prechunks, and prechunks usually come before map chunks, but both sides have to be flexible. I *have* seen mini-chunks cross map chunk boundaries, but it might be a bug in my client ;p

Example: 6x4x5 mini-chunk sent for [-1022, 20, 50]. Prechunk sent for [-1024/16, 48/16]. 16x128x16 map chunk sent for [-1024, 0, 48], overwriting the mini-chunk. Now it's drawn, because client has prechunk and full map chunk. Remember, chunk sizes are encoded as size-1.

Currently unlisted packets.

Some packets are listed as only going in one direction, but are actually sent the other too. To my knowledge, these are:

  • S->C 0x0a
  • S->C 0x0b
  • C->S 0x3b (mentioned above)

The packets are identical to their counterparts. Barneygale 17:02, 15 December 2010 (EST)

Were you connecting to a standard server? I've only received 0xa and 0xb from unofficial servers. --Axus 13:21, 16 December 2010 (EST)

beta update December 20, 2010

Someone pasted some notes about the protocol changes here:

Question: Does 0x0D Player Position and Look Client->Server still differ from Server->Client?

I haven't seen any differences in how player position works. I've updated my wrapper and server to work with the new protocol and everything seems fine. See this diff for most packet changes: 10:30, 21 December 2010 (EST)
I updated the packets that were missing information, and changed the notion from "inventories" to "windows" as that makes more sense. I also believe that's the term used by Notch when he mentioned his implementation in some blog post. - Blixt 19:25, 21 December 2010 (EST)
Sorry, the term he used was "popup", not "window". But still, the way the packets work is popup/window-centric, not inventory/container-centric (since every time a popup/window is opened, it gets a new id, the ids are not specific to which container/inventory is opened - except for the player inventory of course). - Blixt 07:18, 22 December 2010 (EST)

Note! As of 1.1, the Transaction packet goes in both direction (previously it was only sent by the server). - Blixt 09:56, 22 December 2010 (EST)

Why the merge?

I noticed the client/server and server/client sections were merged - why was this? It makes it difficult to tell the difference between packet directions when they're unidirectional. --SpaceManiac 13:31, 21 December 2010 (EST)

I don't mind the merge so much (the page is quite a bit shorter), but we should have a list or table of C<->S mapping. Having quick access to that makes writing an inbound {client, server} decoder much easier. --kev009

Actually, a merge makes sense, since the original Minecraft server itself does not differ between directions when defining its packets (that's why there are two unused fields in each direction for the handshake packet, for example). But yes, a notion on which direction(s) a packet can be sent would make sense, possibly with a simple table for each direction at the top for a quick reference on all packets for one direction. - Blixt 19:23, 21 December 2010 (EST)


Two things.. The "Y" and "Stance" are, for Client->Server at least, in the same order in both 0B and 0D packets. Perhaps the discrepancy has been fixed in a recent protocol version, but I haven't checked Server->Client yet.

Also the F3 Coordinate display in Minecraft shows, for Y, what we are calling "Stance" on the page. The server uses "stance" to mean neither coordinate, but in fact the difference between the two, ie, the height of the player. This would make more sense as something to be called "stance" too.

So, I would say the upper of the two coordinates (currently called "stance") should be called "Y", and the lower (currently called "Y") should be "foot height" or something like that. Neither should be called "stance". Moo 10:15, 1 January 2011 (MST)

I like having "Y" correspond to player's foot position. What happens if player is standing at Y=127? Eye height becomes 128.62, which maps out of the normal chunk coordinates. Items and monsters give Y at their foot position, doing the same with players would be consistent. --Axus 07:16, 3 January 2011 (MST)

"What happens if player is standing at Y=127? Eye height becomes 128.62," Minecraft itself shows the player's Y coordinate as 129.62 when as high as can currently be reached. Monsters and items don't have a camera/eye position to account for, so that would probably explain why they use the "foot position". Moo 16:15, 6 January 2011 (MST)

Connection "hash" somewhat misleading?

I know some guys who are writing server software for Minecraft, and I know one thing they were confused about was how to generate the connection "hash". Was it an MD5 hash or a SHA1 hash or what? I looked into it for them and discovered that it wasn't actually what we considered a hash at all. Instead, it was a random long in hexadecimal form. Literally. Take a look at this code:

public void a(h paramh) {

 if (this.e.l) {
   this.i = Long.toHexString(d.nextLong());
   this.b.a(new h(this.i));
 } else {
   this.b.a(new h("-"));


h turns out to be the handshake packet class. this.b.a() appears to send the client a packet, and this.d (referred to as just d) is a Random object. this.e.l is the variable in the MinecraftServer object that tells whether 'online-mode' is on or off. All I'm asking is for there to be a little clarification on what exactly the connection "hash" is, as not everyone can go trudging through obfuscated code to find how it's generated. Is it alright for me to do this? AnonymousJohn 21:21, 9 January 2011 (MST)

Beta 1.2 Update

Lots of "interesting" things.

The most "interesting" is what looks like "Custom mob data" at the end of Mob Spawn 0x18 and new packet 0x28 (Mob Update?). The "Custom mob data" is a byte stream with each data type encoded in a byte. According to pastebin:

The "metadata" byte is split this way:

  • j: First 3 bits, data type
  • k: Last 5 bits, data key

"j" data type:

  • 0: byte
  • 1: short
  • 2: int
  • 3: float
  • 4: string (short, bytes)
  • 5: inventory item (short, byte, short)

After the "metadata" byte is data of the "data type".


  • 0x00, 0x00, 0x7F:
    • j = 0, k = 0. Key = 0, byte value = 0x00.
    • End of stream marked by 0x7F.
  • 0x00, 0x00, 0x10, 0xFF, 0x7F:
    • j = 0, k = 0. Key = 0, byte value = 0x00.
    • j = 0, k = 16. Key = 16, byte value = 255.
    • End of stream marked by 0x7F.

Packet ID datatype explanation

The page needs to mention what datatype the packet ID is. My experimentation has revealed it to be unsigned char, however I'm not sure whether this is correct, and if so, where it should appear on the page. --ElectronicsRules 04:40, 17 January 2011 (MST)

OK I added something. --Axus 05:24, 17 January 2011 (MST)

Signed/Unsigned Byte Values

Section #SizeX.2C_SizeY.2C_SizeZ in the Map Chunk section says that bytes can be values up to 255. There needs to be clarification when bytes are signed and when they're unsigned. Java's bytes are always signed. --Thejoshwolfe 20:31, 23 January 2011 (MST)

Absolute integer relation to absolute position

The formula is currently stated as:

absolute_int = (int)(absolute_double / 32.0);

But in my understanding it should be:

absolute_int = (int)(absolute_double * 32.0);

I think you're correct. You have to divide "absolute int" by 32 to get the block position, and "absolute double" is block position with extra precision --Axus 08:44, 30 January 2011 (MST)

Oops. Good catch. Thanks. --Thejoshwolfe 16:19, 30 January 2011 (MST)