https://wiki.vg/api.php?action=feedcontributions&user=Janmm14&feedformat=atomwiki.vg - User contributions [en]2024-03-29T16:00:42ZUser contributionsMediaWiki 1.34.4https://wiki.vg/index.php?title=Talk:Protocol&diff=18054Talk:Protocol2023-03-16T23:25:36Z<p>Janmm14: /* Differentiation between multiple Minecraft protocol level packets in one TCP packet */</p>
<hr />
<div>== zlib compress instead of deflate? (0x33) ==<br />
Whilst implementing chunk creation server side in PHP I've found deflate does not work, however the zlib compressed format does. Can anyone else confirm this? --[[User:ody|ody]]<br />
<br />
I can confirm it uses zlib. I'm using the Ionic Zlib library. Using deflate makes the Minecraft client show the error "Bad compressed data format." [[User:DotMaiku|dotMaiku]] 10:13, 23 October 2011 (MST)<br />
<br />
Just strip the first 2 chars... then it works (Java deflate issue) --[[User:Shoghicp|Shoghicp]] 14:21, 12 December 2011 (MST)<br />
<br />
== Too Large? ==<br />
MediaWiki gave me a warning about this page being too large for some browsers. Perhaps it should be split in half? --[[User:SpaceManiac|SpaceManiac]] 00:44, 6 November 2010 (EDT)<br />
<br />
Don't hit Edit for the entire page :P -- [[User:Jailout2000|<span style="color: #0080C0; font-weight: bold;">Jailout2000</span>]] 04:48, 2 January 2012 (MST)<br />
<br />
== Player Position (0x0B) really absolute position? ==<br />
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. [[User:Yen|Yen]]<br />
<br />
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. [[User:ReDucTor|ReDucTor]]<br />
<br />
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. --[[User:Thejoshwolfe|Thejoshwolfe]] 22:55, 25 January 2011 (MST)<br />
<br />
== New Server Packet 0x1c ==<br />
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. [[User:Jorgon3d|Jorgon3d]] 20:34, 10 November 2010 (EST)<br />
<br />
== New Client Packet 0x15 ==<br />
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". [[User:Jorgon3d|Jorgon3d]] 20:34, 10 November 2010 (EST)<br />
<br />
== Version 4 ==<br />
<br />
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 irc.esper.net / #mcc to discuss this new protocol. [[User:ReDucTor|ReDucTor]]<br />
<br />
== C->S Block change with direction=-1 ==<br />
<br />
(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? [[User:ReDucTor|ReDucTor]]<br />
<br />
== New packets introduced in SMP Health update ==<br />
<br />
Looking at the new server JAR I've seen three new packets. IDs are 0x08(<byte>), 0x09(), and 0x26(<int>,<byte>).<br />
<br />
0x08 I'm thinking could be the players health update packet, 0x26 perhaps the 'hit entity' packet, 0x09 I'm not sure.<br />
<br />
I'll confirm what these packets do tonight when I get back from work.<br />
<br />
: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. [[User:Blixt|Blixt]] 08:17, 24 November 2010 (EST)<br />
<br />
: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. [[User:Blixt|Blixt]] 10:01, 24 November 2010 (EST)<br />
<br />
: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. [[User:Blixt|Blixt]] 10:14, 24 November 2010 (EST)<br />
<br />
: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). [[User:benmanns|benmanns]] 10:24, 24 November 2010 (EST)<br />
<br />
::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. [[User:Blixt|Blixt]] 10:59, 24 November 2010 (EST)<br />
<br />
: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 (http://github.com/blixt/pyminecraft) is working fine now, but there seems to be a few bugs relating to burning mobs... don't know why. [[User:Blixt|Blixt]] 10:59, 24 November 2010 (EST)<br />
<br />
::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. :) [[User:Blixt|Blixt]] 14:15, 24 November 2010 (EST)<br />
<br />
== Complex entity packet (0x3B) client->server ==<br />
<br />
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. [[User:Blixt|Blixt]] 11:37, 29 November 2010 (EST)<br />
<br />
== Nov 30 update ==<br />
<br />
Today's update seems to change the following:<br />
<br />
* 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.<br />
* 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.<br />
* There are a lot of new values for packet 0x12 (animate), such as 104 for crouching, 105 for standing up.<br />
<br />
- [[User:Blixt|Blixt]] 17:58, 30 November 2010 (EST)<br />
<br />
: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. – [[User:Blixt|Blixt]] 05:12, 1 December 2010 (EST)<br />
<br />
: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. – [[User:Blixt|Blixt]] 18:04, 1 December 2010 (EST)<br />
<br />
== Map chunks vs. mini chunks ==<br />
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.<br />
<br />
"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<br />
<br />
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.<br />
<br />
== Currently unlisted packets. ==<br />
<br />
Some packets are listed as only going in one direction, but are actually sent the other too. To my knowledge, these are:<br />
<br />
*S->C 0x0a<br />
*S->C 0x0b<br />
*C->S 0x3b (mentioned [[Talk:Protocol#Complex_entity_packet_.280x3B.29_client-.3Eserver|above]])<br />
<br />
The packets are identical to their counterparts. [[User:Barneygale|Barneygale]] 17:02, 15 December 2010 (EST)<br />
<br />
<br />
Were you connecting to a standard server? I've only received 0xa and 0xb from unofficial servers.<br />
--[[User:Axus|Axus]] 13:21, 16 December 2010 (EST)<br />
<br />
== beta update December 20, 2010 ==<br />
<br />
Someone pasted some notes about the protocol changes here:<br />
http://pastebin.com/YfR9XgC2<br />
<br />
Question: Does 0x0D Player Position and Look Client->Server still differ from Server->Client?<br />
<br />
: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: https://github.com/blixt/pyminecraft/commit/af4c9f6b9b2387e429fa425dd5061ef01e03c5aa#diff-1 – [[User:Blixt|Blixt]] 10:30, 21 December 2010 (EST)<br />
<br />
: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. - [[User:Blixt|Blixt]] 19:25, 21 December 2010 (EST)<br />
<br />
::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). - [[User:Blixt|Blixt]] 07:18, 22 December 2010 (EST)<br />
<br />
'''Note!''' As of 1.1, the Transaction packet goes in both direction (previously it was only sent by the server). - [[User:Blixt|Blixt]] 09:56, 22 December 2010 (EST)<br />
<br />
== Why the merge? ==<br />
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. --[[User:SpaceManiac|SpaceManiac]] 13:31, 21 December 2010 (EST)<br />
<br />
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. --[[User:Kev009|kev009]]<br />
<br />
: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. - [[User:Blixt|Blixt]] 19:23, 21 December 2010 (EST)<br />
<br />
== Y/Stance ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
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".<br />
[[User:Moo|Moo]] 10:15, 1 January 2011 (MST)<br />
<br />
<br />
: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. --[[User:Axus|Axus]] 07:16, 3 January 2011 (MST)<br />
<br />
<br />
::"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". [[User:Moo|Moo]] 16:15, 6 January 2011 (MST)<br />
<br />
:I agree with [[User:Axus|Axus]] that "Y" should be the foot position to be consistent with mobs and such. But "Stance" is really the wrong name for the field in the Player Position messages. Like [[User:Moo|Moo]] said, the server calls "stance" the difference between the eyes and feet. The fields in the Player Position messages should be "Y" and "Eye Y". Note that Eye Y is NOT the top of the player's bounding box. Players are 1.74 meters tall, and foot-to-eye distance only goes up to 1.65 meters. Also changing your Eye Y does not make you appear to crouch according to my experiments. --[[User:Thejoshwolfe|Thejoshwolfe]] 04:35, 9 February 2011 (MST)<br />
<br />
== Connection "hash" somewhat misleading? ==<br />
<br />
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:<br />
<br />
public void a(h paramh) {<br />
if (this.e.l) {<br />
this.i = Long.toHexString(d.nextLong());<br />
this.b.a(new h(this.i));<br />
} else {<br />
this.b.a(new h("-"));<br />
}<br />
}<br />
<br />
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? [[User:AnonymousJohn|AnonymousJohn]] 21:21, 9 January 2011 (MST)<br />
<br />
== Beta 1.2 Update ==<br />
<br />
Lots of "interesting" things. <br />
<br />
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 [http://pastebin.com/8fF60ZwQ pastebin]:<br />
<br />
The "metadata" byte is split this way:<br />
*j: First 3 bits, data type<br />
*k: Last 5 bits, data key<br />
<br />
"j" data type:<br />
*0: byte<br />
*1: short<br />
*2: int<br />
*3: float<br />
*4: string (short, bytes)<br />
*5: inventory item (short, byte, short)<br />
<br />
After the "metadata" byte is data of the "data type".<br />
<br />
Example:<br />
*0x00, 0x00, 0x7F:<br />
**j = 0, k = 0. Key = 0, byte value = 0x00.<br />
**End of stream marked by 0x7F.<br />
<br />
*0x00, 0x00, 0x10, 0xFF, 0x7F:<br />
**j = 0, k = 0. Key = 0, byte value = 0x00.<br />
**j = 0, k = 16. Key = 16, byte value = 255.<br />
**End of stream marked by 0x7F.<br />
<br />
== Packet ID datatype explanation ==<br />
<br />
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<br />
whether this is correct, and if so, where it should appear on the page. --[[User:ElectronicsRules|ElectronicsRules]] 04:40, 17 January 2011 (MST)<br />
<br />
OK I added something. --[[User:Axus|Axus]] 05:24, 17 January 2011 (MST)<br />
<br />
== Signed/Unsigned Byte Values ==<br />
<br />
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. --[[User:Thejoshwolfe|Thejoshwolfe]] 20:31, 23 January 2011 (MST)<br />
<br />
== Absolute integer relation to absolute position ==<br />
<br />
The formula is currently stated as:<br />
<br />
absolute_int = (int)(absolute_double / 32.0);<br />
<br />
But in my understanding it should be:<br />
<br />
absolute_int = (int)(absolute_double * 32.0);<br />
<br />
<br />
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 --[[User:Axus|Axus]] 08:44, 30 January 2011 (MST)<br />
<br />
Oops. Good catch. Thanks. --[[User:Thejoshwolfe|Thejoshwolfe]] 16:19, 30 January 2011 (MST)<br />
<br />
== Packet 0xA ==<br />
<br />
I've removed the note about this packet being used for speedhacking detection as it doesn't really make sense considering it is a client-to-server packet. The client is authoritative on movement of the player. Note that the "Player moved wrongly" server console warning is based on movement delta thresholds and not ground/airborne state, which seems to be used exclusively for fall damage application (try forcing the "on ground" state to be True in all c>s player movement packets)<br />
--[[User:Entity|Entity]] 06:05, 5 February 2011 (MST)<br />
<br />
: Forcing 'on ground' state to be True on all c->s movement does indeed eliminate fall damage. However, when 'on ground' is forced True, you cannot ride minecarts - I haven't tested this yet for boats. [[User:Coldelectrons|Coldelectrons]] 09:00, 1 May 2011 (MST)<br />
<br />
== big endian conversion c++ ==<br />
<br />
converting integer types from big endian to little endian and vice versa is rather simple<br />
<br />
when using visual studio this might need some adjusting thou<br />
please make sure you understand this and reimplement it to fit your needs, this is basically just pseudo code that could be compiled with a c++ compiler<br />
<br />
<pre><br />
#include <endian.h><br />
<br />
int32_t toInt(char* somedata)<br />
{<br />
int32_t result = *((int32_t*)somedata);<br />
result = be32toh(result);<br />
return result;<br />
}<br />
<br />
//for doubles and floats you need some more pointer magic (I know it's evil)<br />
<br />
float toFloat(char* somedata)<br />
{<br />
int32_t result = *((int32_t*)somedata);<br />
float* result_pointer = & result;<br />
result = be32toh(result);<br />
return *result_pointer;<br />
}<br />
</pre><br />
--[[User:Ker|Ker]] 14:53, 17 February 2011 (MST)<br />
<br />
== Wolves metadata ==<br />
<br />
I'm handling metadata as explained here http://mc.kev009.com/Protocol#Metadata<br />
When i do ''byte y = x >> 5;'' i keep getting -4 for wolves.<br />
New type of metadata, or is it just my fault? --[[User:Ligustah|Ligustah]] 04:18, 1 April 2011 (MST)<br />
<br />
Not necessarily wrong, X might really be 0xFFC?????, which would make Y look like "-4". Need to be checked of course. --[[User:Axus|Axus]] 08:03, 2 April 2011 (MST)<br />
<br />
I did a little more testing:<br />
https://gist.github.com/900428 I added metadata packets that i received in different situations. --[[User:Ligustah|Ligustah]] 06:35, 3 April 2011 (MST)<br />
<br />
The -4 mentioned earlier was actually my bad. I was using a byte to hold my x while it should have been an unsigned byte. I also updated the paste above and added all indices i observed with this packet. --[[User:Ligustah|Ligustah]] 08:16, 3 April 2011 (MST)<br />
<br />
== Version 11 (Beta 1.5) ==<br />
<br />
Changes I've noticed so far:<br />
<br />
All strings in packets are now 2-byte Big-Endian Unicode. The string length prefix value specifies #of chars not bytes;<br />
<br />
Packet 0x64 appears all different. String remains Modified-UTF. That's a big consistency WTF.<br />
<br />
Packet 0x66 gained a byte between Action and Item ID<br />
<br />
Login 0x01 response from server now appears EID (''int'') followed by 11 bytes (in my case); Looks like ''short,string,long,byte'' and that the second string was dropped. Total packet len 16 + (2 * strSize).<br />
<br />
Weather Event Packet 0x47 (71). (''int, byte, int, int, int'')<br/><br />
So far this packet has only shown itself for a lightning strike. The value of the ''byte'' was then always 1. During all other events (rain start/stop) this packet was nowhere to be seen whether during gameplay or when logging to SMP during a rainstorm. The first ''int'' appears to be an ''Entity ID'' as it always grew with every new strike. Last 3 ''int''s were the X,Y,Z coords respectively of the strike on the ground. It appears to be only S->C --[[User:Xiix|xiix]] 11:19, 20 April 2011 (MST)<br />
<br />
Packet 0x46 was also updated. The packet is the ba class. I grepped for "new ba" and got 3 hits<br />
<br />
The first 2 are in the dg class. These extends the da class which has code that seems to slowly change the raining state. <br />
<code><br />
protected void i()<br />
{<br />
boolean bool = v();<br />
super.i();<br />
<br />
if (bool != v())<br />
if (bool)<br />
this.z.f.a(new ba(2));<br />
else<br />
this.z.f.a(new ba(1));<br />
}<br />
<br />
</code><br />
<br />
The call to v() checks if it is still raining and the call to i() updates the raining counter.<br />
<br />
This basically says that if the rain state changes, send a 0x46 packet.<br />
<br />
1 = begin raining<br />
<br />
2 = end raining<br />
<br />
The next hit is in the du class.<br />
<br />
<code><br />
if (this.e.e.v()) {<br />
localgj.b(new ba(1));<br />
}<br />
</code><br />
<br />
this.e is the MinecraftServer and this.e.e is of type dg. This says that if it is raining, then send a packet with code 1. This method seems to be for logging in.<br />
<br />
The final hit is in the ep class.<br />
<br />
<code><br />
if (localaq2 != null) {<br />
localdc.c(localaq2.a + 0.5F, localaq2.b + 0.1F, localaq2.c + 0.5F, 0.0F, 0.0F);<br />
localdc.a(localaq1);<br />
} else {<br />
localdc.a.b(new ba(0));<br />
}<br />
</code><br />
<br />
The is probably the bed case.<br />
<br />
So, anyway, the possible values would be:<br />
{| class="wikitable"<br />
|-<br />
! Code<br />
! Effect<br />
|-<br />
| 0<br />
| Invalid Bed<br />
|-<br />
| 1<br />
| Begin raining<br />
|-<br />
| 2<br />
| End raining<br />
|}<br />
<br />
Tested and confirmed --[[User:Xiix|xiix]] 15:30, 23 April 2011 (MST)<br />
<br />
The reason byte is a public variable, so it is possible that the code is set from other places. However, since the string array only has 3 values, that suggests that these are the 3 valid values.<br />
<br />
Btw, what is the policy on editing the main protocol page itself?<br />
--[[User:Raphfrk|Raphfrk]] 13:57, 23 April 2011 (MST)<br />
<br />
Mystery packet 0xC8 (200). Follows hitting entities (cows and whatnot) or destroying/placing anything else:<br />
<br />
:* '''bool''' : ''0 entity destroyed; 1 otherwise, even if block is dug out it still exists so maybe that's why this one's always 1'';<br />
:* '''byte''' : ''0 entity/block destroyed; 2 block or item placed'';<br />
:* '''byte''' : ''???'';<br />
:* '''byte''' : ''block/item ID; for entities no clue'';<br />
:* '''byte''' : ''for bool=0 changes depending on what you hold, hit strength maybe'';<br />
<br />
Sent only ''Server''->''Client''.<br />
<br />
--[[User:Xiix|xiix]] 18:20, 19 April 2011 (MST)<br />
<br />
== /* Item data type */ ==<br />
<br />
In my own code, I've simplified things by treating the 3 items (short, optional byte,short) as an Item. It makes my packet format definitions far more readable.<br />
<br />
Any votes in favor of applying the Item definition to the existing page?<br />
<br />
{| class="wikitable"<br />
|- class="row0"<br />
| class="col0" |<br />
! class="col1" | Size<br />
! class="col2" | Range<br />
! class="col3" | Notes<br />
|- class="row1"<br />
! class="col0 centeralign" | Item<br />
| class="col1 centeralign" | 2-5<br />
| class="col2" | N/A<br />
| class="col3" | The structure is (short ItemID, [byte Count, short MetaDamage]). If ItemID == -1, the latter two items are omitted.<br />
|}<br />
-- Coldelectrons<br />
<br />
Would have been fine but 0x05 does not comply with this. Personally I'd rather deal with no rules than rules that have exceptions to them. --[[User:Xiix|xiix]] 09:43, 20 April 2011 (MST)<br />
<br />
== 0x01 Login C->S (Version 11) ==<br />
<br />
'''Since''' I'm a n00b here I won't edit the wiki itself for the fear of being an idiot, but to whoever did: from my own packet analysis the ''''''Client->Server'''''' login 0x01 packet remains unchanged except for the String8->String16 mod. Either Password (or other text) is still possibly sent (now empty) or it has 2 extra (0,0) bytes for whatever reason after username. So the makeup for my money is ''int, string16, string16, long, sbyte''. The length of the packet remains 18 + len of string16's.<br />
<br />
'''Also''', re new String16 thing. Maybe this is common knowledge for java folk, but for us MS/.NET dweebs it is important to know that the new string16 is actually UTF-16BE, as UTF-16 (implies UTF-16LE) decode will render gibberish.<br />
<br />
--[[User:Xiix|xiix]] 09:38, 20 April 2011 (MST)<br />
<br />
Note that it's actually big-endian UCS-2. Treating it as UTF-16 will likely work most of the time, except for crafted packets or otherwise misbehaving peers.<br />
<br />
--[[User:Huin|Huin]] 14:22, 15 May 2011 (MST)<br />
<br />
== /* Byte-packed double? */ ==<br />
<br />
The 3 ints int the weather packet:<br />
Can someone please explain or link to an explanation of how it is you pack a double-precision floating point (8 bytes) number into an int (4 bytes)? Bonus points for why you would want to do it that way?<br />
<br />
I might be wrong but I don't think it is a packed double in a true packing sense. What you do is in this instance is:<br/><br />
: '''double = int / 32.0''' --[[User:Xiix|xiix]] 08:26, 21 April 2011 (MST)<br />
<br />
== 0x32 (pre-chunk) packet optional? ==<br />
<br />
I've tried sending 0x33 packets without 0x32 packets to a 1.5 Beta client on initial connection - the client simply doesn't like it, and just jiggles up and down and the chunks are not visible.<br />
<br />
Sending the same 0x33 packets with 0x32 packets following results in the client falling, but the chunks being completely air-blocks.<br />
<br />
The chunks only appear to load correctly if each 0x33 packet is preceded by the corresponding 0x32 packet (even if not immediately preceding).<br />
<br />
Any other observations on this matter? It appears to me that the 0x32 packet to initialize the chunk is always required, rather than optional as the current text about packet 0x33 might suggest.<br />
<br />
--[[User:Huin|Huin]] 14:19, 15 May 2011 (MST)<br />
<br />
It might only matter on chunks close to the player. I think the "optional" note was more for client writers to allow strange exceptions from Notch's server, than for letting server writers take it easy ;)<br />
--[[User:Axus|Axus]] 16:03, 16 May 2011 (MST)<br />
<br />
Perhaps the times when the notchian server *doesn't* send the 0x32 is when the 0x33 packet is for a subset of the chunk (that is: an already loaded chunk). It would be nice to back this up with evidence of course. --[[User:Huin|Huin]] 14:24, 21 May 2011 (MST)<br />
<br />
== 0x18 - Where does the 'Index' come from? + Metadata String ==<br />
<br />
Can somebody tell me where the index come from? Is this a byte in the metastream or what ?<br />
<br />
Additionally there is no information about the width of the string chars in a metastream.<br />
<br />
--[[User:Chrisliebaer|Chrisliebaer]] 11:39, 22 May 2011 (MST)<br />
<br />
== 0x47 - Weather? ==<br />
<br />
22 May 2011 - Just started writing a library to read and write packets. Tried to follow the spec for 0x47 on the page, and kept getting errors. Looked at a Wireshark capture, and I see the 0x47 packet as being 8 bytes long (9 with the header). The first four bytes look to be an int related to location? It was negative in my capture. The next three bytes were all 0's, then a 0x02. --[[User:Nyasara]]<br />
<br />
== Map data (0x83) ==<br />
<br />
It seems like there is a new packet 0x83 which I can't figure out. Decompiling it reveals four possible forms: http://pastie.org/1975651<br />
--[[User:Sadimusi|Sadimusi]] 04:10, 26 May 2011 (MST)<br />
<br />
I wonder if it handles something related to Nether travel (probably reaching). <br />
<br />
I guess the respawn packet with the new field might be all that was added for handling this. <br />
<br />
Does the Nether have any use for a new world seed? If not, then I guess adding the Nether didn't require that a "change world seed" packet was created. If so, that is pretty disappointing. This would have been a perfect time to add a way to update the client's world seed.<br />
<br />
I am going to run a test tonight to see if the client can handle a second login packet after the update.<br />
<br />
--[[User:Raphfrk|Raphfrk]] 05:12, 26 May 2011 (MST)<br />
<br />
== Block Action? (0x3D) ==<br />
<br />
This packet is<br />
<br />
Int<br />
Int<br />
Byte<br />
Int<br />
Int<br />
<br />
It seems to be related to opening doors<br />
<br />
Int: 1003 (constant)<br />
Int: X position of door<br />
Byte: Y position of door<br />
Int: Z position of door<br />
Int: 0 (constant)<br />
<br />
The packet is sent to all players except the player who opens the door.<br />
--[[User:Raphfrk|Raphfrk]] 11:56, 26 May 2011 (MST)<br />
<br />
It is also sent to all near players when a door is opened with a redstone current.<br />
--[[User:Sadimusi|Sadimusi]] 12:39, 26 May 2011 (MST)<br />
<br />
<br />
:When a player opens a door with right click, the server receives Packet 0xF (block placement, but opens door)<br />
: When a player opens a door with left click, the server receives Packet 0xE+start digging<br />
: 1.7.3<br />
: [[User:Ishinay|Ishinay]] 05:31, 27 August 2011 (MST)<br />
<br />
== Unknown fields in 0x17 may be trajectory. ==<br />
<br />
Especially as there is no other packet to keep track of a ranged weapons trajectory, I deem it likely that the unknown fields encode the trajectory of the projectile.<br />
I haven't done any research into this yet, but I consider two methods of encoding likely:<br />
<br />
If X, Y and Z mark the original start point of the projectile, the last three fields may hold the initial X, Y and Z velocities of the projectile while the integer field encodes the time the projectile has already travelled on that path.<br />
<br />
If X, Y and Z mark the current position of the projectile, the unknown int could instead hold the velocity and the remaining shorts just encode the orientation of the projectile.<br />
<br />
Another, though unlikely option would be to encode the coordinates of the trajectories zenith.<br />
<br />
[[User:SlashLife|SlashLife]] 13:58, 28 May 2011 (MST)<br />
<br />
The fact that these fields were added with the same update the map item was introduced suggests a connection between those two things. Projectiles were added a long time ago and worked without these fields.<br />
--[[User:Sadimusi|Sadimusi]] 16:35, 28 May 2011 (MST)<br />
<br />
<br />
:The "Unknown flag int" actually seems to be the Shooter Entity Id, useful for differenciate the source of the damage. This code exemplifies:<br />
'''<br />
EntityFireball entityfireball = (EntityFireball) this.tracker;<br />
Packet23VehicleSpawn packet23vehiclespawn = new Packet23VehicleSpawn(this.tracker, 63, ((EntityFireball) this.tracker).shooter.id);<br />
'''<br />
:The other 3 int are taken from entity speed, so with much probability marks the initial trayectory tangent as a vector.<br />
'''<br />
double speedX = entity.speedX;<br />
double speedY = entity.speedY;<br />
double speedZ = entity.speedZ;<br />
...<br />
this.trayectoryX = (int) (speedX * 8000.0D);<br />
this.trayectoryY = (int) (speedY * 8000.0D);<br />
this.trayectoryZ = (int) (speedZ * 8000.0D);<br />
'''<br />
[[User:Ishinay|Ishinay]] 05:14, 27 August 2011 (MST)<br />
<br />
== 0x3D packet specs ==<br />
<br />
Packet 0x3D is used to make effects happen on the client.<br />
<br />
Parameters:<br />
int - identifier for effect (client chooses effect using a switch).<br />
int - X<br />
int - Y<br />
int - Z<br />
int - extra data value (used for 3 effects).<br />
<br />
Possible values:<br />
1000 - plays the dispenser fire sound.<br />
1001 - plays the empty dispenser fire sound.<br />
1002 - plays the projectile fire sound (snowball, egg, bow).<br />
1003 - plays the (trap)door open/close sound (50/50 chance of either).<br />
1004 - plays the fire extinguish sound.<br />
1005 - plays a record sound (using the extra data field as an item ID).<br />
2000 - spawns a dispenser fire particle (uses the extra data field for direction, possible 9? values).<br />
2001 - places dig effects on the block at the given location (uses the extra data field as a block ID).<br />
<br />
== 0x6A - Inventory Transaction ==<br />
<br />
The bool in packet 0x6A isn't as simple as 'True if accepted'. I've been playing with inventory logic a bit, and with Notchian client/server, the 'accepted' bool has no immediately discernible rhyme or reason from the server - simply, if a transaction has been accepted, there is a Transaction packet s->c, and if not, not. -- [[User:Coldelectrons|Coldelectrons]] 19:40, 11 June 2011 (MST)<br />
<br />
I tend to agree that its effect is non-obvious. I have noted that sending a "false" for that field results in the client replying with a transaction packet with "true". Beats me what it means :) --[[User:Huin|Huin]] 13:37, 17 June 2011 (MST)<br />
<br />
==== further observations ====<br />
<br />
* When a click leaves an inventory slot empty (picking up a whole stack or item), or when the click changes the amount of the stack in the inventory slot (depositing a single item into a stack), or swapping items, the S->C accepted==False. <br />
<br />
* When a click puts something into an empty slot (a single item or dropping one off of a stack with right-click), the S->C accepted==True<br />
<br />
These two could probably be simplified to "If the slot is empty when it is clicked, S->C accepted=True, else it is False". I haven't observed all conditions in all window types, so some collaboration would be helpful.<br />
<br />
* When the server sends accepted==False, the client will respond with a transaction packet with the same action number, but with accepted==True<br />
<br />
* When the server sends accepted==True, the client does not respond further.<br />
<br />
[[User:Coldelectrons|Coldelectrons]] 15:44, 17 June 2011 (MST)<br />
<br />
== Decimal packet numbers? ==<br />
<br />
Since the Packet classes in the minecraft source (as decompiled by mcp) are named with Decimal numbers it is kind of a hassle when trying to correlate those classes with this list of packets which only have the packet ID shown in hex. Any chance the decimal number could be included in here? In the section heading preferably so it can be seen in the index.<br />
<br />
== Entity Action ??? (0x13) ==<br />
<br />
Seem to be having trouble getting this to work this is sent when someone crouches but it causes a packet error in 1.7.2 was something added? --[[User:Faith2712|Faith2712]] 19:01, 6 July 2011 (MST)<br />
<br />
I believe you have to send the crouch in an entitymetadata packet rather than entityaction (apply the crouch flag to the metadata, then send the edited data).<br />
<br />
: Sneaking is definitely sent with 0x13 as you can see in this (unobscured) snippet from 1.7.3: http://pastie.org/2209271 --[[User:Sadimusi|Sadimusi]] 14:15, 13 July 2011 (MST)<br />
<br />
: : Faith2712 is definitely correct about it being sent from the server as entitymetadata (0x28). Packet 0x13 is client to server only. <br />
: : The byte array for crouching would be: "0x28, [player id(4 bytes)], 0x00, 0x02, 0x7F". 0x02 can be 0x00 (for no animations), 0x01 (for fire), 0x02 (for crouch), 0x03 (for crouch and fire a same time).<br />
: : --[[User:Jasonbay13|Jasonbay13]] 17:01, 11 August 2011 (MST)<br />
<br />
== Piston Direction ==<br />
<br />
Should piston direction 5 not be South? East is in there twice, and south is missed out. I am not certain that it is 5 though, so I have not edited it.<br />
<br />
== Entity Status (0x26) ==<br />
<br />
I've been looking into bukkit stuff today and I think I know what packet 0x26 is! It is sent any time an entity does some animation, especially I noticed with wolves:<br />
HURT (2),<br />
DEATH (3),<br />
SMOKE (6),<br />
HEARTS (7),<br />
WATER (8),<br />
<br />
This is what I've tested out so far. Smoke, Hearts, and water are mainly for wolfie animations. Note that I got these by testing and looking through the minecraft code. That's allowed, right? So far these are the only ones that are sent by the server.<br />
--[[User:Zonedabone|Zonedabone]] 18:08, 12 August 2011 (MST)<br />
<br />
== Yaw diagram needs correcting ==<br />
<br />
While I get the impression from Minecraft's code that ''some'' people *cough* can't tell up from down, left from right, or South from West, we here should be able to.<br />
<br />
The unit circle by the Player Look packet description needs to be changed to reflect what you actually encounter in the game and code.<br />
<br />
I have here a modest example: [[File:Notchian_Coordinate_System.png|200px|thumb|right|Back Arsewards]]<br />
<br />
[[User:Coldelectrons|Coldelectrons]] 14:45, 24 August 2011 (MST)<br />
<br />
== 1.8 Pre-release changes ==<br />
<br />
When refreshing the server list, packet 0xfe is sent. Its length is 1 byte.<br />
The server answers with a Kick(0xff) packet with the motd and player amount in the kick message with the format<br />
<br />
Motd§0§20<br />
<br />
for a server with 0 players, 20 slots, and motd set to Motd.<br />
<br />
--[[User:Zhuowei|Zhuowei]] 17:42, 9 September 2011 (MST)<br />
<br />
: Added, thanks :) [[User:Barneygale|Barneygale]] 23:32, 9 September 2011 (MST)<br />
<br />
== Creative inventory action (0x6B) ==<br />
<br />
Creative inventory action (0x6B) is sent by the client when the user clicks on a quickbar-slot<br />
<br />
== Mob ID for endermen? ==<br />
<br />
I'm pretty sure it's 58, can anyone confirm? [[User:Origamiguy|Origamiguy]] 08:57, 16 September 2011 (MST)<br />
<br />
: Yep, 58. The code:<br />
: addMapping(net.minecraft.src.EntityEnderman.class, "Enderman", 58);<br />
: (the number is the mob ID). --[[User:DuckDuckGo|DuckDuckGo]] 13:50, 29 December 2011 (MST)<br />
<br />
== Add Object/Vehicle correct? ==<br />
<br />
About a week ago, I tried to figure out the last four fields in the [[Protocol#Add_Object.2FVehicle_.280x17.29|Add Object/Vehicle (0x17) packet]]. Can someone check that I got it right? --[[User:Krenair|Krenair]] 08:28, 25 September 2011 (MST)<br />
<br />
== 0x02 (Server to Client), description misunderstunding ==<br />
<br />
The current description is:<br />
"This is the first packet sent when the client connects and is used for Authentication. If the hash is '-', then the client continues without doing name authentication. If the hash is a '+', there is currently no way to send a password in at least version 1.8.1. It should be treated similarly to '+'."<br />
<br />
But the meaning of the sentences is not clear.<br />
* The fact that '+' is used for password authentication is implied by the reader.<br />
* "It should be treated similarly to '+'." Meaning '+' similar to '+'? I guess it was supposed to be "...similarly to '-'."<br />
<br />
Am i correct on the above assumptions?<br />
<br />
== Server poll not working in 1.0? ==<br />
<br />
I've recently converted my software to match up with MC 1.0, but it doesn't seem to be working: it gives me a communication error, as if the packet's contents are incorrect. I'm currently using my 1.8 system, where the 254 packet is received and I immediately respond by sending the 255 Kick packet, with a string, such as MyServer§0§16. Any ideas? Has the protocol changed in this sense since 1.0 was released?<br />
<br />
Fixed: I forgot that my encoder was automatically generating the packet header for packet 254 in response rather than just sending packet 255. It was generating two headers, then the payload, haha. Fixed.<br />
<br />
== More explanations! ==<br />
<br />
I, for one, would be interested to know whether the animation packet is validated in any way by the server. For instance, could you send the eat animation to the server with something other than food in your hand?<br />
--[[User:DuckDuckGo|DuckDuckGo]] 13:47, 29 December 2011 (MST)<br />
:Try it and see --[[User:Barneygale|Barneygale]] 23:07, 29 December 2011 (MST)<br />
<br />
== World height and indexing problem ==<br />
<br />
I was working with [[Realcraft]] earlier tonight, rewriting it and all (I lost the source due to a HDD failure), and I got it working back to the point that it was at when I left it so long ago. I've seemed to have stumbled upon an issue. Only a world height of 128 (Size_Y=127) will work with the indexing (<code>index = y + (z * (Size_Y+1)) + (x * (Size_Y+1) * (Size_Z+1))</code>), any other height and the Minecraft client will show erroneous chunks. Perhaps a new indexing scheme is in order? -- [[User:Jailout2000|<span style="color: #0080C0; font-weight: bold;">Jailout2000</span>]] 04:52, 2 January 2012 (MST)<br />
:Support for different world heights is only partially implemented in the protocol, e.g. the Player Digging packet has Y as a byte, meaning you're constrained to 127. --[[User:Barneygale|Barneygale]] 12:49, 2 January 2012 (MST)<br />
<br />
== 1.1 changes ==<br />
<br />
The protocol version number for 1.1 is 23.<br />
<br />
Also a new string is inserted into the middle of the login packet after the Map Seed field. That increases the size of the packet to 25 plus length of strings.<br />
<br />
== Packet directon changes ==<br />
<br />
Recently there were a lot of packet direction changes from ''Client to Server'' into ''Two-way'' mainly with the Player* packets.<br />
<br />
As far as my proxy implementation goes it has never received those packages from the Notchian server so I will change it back.<br />
<br />
--[[User:Ceiru|Ceiru]] 13:30, 17 March 2012 (MST)<br />
<br />
== Removed the last two "this command is not fully understood" ==<br />
<br />
So if anyone needs to copy-paste it for new packets, here it is:<br />
<br />
<nowiki>[[File:Icon_exclaim.gif|:!:]] This command is not fully understood.</nowiki><br />
<br />
Probably should be a template, but given how advanced our tools are (like burger) and how easy it is to get official explanations from the devs, I doubt anyone will need this again. --[[User:Dx|Dx]] 00:58, 13 June 2012 (MST)<br />
<br />
:This is a relic of when I created this page. My own wiki uses DokuWiki, which provides handy icons like above. Looks like someone downloaded it and re-added it as a media upload when it was copied over. I'd advise not using it again, and instead mention it in the channel and someone will take the time to clarify before ever making a change. [[User:TkTech|TkTech]] 01:54, 13 June 2012 (MST)<br />
<br />
== Strange Packets ==<br />
<br />
At first, everything goes as it says in the documentation. As soon as I send the encrypted login request packet, though, I start getting random packets.<br />
<br />
[http://www.mediafire.com/?kafomz31s8bg1mc Strange Packets]<br />
<br />
Can someone please tell me what I'm doing wrong?<br />
<br />
<br />
:Minecraft uses AES-128-CFB8. Not AES-128-CFB128 (happened to me). Check if this happens<br />
:[[User:Shoghicp|Shoghicp]] ([[User talk:Shoghicp|talk]]) 12:36, 23 November 2012 (MST)<br />
<br />
<br />
OK, after some analysis, I have realized that the problem is in the specification, not my code. It is actually similar to your issue.<br />
<br />
The specs should say that you don't start over counting to 16 when you get a new packet, but rather have to accumulate 16-byte chunks to decrypt (regardless of logical or network packet boundaries).<br />
<br />
:CFB8 means that it has a block size (for encrypt/decrypt) of 1 byte, so you're able to encrypt/decrypt on the fly, and without having to wait for more data. The specifications allow variable block size for CFB, since you only have to xor the generated key with the plaintext.<br />
:[[User:Shoghicp|Shoghicp]] ([[User talk:Shoghicp|talk]]) 05:51, 24 November 2012 (MST)<br />
<br />
Join us on IRC, freenode #mcdevs if you need help<br />
[[User:Md 5|md_5]] ([[User talk:Md 5|talk]]) 05:02, 25 November 2012 (MST)<br />
<br />
== Packet 0x1E description ==<br />
<br />
The description of [[Protocol#Entity (0x1E)|packet 0x1E]] probably needs to be revised. The official server doesn't initialize this packet's class directly anymore, and it can therefore be assumed that this packet doesn't get sent by the official server anymore. The official client should theoretically handle this packet the same as either one of packets 0x1F, 0x20 or 0x21 with additional fields set to 0. [[User:14mRh4X0r|14mRh4X0r]] ([[User talk:14mRh4X0r|talk]]) 18:33, 17 January 2013 (MST)<br />
<br />
== Ambiguity and Typos? ==<br />
<br />
I feel that some of the information on the Protocol page is ambiguous and contains typos<br />
# [[Protocol#Player Digging (0x0E)|Player Digging (0x0E)]] - The field Y states the field type is "byte", which according to [[Data Types]] only ranges from -127 to 127. However, as of 1.4.7 (current version at time of writing) I am able to dig blocks up to 255. Should the field type for field Y be changed to "unsigned byte" similar to [[Protocol#Player Block Placement (0x0F)|Player Block Placement (0x0F)]]?<br />
#* [[Protocol#Use Bed (0x11)|Use Bed (0x11)]] has the same issue described above, and possible others too.<br />
# [[Protocol#Player Position and Look (0x0D)|Player Position and Look (0x0D)]] says that it is ''Two-Way''. However, Player Position (0x0B) and Player Look (0x0C) say only ''Client to Server''. Shouldn't this be changed to ''Client to Server'', or can the server actually send Player Position and Look (0x0D)?<br />
# [[Protocol#Player Look (0x0C)|Player Look (0x0C)]] is unclear. With Entity packets (server to client), there is Entity Look (0x20) and Entity Head Look (0x23), but only a single Look packet for the Player (client to server). How should a server implementing the protocol deal with sending Entity Look and Head Look of other players to clients?<br />
--[[User:Greenegg|Greenegg]] ([[User talk:Greenegg|talk]]) 09:02, 19 February 2013 (MST)<br />
:The server sends 0x0D packets (with reversed Y and Stance) when the player makes an invalid move; Player Look is C->S, Entity Look is S->C. [[User:ZioCrocifisso|ZioCrocifisso]] ([[User talk:ZioCrocifisso|talk]])<br />
<br />
== Why is "float" in 0x08 bold? ==<br />
<br />
Does it mean anything or may be safely removed?<br />
http://wiki.vg/Protocol#0x08<br />
<br />
== Rename category to state ==<br />
<br />
Should we rename the Category column to State? This would make it clearer that the packet type depends on both the packet ID and the current state. —[[User:Fenhl|Fenhl]] 03:32, 21 January 2015 (UTC)<br />
<br />
== String terminator ==<br />
<br />
For strings, I understand that there's a VarInt for the length of the string, and the string itself. This means a null terminator isn't needed to specify the end of the string. Should my code include a null terminator, or should it trim that final character? I'm trying to mirror the behavior of the Notchian client/server. [[User:NickNackGus|NickNackGus]] ([[User talk:NickNackGus|talk]]) 13:22, 25 May 2016 (UTC)<br />
<br />
== What happends if you don't send CPacketConfirmTeleport / what does it do and what are the effects of sending it? (serverbound-related) ==<br />
<br />
I'm just curious.<br />
<br />
== Click Window ==<br />
<br />
The documentation says "Slot" is a short.<br />
So I used PacketContainer#getShorts().read(0), but after some tests I realized that the index 0 was actually "ActionNumber".<br />
To fix it, I changed to PacketContainer#getIntegers().read(1). --RoinujNosde<br />
<br />
: The documentation is about what is delivered in the network stream and not how minecraft is saving the data in the Packet objects, which is what you get when using ProtocolLib. --[[User:Janmm14|Janmm14]] ([[User talk:Janmm14|talk]]) 17:32, 16 October 2019 (UTC)<br />
<br />
== Can't make a valid chunkdata packet (0x21) ==<br />
<br />
Hi i'm stuck with this packet, i can't manage to make a valid packet for the client, i think it's due to my height map wich may not be valid but i don't understand how to make it valid using the doc<br />
<br />
here i try to send this packet to the client (all is 0, i just want to understand the formating before using real data) (in hex, the heightmap is in bold)<br />
c0 02 21 00 00 01 01 '''0a 00 0c 00 0f 4d 4f 54 49 4f 4e 5f 42 4c 4f 43 4b 49 4e 47 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'''<br />
00 00<br />
<br />
i get this error with the client : Internal Exe... io.netty.handler.codec.EncoderException: java.io.EOFException: fieldSize is too long! Lenght is 21577, but maximun is 306<br />
<br />
from my understanding of nbt i don't see how could it read this value somewhere<br />
<br />
i've also tried with a Heightmaps named coumpound<br />
<br />
:Let's disect your packet:<br />
<br />
c0 02 # Packet Length<br />
21 # Packet ID<br />
00 00 01 01 # Chunk X<br />
0a 00 0c 00 # Chunk Z<br />
0f # Full Chunk? (Should be 1 or 0)<br />
4d # Primary BitMask<br />
4f # NBT Tag (Invalid)<br />
54 49 # NBT Tag Name Length (0x5449 = 21577), all NBT data is implicitly inside a Compound<br />
... # Client probably doesn't even read the rest, it knows Packet Length < NBT Tag Name Length<br />
<br />
:You seem to be writing your chunk coordinates as VarInts, when they are specified on the wiki as Ints.<br />
:[[User:YoYoYonnY|YoYoYonnY]] ([[User talk:YoYoYonnY|talk]]) 12:19, 22 April 2020 (UTC)<br />
<br />
oh thx for the response i've made it work since then, and found out that this packet has great potential to crash clients :)<br />
<br />
== Little bug? ==<br />
<br />
In the 'Dimension type' Section:<br />
<br />
{| class="wikitable"<br />
! Name<br />
! Type<br />
!style="width: 250px;" colspan="2"| Meaning<br />
! Values<br />
|-<br />
| coordinate_scale<br />
| TAG_Float<br />
|colspan="2"| The multiplier applied to coordinates when traveling to the dimension.<br />
| 1: true, 0: false.<br />
|}<br />
<br />
Should it be "1: true, 0: false."?<br />
<br />
Sorry for my poor English.<br />
<br />
== Handshake and Login both in 1 packet? ==<br />
Hi, I'm writing a proxy for inspecting the minecraft protocol. This page has been incredibly helpful, but i've noticed that when my 1.16.5 client wants to connect my server it sends a packet like this:<br />
10 00 F2 05 09 6C 6F 63 61 6C 68 6F 73 74 1B 39 02 0A 00 08 6B 61 62 6F 75 74 65 72<br />
that represents the following values:<br />
size: 0x10<br />
Packet ID: 0x0<br />
Protocol Version: 754<br />
Server Address: localhost<br />
Server Port: 6969<br />
Next State: 2<br />
and according to the described protocol this should be all the values, but my client also sends<br />
0A 00 08 6B 61 62 6F 75 74 65 72<br />
I don't have a clue about the first two characters but from 08 and after is my username encoded as a String: kabouter<br />
The server responds with what looks to be an [[Protocol#Encryption_Request]]<br />
Does anyone know about this way to login?<br />
<br />
:There can be multiple Minecraft protocol-level packets in one TCP packet (and one Minecraft packet can be split across multiple TCP packets). What you're seeing is [[Protocol#Handshake|Handshake]] followed by [[Protocol#Login_Start|Login Start]]. --[[User:Pokechu22|Pokechu22]] ([[User talk:Pokechu22|talk]]) 01:27, 15 June 2021 (UTC)<br />
<br />
== Specify the specific DER encoding ==<br />
<br />
I struggled for a while with the DER encoding for Encryption Request because I thought it was PKCS#1 but it's actually PKIX. Could we specify that? [[User:Mattf|Mattf]] ([[User talk:Mattf|talk]]) 19:10, 6 February 2022 (UTC)<br />
<br />
== Differentiation between multiple Minecraft protocol level packets in one TCP packet ==<br />
<br />
I've noticed (and confirmed from this section: https://wiki.vg/Talk:Protocol#Handshake_and_Login_both_in_1_packet.3F) that multiple Minecraft protocol level packets can be put into one TCP packet, and sometimes they can be split across multiple packets. Is there a good way for differentiating between packets/grouping them together? From what I understand there isn't really an "end of packet" marker so it's hard to tell if the client is sending multiple packets or just more data.<br />
<br />
: You should ignore individual tcp packets and jsut see the input as a stream of bytes. Before each packet there is the packet format stuff. You are to expect that after you read all bytes of a minecraft packet (determined by the length varint), that the next bytes are the length of the next minecraft packet. [[User:Janmm14|Janmm14]] ([[User talk:Janmm14|talk]]) 23:25, 16 March 2023 (UTC)<br />
<br />
== LEB128 ==<br />
<br />
I've been implementing LEB128 VarInt in Java using a combination of this video, https://www.youtube.com/watch?v=GuuhUwn-8ug, and the sample values on this page. I've discovered a discrepancy that I'm hoping to find some clarity on. The Sample VarInts show the decimal value 127 being represented as 0x7f, which is true for unsigned integers, however, it seems that the Minecraft protocol expects integers to be signed, and the signed representation of 127 is 0xff 0x00 to account for the sign bit which is expected to be one position lower than the continuation bit in the last byte. Since the binary representation of 127 is 0b0111 1111, the sign bit is active which would be interpreted as negative according to the LEB128 specification. For this reason, an empty byte is added to show that it is positive, hence 0xff 0x00. A similar thing is true for 2097151. Any positive number where the last byte is 127/0x7f requires an additional byte to account for the sign. This statement, "Because Minecraft uses the normal encoding instead of ZigZag encoding, negative values always use the maximum number of bytes," is also not true if, in fact, Minecraft follows LEB128. As long as the negative number can be represented by fewer than 7 bits, the sign bit can be on in the first byte which will yield the correct number when decoded. This seems pretty clear from LEB128, so do these examples need to be updated, or do we need to remove the statement that Minecraft follows LEB128 (with the 5 byte limit imposed on it)? Of course, it could also just be the case that Minecraft VarInts are actually unsigned LEB128 integers. That would render all the statements true requiring that things are updated to drop sign.</div>Janmm14https://wiki.vg/index.php?title=Talk:Protocol&diff=18053Talk:Protocol2023-03-16T23:25:26Z<p>Janmm14: /* Differentiation between multiple Minecraft protocol level packets in one TCP packet */</p>
<hr />
<div>== zlib compress instead of deflate? (0x33) ==<br />
Whilst implementing chunk creation server side in PHP I've found deflate does not work, however the zlib compressed format does. Can anyone else confirm this? --[[User:ody|ody]]<br />
<br />
I can confirm it uses zlib. I'm using the Ionic Zlib library. Using deflate makes the Minecraft client show the error "Bad compressed data format." [[User:DotMaiku|dotMaiku]] 10:13, 23 October 2011 (MST)<br />
<br />
Just strip the first 2 chars... then it works (Java deflate issue) --[[User:Shoghicp|Shoghicp]] 14:21, 12 December 2011 (MST)<br />
<br />
== Too Large? ==<br />
MediaWiki gave me a warning about this page being too large for some browsers. Perhaps it should be split in half? --[[User:SpaceManiac|SpaceManiac]] 00:44, 6 November 2010 (EDT)<br />
<br />
Don't hit Edit for the entire page :P -- [[User:Jailout2000|<span style="color: #0080C0; font-weight: bold;">Jailout2000</span>]] 04:48, 2 January 2012 (MST)<br />
<br />
== Player Position (0x0B) really absolute position? ==<br />
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. [[User:Yen|Yen]]<br />
<br />
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. [[User:ReDucTor|ReDucTor]]<br />
<br />
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. --[[User:Thejoshwolfe|Thejoshwolfe]] 22:55, 25 January 2011 (MST)<br />
<br />
== New Server Packet 0x1c ==<br />
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. [[User:Jorgon3d|Jorgon3d]] 20:34, 10 November 2010 (EST)<br />
<br />
== New Client Packet 0x15 ==<br />
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". [[User:Jorgon3d|Jorgon3d]] 20:34, 10 November 2010 (EST)<br />
<br />
== Version 4 ==<br />
<br />
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 irc.esper.net / #mcc to discuss this new protocol. [[User:ReDucTor|ReDucTor]]<br />
<br />
== C->S Block change with direction=-1 ==<br />
<br />
(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? [[User:ReDucTor|ReDucTor]]<br />
<br />
== New packets introduced in SMP Health update ==<br />
<br />
Looking at the new server JAR I've seen three new packets. IDs are 0x08(<byte>), 0x09(), and 0x26(<int>,<byte>).<br />
<br />
0x08 I'm thinking could be the players health update packet, 0x26 perhaps the 'hit entity' packet, 0x09 I'm not sure.<br />
<br />
I'll confirm what these packets do tonight when I get back from work.<br />
<br />
: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. [[User:Blixt|Blixt]] 08:17, 24 November 2010 (EST)<br />
<br />
: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. [[User:Blixt|Blixt]] 10:01, 24 November 2010 (EST)<br />
<br />
: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. [[User:Blixt|Blixt]] 10:14, 24 November 2010 (EST)<br />
<br />
: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). [[User:benmanns|benmanns]] 10:24, 24 November 2010 (EST)<br />
<br />
::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. [[User:Blixt|Blixt]] 10:59, 24 November 2010 (EST)<br />
<br />
: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 (http://github.com/blixt/pyminecraft) is working fine now, but there seems to be a few bugs relating to burning mobs... don't know why. [[User:Blixt|Blixt]] 10:59, 24 November 2010 (EST)<br />
<br />
::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. :) [[User:Blixt|Blixt]] 14:15, 24 November 2010 (EST)<br />
<br />
== Complex entity packet (0x3B) client->server ==<br />
<br />
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. [[User:Blixt|Blixt]] 11:37, 29 November 2010 (EST)<br />
<br />
== Nov 30 update ==<br />
<br />
Today's update seems to change the following:<br />
<br />
* 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.<br />
* 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.<br />
* There are a lot of new values for packet 0x12 (animate), such as 104 for crouching, 105 for standing up.<br />
<br />
- [[User:Blixt|Blixt]] 17:58, 30 November 2010 (EST)<br />
<br />
: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. – [[User:Blixt|Blixt]] 05:12, 1 December 2010 (EST)<br />
<br />
: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. – [[User:Blixt|Blixt]] 18:04, 1 December 2010 (EST)<br />
<br />
== Map chunks vs. mini chunks ==<br />
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.<br />
<br />
"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<br />
<br />
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.<br />
<br />
== Currently unlisted packets. ==<br />
<br />
Some packets are listed as only going in one direction, but are actually sent the other too. To my knowledge, these are:<br />
<br />
*S->C 0x0a<br />
*S->C 0x0b<br />
*C->S 0x3b (mentioned [[Talk:Protocol#Complex_entity_packet_.280x3B.29_client-.3Eserver|above]])<br />
<br />
The packets are identical to their counterparts. [[User:Barneygale|Barneygale]] 17:02, 15 December 2010 (EST)<br />
<br />
<br />
Were you connecting to a standard server? I've only received 0xa and 0xb from unofficial servers.<br />
--[[User:Axus|Axus]] 13:21, 16 December 2010 (EST)<br />
<br />
== beta update December 20, 2010 ==<br />
<br />
Someone pasted some notes about the protocol changes here:<br />
http://pastebin.com/YfR9XgC2<br />
<br />
Question: Does 0x0D Player Position and Look Client->Server still differ from Server->Client?<br />
<br />
: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: https://github.com/blixt/pyminecraft/commit/af4c9f6b9b2387e429fa425dd5061ef01e03c5aa#diff-1 – [[User:Blixt|Blixt]] 10:30, 21 December 2010 (EST)<br />
<br />
: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. - [[User:Blixt|Blixt]] 19:25, 21 December 2010 (EST)<br />
<br />
::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). - [[User:Blixt|Blixt]] 07:18, 22 December 2010 (EST)<br />
<br />
'''Note!''' As of 1.1, the Transaction packet goes in both direction (previously it was only sent by the server). - [[User:Blixt|Blixt]] 09:56, 22 December 2010 (EST)<br />
<br />
== Why the merge? ==<br />
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. --[[User:SpaceManiac|SpaceManiac]] 13:31, 21 December 2010 (EST)<br />
<br />
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. --[[User:Kev009|kev009]]<br />
<br />
: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. - [[User:Blixt|Blixt]] 19:23, 21 December 2010 (EST)<br />
<br />
== Y/Stance ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
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".<br />
[[User:Moo|Moo]] 10:15, 1 January 2011 (MST)<br />
<br />
<br />
: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. --[[User:Axus|Axus]] 07:16, 3 January 2011 (MST)<br />
<br />
<br />
::"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". [[User:Moo|Moo]] 16:15, 6 January 2011 (MST)<br />
<br />
:I agree with [[User:Axus|Axus]] that "Y" should be the foot position to be consistent with mobs and such. But "Stance" is really the wrong name for the field in the Player Position messages. Like [[User:Moo|Moo]] said, the server calls "stance" the difference between the eyes and feet. The fields in the Player Position messages should be "Y" and "Eye Y". Note that Eye Y is NOT the top of the player's bounding box. Players are 1.74 meters tall, and foot-to-eye distance only goes up to 1.65 meters. Also changing your Eye Y does not make you appear to crouch according to my experiments. --[[User:Thejoshwolfe|Thejoshwolfe]] 04:35, 9 February 2011 (MST)<br />
<br />
== Connection "hash" somewhat misleading? ==<br />
<br />
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:<br />
<br />
public void a(h paramh) {<br />
if (this.e.l) {<br />
this.i = Long.toHexString(d.nextLong());<br />
this.b.a(new h(this.i));<br />
} else {<br />
this.b.a(new h("-"));<br />
}<br />
}<br />
<br />
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? [[User:AnonymousJohn|AnonymousJohn]] 21:21, 9 January 2011 (MST)<br />
<br />
== Beta 1.2 Update ==<br />
<br />
Lots of "interesting" things. <br />
<br />
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 [http://pastebin.com/8fF60ZwQ pastebin]:<br />
<br />
The "metadata" byte is split this way:<br />
*j: First 3 bits, data type<br />
*k: Last 5 bits, data key<br />
<br />
"j" data type:<br />
*0: byte<br />
*1: short<br />
*2: int<br />
*3: float<br />
*4: string (short, bytes)<br />
*5: inventory item (short, byte, short)<br />
<br />
After the "metadata" byte is data of the "data type".<br />
<br />
Example:<br />
*0x00, 0x00, 0x7F:<br />
**j = 0, k = 0. Key = 0, byte value = 0x00.<br />
**End of stream marked by 0x7F.<br />
<br />
*0x00, 0x00, 0x10, 0xFF, 0x7F:<br />
**j = 0, k = 0. Key = 0, byte value = 0x00.<br />
**j = 0, k = 16. Key = 16, byte value = 255.<br />
**End of stream marked by 0x7F.<br />
<br />
== Packet ID datatype explanation ==<br />
<br />
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<br />
whether this is correct, and if so, where it should appear on the page. --[[User:ElectronicsRules|ElectronicsRules]] 04:40, 17 January 2011 (MST)<br />
<br />
OK I added something. --[[User:Axus|Axus]] 05:24, 17 January 2011 (MST)<br />
<br />
== Signed/Unsigned Byte Values ==<br />
<br />
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. --[[User:Thejoshwolfe|Thejoshwolfe]] 20:31, 23 January 2011 (MST)<br />
<br />
== Absolute integer relation to absolute position ==<br />
<br />
The formula is currently stated as:<br />
<br />
absolute_int = (int)(absolute_double / 32.0);<br />
<br />
But in my understanding it should be:<br />
<br />
absolute_int = (int)(absolute_double * 32.0);<br />
<br />
<br />
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 --[[User:Axus|Axus]] 08:44, 30 January 2011 (MST)<br />
<br />
Oops. Good catch. Thanks. --[[User:Thejoshwolfe|Thejoshwolfe]] 16:19, 30 January 2011 (MST)<br />
<br />
== Packet 0xA ==<br />
<br />
I've removed the note about this packet being used for speedhacking detection as it doesn't really make sense considering it is a client-to-server packet. The client is authoritative on movement of the player. Note that the "Player moved wrongly" server console warning is based on movement delta thresholds and not ground/airborne state, which seems to be used exclusively for fall damage application (try forcing the "on ground" state to be True in all c>s player movement packets)<br />
--[[User:Entity|Entity]] 06:05, 5 February 2011 (MST)<br />
<br />
: Forcing 'on ground' state to be True on all c->s movement does indeed eliminate fall damage. However, when 'on ground' is forced True, you cannot ride minecarts - I haven't tested this yet for boats. [[User:Coldelectrons|Coldelectrons]] 09:00, 1 May 2011 (MST)<br />
<br />
== big endian conversion c++ ==<br />
<br />
converting integer types from big endian to little endian and vice versa is rather simple<br />
<br />
when using visual studio this might need some adjusting thou<br />
please make sure you understand this and reimplement it to fit your needs, this is basically just pseudo code that could be compiled with a c++ compiler<br />
<br />
<pre><br />
#include <endian.h><br />
<br />
int32_t toInt(char* somedata)<br />
{<br />
int32_t result = *((int32_t*)somedata);<br />
result = be32toh(result);<br />
return result;<br />
}<br />
<br />
//for doubles and floats you need some more pointer magic (I know it's evil)<br />
<br />
float toFloat(char* somedata)<br />
{<br />
int32_t result = *((int32_t*)somedata);<br />
float* result_pointer = & result;<br />
result = be32toh(result);<br />
return *result_pointer;<br />
}<br />
</pre><br />
--[[User:Ker|Ker]] 14:53, 17 February 2011 (MST)<br />
<br />
== Wolves metadata ==<br />
<br />
I'm handling metadata as explained here http://mc.kev009.com/Protocol#Metadata<br />
When i do ''byte y = x >> 5;'' i keep getting -4 for wolves.<br />
New type of metadata, or is it just my fault? --[[User:Ligustah|Ligustah]] 04:18, 1 April 2011 (MST)<br />
<br />
Not necessarily wrong, X might really be 0xFFC?????, which would make Y look like "-4". Need to be checked of course. --[[User:Axus|Axus]] 08:03, 2 April 2011 (MST)<br />
<br />
I did a little more testing:<br />
https://gist.github.com/900428 I added metadata packets that i received in different situations. --[[User:Ligustah|Ligustah]] 06:35, 3 April 2011 (MST)<br />
<br />
The -4 mentioned earlier was actually my bad. I was using a byte to hold my x while it should have been an unsigned byte. I also updated the paste above and added all indices i observed with this packet. --[[User:Ligustah|Ligustah]] 08:16, 3 April 2011 (MST)<br />
<br />
== Version 11 (Beta 1.5) ==<br />
<br />
Changes I've noticed so far:<br />
<br />
All strings in packets are now 2-byte Big-Endian Unicode. The string length prefix value specifies #of chars not bytes;<br />
<br />
Packet 0x64 appears all different. String remains Modified-UTF. That's a big consistency WTF.<br />
<br />
Packet 0x66 gained a byte between Action and Item ID<br />
<br />
Login 0x01 response from server now appears EID (''int'') followed by 11 bytes (in my case); Looks like ''short,string,long,byte'' and that the second string was dropped. Total packet len 16 + (2 * strSize).<br />
<br />
Weather Event Packet 0x47 (71). (''int, byte, int, int, int'')<br/><br />
So far this packet has only shown itself for a lightning strike. The value of the ''byte'' was then always 1. During all other events (rain start/stop) this packet was nowhere to be seen whether during gameplay or when logging to SMP during a rainstorm. The first ''int'' appears to be an ''Entity ID'' as it always grew with every new strike. Last 3 ''int''s were the X,Y,Z coords respectively of the strike on the ground. It appears to be only S->C --[[User:Xiix|xiix]] 11:19, 20 April 2011 (MST)<br />
<br />
Packet 0x46 was also updated. The packet is the ba class. I grepped for "new ba" and got 3 hits<br />
<br />
The first 2 are in the dg class. These extends the da class which has code that seems to slowly change the raining state. <br />
<code><br />
protected void i()<br />
{<br />
boolean bool = v();<br />
super.i();<br />
<br />
if (bool != v())<br />
if (bool)<br />
this.z.f.a(new ba(2));<br />
else<br />
this.z.f.a(new ba(1));<br />
}<br />
<br />
</code><br />
<br />
The call to v() checks if it is still raining and the call to i() updates the raining counter.<br />
<br />
This basically says that if the rain state changes, send a 0x46 packet.<br />
<br />
1 = begin raining<br />
<br />
2 = end raining<br />
<br />
The next hit is in the du class.<br />
<br />
<code><br />
if (this.e.e.v()) {<br />
localgj.b(new ba(1));<br />
}<br />
</code><br />
<br />
this.e is the MinecraftServer and this.e.e is of type dg. This says that if it is raining, then send a packet with code 1. This method seems to be for logging in.<br />
<br />
The final hit is in the ep class.<br />
<br />
<code><br />
if (localaq2 != null) {<br />
localdc.c(localaq2.a + 0.5F, localaq2.b + 0.1F, localaq2.c + 0.5F, 0.0F, 0.0F);<br />
localdc.a(localaq1);<br />
} else {<br />
localdc.a.b(new ba(0));<br />
}<br />
</code><br />
<br />
The is probably the bed case.<br />
<br />
So, anyway, the possible values would be:<br />
{| class="wikitable"<br />
|-<br />
! Code<br />
! Effect<br />
|-<br />
| 0<br />
| Invalid Bed<br />
|-<br />
| 1<br />
| Begin raining<br />
|-<br />
| 2<br />
| End raining<br />
|}<br />
<br />
Tested and confirmed --[[User:Xiix|xiix]] 15:30, 23 April 2011 (MST)<br />
<br />
The reason byte is a public variable, so it is possible that the code is set from other places. However, since the string array only has 3 values, that suggests that these are the 3 valid values.<br />
<br />
Btw, what is the policy on editing the main protocol page itself?<br />
--[[User:Raphfrk|Raphfrk]] 13:57, 23 April 2011 (MST)<br />
<br />
Mystery packet 0xC8 (200). Follows hitting entities (cows and whatnot) or destroying/placing anything else:<br />
<br />
:* '''bool''' : ''0 entity destroyed; 1 otherwise, even if block is dug out it still exists so maybe that's why this one's always 1'';<br />
:* '''byte''' : ''0 entity/block destroyed; 2 block or item placed'';<br />
:* '''byte''' : ''???'';<br />
:* '''byte''' : ''block/item ID; for entities no clue'';<br />
:* '''byte''' : ''for bool=0 changes depending on what you hold, hit strength maybe'';<br />
<br />
Sent only ''Server''->''Client''.<br />
<br />
--[[User:Xiix|xiix]] 18:20, 19 April 2011 (MST)<br />
<br />
== /* Item data type */ ==<br />
<br />
In my own code, I've simplified things by treating the 3 items (short, optional byte,short) as an Item. It makes my packet format definitions far more readable.<br />
<br />
Any votes in favor of applying the Item definition to the existing page?<br />
<br />
{| class="wikitable"<br />
|- class="row0"<br />
| class="col0" |<br />
! class="col1" | Size<br />
! class="col2" | Range<br />
! class="col3" | Notes<br />
|- class="row1"<br />
! class="col0 centeralign" | Item<br />
| class="col1 centeralign" | 2-5<br />
| class="col2" | N/A<br />
| class="col3" | The structure is (short ItemID, [byte Count, short MetaDamage]). If ItemID == -1, the latter two items are omitted.<br />
|}<br />
-- Coldelectrons<br />
<br />
Would have been fine but 0x05 does not comply with this. Personally I'd rather deal with no rules than rules that have exceptions to them. --[[User:Xiix|xiix]] 09:43, 20 April 2011 (MST)<br />
<br />
== 0x01 Login C->S (Version 11) ==<br />
<br />
'''Since''' I'm a n00b here I won't edit the wiki itself for the fear of being an idiot, but to whoever did: from my own packet analysis the ''''''Client->Server'''''' login 0x01 packet remains unchanged except for the String8->String16 mod. Either Password (or other text) is still possibly sent (now empty) or it has 2 extra (0,0) bytes for whatever reason after username. So the makeup for my money is ''int, string16, string16, long, sbyte''. The length of the packet remains 18 + len of string16's.<br />
<br />
'''Also''', re new String16 thing. Maybe this is common knowledge for java folk, but for us MS/.NET dweebs it is important to know that the new string16 is actually UTF-16BE, as UTF-16 (implies UTF-16LE) decode will render gibberish.<br />
<br />
--[[User:Xiix|xiix]] 09:38, 20 April 2011 (MST)<br />
<br />
Note that it's actually big-endian UCS-2. Treating it as UTF-16 will likely work most of the time, except for crafted packets or otherwise misbehaving peers.<br />
<br />
--[[User:Huin|Huin]] 14:22, 15 May 2011 (MST)<br />
<br />
== /* Byte-packed double? */ ==<br />
<br />
The 3 ints int the weather packet:<br />
Can someone please explain or link to an explanation of how it is you pack a double-precision floating point (8 bytes) number into an int (4 bytes)? Bonus points for why you would want to do it that way?<br />
<br />
I might be wrong but I don't think it is a packed double in a true packing sense. What you do is in this instance is:<br/><br />
: '''double = int / 32.0''' --[[User:Xiix|xiix]] 08:26, 21 April 2011 (MST)<br />
<br />
== 0x32 (pre-chunk) packet optional? ==<br />
<br />
I've tried sending 0x33 packets without 0x32 packets to a 1.5 Beta client on initial connection - the client simply doesn't like it, and just jiggles up and down and the chunks are not visible.<br />
<br />
Sending the same 0x33 packets with 0x32 packets following results in the client falling, but the chunks being completely air-blocks.<br />
<br />
The chunks only appear to load correctly if each 0x33 packet is preceded by the corresponding 0x32 packet (even if not immediately preceding).<br />
<br />
Any other observations on this matter? It appears to me that the 0x32 packet to initialize the chunk is always required, rather than optional as the current text about packet 0x33 might suggest.<br />
<br />
--[[User:Huin|Huin]] 14:19, 15 May 2011 (MST)<br />
<br />
It might only matter on chunks close to the player. I think the "optional" note was more for client writers to allow strange exceptions from Notch's server, than for letting server writers take it easy ;)<br />
--[[User:Axus|Axus]] 16:03, 16 May 2011 (MST)<br />
<br />
Perhaps the times when the notchian server *doesn't* send the 0x32 is when the 0x33 packet is for a subset of the chunk (that is: an already loaded chunk). It would be nice to back this up with evidence of course. --[[User:Huin|Huin]] 14:24, 21 May 2011 (MST)<br />
<br />
== 0x18 - Where does the 'Index' come from? + Metadata String ==<br />
<br />
Can somebody tell me where the index come from? Is this a byte in the metastream or what ?<br />
<br />
Additionally there is no information about the width of the string chars in a metastream.<br />
<br />
--[[User:Chrisliebaer|Chrisliebaer]] 11:39, 22 May 2011 (MST)<br />
<br />
== 0x47 - Weather? ==<br />
<br />
22 May 2011 - Just started writing a library to read and write packets. Tried to follow the spec for 0x47 on the page, and kept getting errors. Looked at a Wireshark capture, and I see the 0x47 packet as being 8 bytes long (9 with the header). The first four bytes look to be an int related to location? It was negative in my capture. The next three bytes were all 0's, then a 0x02. --[[User:Nyasara]]<br />
<br />
== Map data (0x83) ==<br />
<br />
It seems like there is a new packet 0x83 which I can't figure out. Decompiling it reveals four possible forms: http://pastie.org/1975651<br />
--[[User:Sadimusi|Sadimusi]] 04:10, 26 May 2011 (MST)<br />
<br />
I wonder if it handles something related to Nether travel (probably reaching). <br />
<br />
I guess the respawn packet with the new field might be all that was added for handling this. <br />
<br />
Does the Nether have any use for a new world seed? If not, then I guess adding the Nether didn't require that a "change world seed" packet was created. If so, that is pretty disappointing. This would have been a perfect time to add a way to update the client's world seed.<br />
<br />
I am going to run a test tonight to see if the client can handle a second login packet after the update.<br />
<br />
--[[User:Raphfrk|Raphfrk]] 05:12, 26 May 2011 (MST)<br />
<br />
== Block Action? (0x3D) ==<br />
<br />
This packet is<br />
<br />
Int<br />
Int<br />
Byte<br />
Int<br />
Int<br />
<br />
It seems to be related to opening doors<br />
<br />
Int: 1003 (constant)<br />
Int: X position of door<br />
Byte: Y position of door<br />
Int: Z position of door<br />
Int: 0 (constant)<br />
<br />
The packet is sent to all players except the player who opens the door.<br />
--[[User:Raphfrk|Raphfrk]] 11:56, 26 May 2011 (MST)<br />
<br />
It is also sent to all near players when a door is opened with a redstone current.<br />
--[[User:Sadimusi|Sadimusi]] 12:39, 26 May 2011 (MST)<br />
<br />
<br />
:When a player opens a door with right click, the server receives Packet 0xF (block placement, but opens door)<br />
: When a player opens a door with left click, the server receives Packet 0xE+start digging<br />
: 1.7.3<br />
: [[User:Ishinay|Ishinay]] 05:31, 27 August 2011 (MST)<br />
<br />
== Unknown fields in 0x17 may be trajectory. ==<br />
<br />
Especially as there is no other packet to keep track of a ranged weapons trajectory, I deem it likely that the unknown fields encode the trajectory of the projectile.<br />
I haven't done any research into this yet, but I consider two methods of encoding likely:<br />
<br />
If X, Y and Z mark the original start point of the projectile, the last three fields may hold the initial X, Y and Z velocities of the projectile while the integer field encodes the time the projectile has already travelled on that path.<br />
<br />
If X, Y and Z mark the current position of the projectile, the unknown int could instead hold the velocity and the remaining shorts just encode the orientation of the projectile.<br />
<br />
Another, though unlikely option would be to encode the coordinates of the trajectories zenith.<br />
<br />
[[User:SlashLife|SlashLife]] 13:58, 28 May 2011 (MST)<br />
<br />
The fact that these fields were added with the same update the map item was introduced suggests a connection between those two things. Projectiles were added a long time ago and worked without these fields.<br />
--[[User:Sadimusi|Sadimusi]] 16:35, 28 May 2011 (MST)<br />
<br />
<br />
:The "Unknown flag int" actually seems to be the Shooter Entity Id, useful for differenciate the source of the damage. This code exemplifies:<br />
'''<br />
EntityFireball entityfireball = (EntityFireball) this.tracker;<br />
Packet23VehicleSpawn packet23vehiclespawn = new Packet23VehicleSpawn(this.tracker, 63, ((EntityFireball) this.tracker).shooter.id);<br />
'''<br />
:The other 3 int are taken from entity speed, so with much probability marks the initial trayectory tangent as a vector.<br />
'''<br />
double speedX = entity.speedX;<br />
double speedY = entity.speedY;<br />
double speedZ = entity.speedZ;<br />
...<br />
this.trayectoryX = (int) (speedX * 8000.0D);<br />
this.trayectoryY = (int) (speedY * 8000.0D);<br />
this.trayectoryZ = (int) (speedZ * 8000.0D);<br />
'''<br />
[[User:Ishinay|Ishinay]] 05:14, 27 August 2011 (MST)<br />
<br />
== 0x3D packet specs ==<br />
<br />
Packet 0x3D is used to make effects happen on the client.<br />
<br />
Parameters:<br />
int - identifier for effect (client chooses effect using a switch).<br />
int - X<br />
int - Y<br />
int - Z<br />
int - extra data value (used for 3 effects).<br />
<br />
Possible values:<br />
1000 - plays the dispenser fire sound.<br />
1001 - plays the empty dispenser fire sound.<br />
1002 - plays the projectile fire sound (snowball, egg, bow).<br />
1003 - plays the (trap)door open/close sound (50/50 chance of either).<br />
1004 - plays the fire extinguish sound.<br />
1005 - plays a record sound (using the extra data field as an item ID).<br />
2000 - spawns a dispenser fire particle (uses the extra data field for direction, possible 9? values).<br />
2001 - places dig effects on the block at the given location (uses the extra data field as a block ID).<br />
<br />
== 0x6A - Inventory Transaction ==<br />
<br />
The bool in packet 0x6A isn't as simple as 'True if accepted'. I've been playing with inventory logic a bit, and with Notchian client/server, the 'accepted' bool has no immediately discernible rhyme or reason from the server - simply, if a transaction has been accepted, there is a Transaction packet s->c, and if not, not. -- [[User:Coldelectrons|Coldelectrons]] 19:40, 11 June 2011 (MST)<br />
<br />
I tend to agree that its effect is non-obvious. I have noted that sending a "false" for that field results in the client replying with a transaction packet with "true". Beats me what it means :) --[[User:Huin|Huin]] 13:37, 17 June 2011 (MST)<br />
<br />
==== further observations ====<br />
<br />
* When a click leaves an inventory slot empty (picking up a whole stack or item), or when the click changes the amount of the stack in the inventory slot (depositing a single item into a stack), or swapping items, the S->C accepted==False. <br />
<br />
* When a click puts something into an empty slot (a single item or dropping one off of a stack with right-click), the S->C accepted==True<br />
<br />
These two could probably be simplified to "If the slot is empty when it is clicked, S->C accepted=True, else it is False". I haven't observed all conditions in all window types, so some collaboration would be helpful.<br />
<br />
* When the server sends accepted==False, the client will respond with a transaction packet with the same action number, but with accepted==True<br />
<br />
* When the server sends accepted==True, the client does not respond further.<br />
<br />
[[User:Coldelectrons|Coldelectrons]] 15:44, 17 June 2011 (MST)<br />
<br />
== Decimal packet numbers? ==<br />
<br />
Since the Packet classes in the minecraft source (as decompiled by mcp) are named with Decimal numbers it is kind of a hassle when trying to correlate those classes with this list of packets which only have the packet ID shown in hex. Any chance the decimal number could be included in here? In the section heading preferably so it can be seen in the index.<br />
<br />
== Entity Action ??? (0x13) ==<br />
<br />
Seem to be having trouble getting this to work this is sent when someone crouches but it causes a packet error in 1.7.2 was something added? --[[User:Faith2712|Faith2712]] 19:01, 6 July 2011 (MST)<br />
<br />
I believe you have to send the crouch in an entitymetadata packet rather than entityaction (apply the crouch flag to the metadata, then send the edited data).<br />
<br />
: Sneaking is definitely sent with 0x13 as you can see in this (unobscured) snippet from 1.7.3: http://pastie.org/2209271 --[[User:Sadimusi|Sadimusi]] 14:15, 13 July 2011 (MST)<br />
<br />
: : Faith2712 is definitely correct about it being sent from the server as entitymetadata (0x28). Packet 0x13 is client to server only. <br />
: : The byte array for crouching would be: "0x28, [player id(4 bytes)], 0x00, 0x02, 0x7F". 0x02 can be 0x00 (for no animations), 0x01 (for fire), 0x02 (for crouch), 0x03 (for crouch and fire a same time).<br />
: : --[[User:Jasonbay13|Jasonbay13]] 17:01, 11 August 2011 (MST)<br />
<br />
== Piston Direction ==<br />
<br />
Should piston direction 5 not be South? East is in there twice, and south is missed out. I am not certain that it is 5 though, so I have not edited it.<br />
<br />
== Entity Status (0x26) ==<br />
<br />
I've been looking into bukkit stuff today and I think I know what packet 0x26 is! It is sent any time an entity does some animation, especially I noticed with wolves:<br />
HURT (2),<br />
DEATH (3),<br />
SMOKE (6),<br />
HEARTS (7),<br />
WATER (8),<br />
<br />
This is what I've tested out so far. Smoke, Hearts, and water are mainly for wolfie animations. Note that I got these by testing and looking through the minecraft code. That's allowed, right? So far these are the only ones that are sent by the server.<br />
--[[User:Zonedabone|Zonedabone]] 18:08, 12 August 2011 (MST)<br />
<br />
== Yaw diagram needs correcting ==<br />
<br />
While I get the impression from Minecraft's code that ''some'' people *cough* can't tell up from down, left from right, or South from West, we here should be able to.<br />
<br />
The unit circle by the Player Look packet description needs to be changed to reflect what you actually encounter in the game and code.<br />
<br />
I have here a modest example: [[File:Notchian_Coordinate_System.png|200px|thumb|right|Back Arsewards]]<br />
<br />
[[User:Coldelectrons|Coldelectrons]] 14:45, 24 August 2011 (MST)<br />
<br />
== 1.8 Pre-release changes ==<br />
<br />
When refreshing the server list, packet 0xfe is sent. Its length is 1 byte.<br />
The server answers with a Kick(0xff) packet with the motd and player amount in the kick message with the format<br />
<br />
Motd§0§20<br />
<br />
for a server with 0 players, 20 slots, and motd set to Motd.<br />
<br />
--[[User:Zhuowei|Zhuowei]] 17:42, 9 September 2011 (MST)<br />
<br />
: Added, thanks :) [[User:Barneygale|Barneygale]] 23:32, 9 September 2011 (MST)<br />
<br />
== Creative inventory action (0x6B) ==<br />
<br />
Creative inventory action (0x6B) is sent by the client when the user clicks on a quickbar-slot<br />
<br />
== Mob ID for endermen? ==<br />
<br />
I'm pretty sure it's 58, can anyone confirm? [[User:Origamiguy|Origamiguy]] 08:57, 16 September 2011 (MST)<br />
<br />
: Yep, 58. The code:<br />
: addMapping(net.minecraft.src.EntityEnderman.class, "Enderman", 58);<br />
: (the number is the mob ID). --[[User:DuckDuckGo|DuckDuckGo]] 13:50, 29 December 2011 (MST)<br />
<br />
== Add Object/Vehicle correct? ==<br />
<br />
About a week ago, I tried to figure out the last four fields in the [[Protocol#Add_Object.2FVehicle_.280x17.29|Add Object/Vehicle (0x17) packet]]. Can someone check that I got it right? --[[User:Krenair|Krenair]] 08:28, 25 September 2011 (MST)<br />
<br />
== 0x02 (Server to Client), description misunderstunding ==<br />
<br />
The current description is:<br />
"This is the first packet sent when the client connects and is used for Authentication. If the hash is '-', then the client continues without doing name authentication. If the hash is a '+', there is currently no way to send a password in at least version 1.8.1. It should be treated similarly to '+'."<br />
<br />
But the meaning of the sentences is not clear.<br />
* The fact that '+' is used for password authentication is implied by the reader.<br />
* "It should be treated similarly to '+'." Meaning '+' similar to '+'? I guess it was supposed to be "...similarly to '-'."<br />
<br />
Am i correct on the above assumptions?<br />
<br />
== Server poll not working in 1.0? ==<br />
<br />
I've recently converted my software to match up with MC 1.0, but it doesn't seem to be working: it gives me a communication error, as if the packet's contents are incorrect. I'm currently using my 1.8 system, where the 254 packet is received and I immediately respond by sending the 255 Kick packet, with a string, such as MyServer§0§16. Any ideas? Has the protocol changed in this sense since 1.0 was released?<br />
<br />
Fixed: I forgot that my encoder was automatically generating the packet header for packet 254 in response rather than just sending packet 255. It was generating two headers, then the payload, haha. Fixed.<br />
<br />
== More explanations! ==<br />
<br />
I, for one, would be interested to know whether the animation packet is validated in any way by the server. For instance, could you send the eat animation to the server with something other than food in your hand?<br />
--[[User:DuckDuckGo|DuckDuckGo]] 13:47, 29 December 2011 (MST)<br />
:Try it and see --[[User:Barneygale|Barneygale]] 23:07, 29 December 2011 (MST)<br />
<br />
== World height and indexing problem ==<br />
<br />
I was working with [[Realcraft]] earlier tonight, rewriting it and all (I lost the source due to a HDD failure), and I got it working back to the point that it was at when I left it so long ago. I've seemed to have stumbled upon an issue. Only a world height of 128 (Size_Y=127) will work with the indexing (<code>index = y + (z * (Size_Y+1)) + (x * (Size_Y+1) * (Size_Z+1))</code>), any other height and the Minecraft client will show erroneous chunks. Perhaps a new indexing scheme is in order? -- [[User:Jailout2000|<span style="color: #0080C0; font-weight: bold;">Jailout2000</span>]] 04:52, 2 January 2012 (MST)<br />
:Support for different world heights is only partially implemented in the protocol, e.g. the Player Digging packet has Y as a byte, meaning you're constrained to 127. --[[User:Barneygale|Barneygale]] 12:49, 2 January 2012 (MST)<br />
<br />
== 1.1 changes ==<br />
<br />
The protocol version number for 1.1 is 23.<br />
<br />
Also a new string is inserted into the middle of the login packet after the Map Seed field. That increases the size of the packet to 25 plus length of strings.<br />
<br />
== Packet directon changes ==<br />
<br />
Recently there were a lot of packet direction changes from ''Client to Server'' into ''Two-way'' mainly with the Player* packets.<br />
<br />
As far as my proxy implementation goes it has never received those packages from the Notchian server so I will change it back.<br />
<br />
--[[User:Ceiru|Ceiru]] 13:30, 17 March 2012 (MST)<br />
<br />
== Removed the last two "this command is not fully understood" ==<br />
<br />
So if anyone needs to copy-paste it for new packets, here it is:<br />
<br />
<nowiki>[[File:Icon_exclaim.gif|:!:]] This command is not fully understood.</nowiki><br />
<br />
Probably should be a template, but given how advanced our tools are (like burger) and how easy it is to get official explanations from the devs, I doubt anyone will need this again. --[[User:Dx|Dx]] 00:58, 13 June 2012 (MST)<br />
<br />
:This is a relic of when I created this page. My own wiki uses DokuWiki, which provides handy icons like above. Looks like someone downloaded it and re-added it as a media upload when it was copied over. I'd advise not using it again, and instead mention it in the channel and someone will take the time to clarify before ever making a change. [[User:TkTech|TkTech]] 01:54, 13 June 2012 (MST)<br />
<br />
== Strange Packets ==<br />
<br />
At first, everything goes as it says in the documentation. As soon as I send the encrypted login request packet, though, I start getting random packets.<br />
<br />
[http://www.mediafire.com/?kafomz31s8bg1mc Strange Packets]<br />
<br />
Can someone please tell me what I'm doing wrong?<br />
<br />
<br />
:Minecraft uses AES-128-CFB8. Not AES-128-CFB128 (happened to me). Check if this happens<br />
:[[User:Shoghicp|Shoghicp]] ([[User talk:Shoghicp|talk]]) 12:36, 23 November 2012 (MST)<br />
<br />
<br />
OK, after some analysis, I have realized that the problem is in the specification, not my code. It is actually similar to your issue.<br />
<br />
The specs should say that you don't start over counting to 16 when you get a new packet, but rather have to accumulate 16-byte chunks to decrypt (regardless of logical or network packet boundaries).<br />
<br />
:CFB8 means that it has a block size (for encrypt/decrypt) of 1 byte, so you're able to encrypt/decrypt on the fly, and without having to wait for more data. The specifications allow variable block size for CFB, since you only have to xor the generated key with the plaintext.<br />
:[[User:Shoghicp|Shoghicp]] ([[User talk:Shoghicp|talk]]) 05:51, 24 November 2012 (MST)<br />
<br />
Join us on IRC, freenode #mcdevs if you need help<br />
[[User:Md 5|md_5]] ([[User talk:Md 5|talk]]) 05:02, 25 November 2012 (MST)<br />
<br />
== Packet 0x1E description ==<br />
<br />
The description of [[Protocol#Entity (0x1E)|packet 0x1E]] probably needs to be revised. The official server doesn't initialize this packet's class directly anymore, and it can therefore be assumed that this packet doesn't get sent by the official server anymore. The official client should theoretically handle this packet the same as either one of packets 0x1F, 0x20 or 0x21 with additional fields set to 0. [[User:14mRh4X0r|14mRh4X0r]] ([[User talk:14mRh4X0r|talk]]) 18:33, 17 January 2013 (MST)<br />
<br />
== Ambiguity and Typos? ==<br />
<br />
I feel that some of the information on the Protocol page is ambiguous and contains typos<br />
# [[Protocol#Player Digging (0x0E)|Player Digging (0x0E)]] - The field Y states the field type is "byte", which according to [[Data Types]] only ranges from -127 to 127. However, as of 1.4.7 (current version at time of writing) I am able to dig blocks up to 255. Should the field type for field Y be changed to "unsigned byte" similar to [[Protocol#Player Block Placement (0x0F)|Player Block Placement (0x0F)]]?<br />
#* [[Protocol#Use Bed (0x11)|Use Bed (0x11)]] has the same issue described above, and possible others too.<br />
# [[Protocol#Player Position and Look (0x0D)|Player Position and Look (0x0D)]] says that it is ''Two-Way''. However, Player Position (0x0B) and Player Look (0x0C) say only ''Client to Server''. Shouldn't this be changed to ''Client to Server'', or can the server actually send Player Position and Look (0x0D)?<br />
# [[Protocol#Player Look (0x0C)|Player Look (0x0C)]] is unclear. With Entity packets (server to client), there is Entity Look (0x20) and Entity Head Look (0x23), but only a single Look packet for the Player (client to server). How should a server implementing the protocol deal with sending Entity Look and Head Look of other players to clients?<br />
--[[User:Greenegg|Greenegg]] ([[User talk:Greenegg|talk]]) 09:02, 19 February 2013 (MST)<br />
:The server sends 0x0D packets (with reversed Y and Stance) when the player makes an invalid move; Player Look is C->S, Entity Look is S->C. [[User:ZioCrocifisso|ZioCrocifisso]] ([[User talk:ZioCrocifisso|talk]])<br />
<br />
== Why is "float" in 0x08 bold? ==<br />
<br />
Does it mean anything or may be safely removed?<br />
http://wiki.vg/Protocol#0x08<br />
<br />
== Rename category to state ==<br />
<br />
Should we rename the Category column to State? This would make it clearer that the packet type depends on both the packet ID and the current state. —[[User:Fenhl|Fenhl]] 03:32, 21 January 2015 (UTC)<br />
<br />
== String terminator ==<br />
<br />
For strings, I understand that there's a VarInt for the length of the string, and the string itself. This means a null terminator isn't needed to specify the end of the string. Should my code include a null terminator, or should it trim that final character? I'm trying to mirror the behavior of the Notchian client/server. [[User:NickNackGus|NickNackGus]] ([[User talk:NickNackGus|talk]]) 13:22, 25 May 2016 (UTC)<br />
<br />
== What happends if you don't send CPacketConfirmTeleport / what does it do and what are the effects of sending it? (serverbound-related) ==<br />
<br />
I'm just curious.<br />
<br />
== Click Window ==<br />
<br />
The documentation says "Slot" is a short.<br />
So I used PacketContainer#getShorts().read(0), but after some tests I realized that the index 0 was actually "ActionNumber".<br />
To fix it, I changed to PacketContainer#getIntegers().read(1). --RoinujNosde<br />
<br />
: The documentation is about what is delivered in the network stream and not how minecraft is saving the data in the Packet objects, which is what you get when using ProtocolLib. --[[User:Janmm14|Janmm14]] ([[User talk:Janmm14|talk]]) 17:32, 16 October 2019 (UTC)<br />
<br />
== Can't make a valid chunkdata packet (0x21) ==<br />
<br />
Hi i'm stuck with this packet, i can't manage to make a valid packet for the client, i think it's due to my height map wich may not be valid but i don't understand how to make it valid using the doc<br />
<br />
here i try to send this packet to the client (all is 0, i just want to understand the formating before using real data) (in hex, the heightmap is in bold)<br />
c0 02 21 00 00 01 01 '''0a 00 0c 00 0f 4d 4f 54 49 4f 4e 5f 42 4c 4f 43 4b 49 4e 47 00 00 00 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00'''<br />
00 00<br />
<br />
i get this error with the client : Internal Exe... io.netty.handler.codec.EncoderException: java.io.EOFException: fieldSize is too long! Lenght is 21577, but maximun is 306<br />
<br />
from my understanding of nbt i don't see how could it read this value somewhere<br />
<br />
i've also tried with a Heightmaps named coumpound<br />
<br />
:Let's disect your packet:<br />
<br />
c0 02 # Packet Length<br />
21 # Packet ID<br />
00 00 01 01 # Chunk X<br />
0a 00 0c 00 # Chunk Z<br />
0f # Full Chunk? (Should be 1 or 0)<br />
4d # Primary BitMask<br />
4f # NBT Tag (Invalid)<br />
54 49 # NBT Tag Name Length (0x5449 = 21577), all NBT data is implicitly inside a Compound<br />
... # Client probably doesn't even read the rest, it knows Packet Length < NBT Tag Name Length<br />
<br />
:You seem to be writing your chunk coordinates as VarInts, when they are specified on the wiki as Ints.<br />
:[[User:YoYoYonnY|YoYoYonnY]] ([[User talk:YoYoYonnY|talk]]) 12:19, 22 April 2020 (UTC)<br />
<br />
oh thx for the response i've made it work since then, and found out that this packet has great potential to crash clients :)<br />
<br />
== Little bug? ==<br />
<br />
In the 'Dimension type' Section:<br />
<br />
{| class="wikitable"<br />
! Name<br />
! Type<br />
!style="width: 250px;" colspan="2"| Meaning<br />
! Values<br />
|-<br />
| coordinate_scale<br />
| TAG_Float<br />
|colspan="2"| The multiplier applied to coordinates when traveling to the dimension.<br />
| 1: true, 0: false.<br />
|}<br />
<br />
Should it be "1: true, 0: false."?<br />
<br />
Sorry for my poor English.<br />
<br />
== Handshake and Login both in 1 packet? ==<br />
Hi, I'm writing a proxy for inspecting the minecraft protocol. This page has been incredibly helpful, but i've noticed that when my 1.16.5 client wants to connect my server it sends a packet like this:<br />
10 00 F2 05 09 6C 6F 63 61 6C 68 6F 73 74 1B 39 02 0A 00 08 6B 61 62 6F 75 74 65 72<br />
that represents the following values:<br />
size: 0x10<br />
Packet ID: 0x0<br />
Protocol Version: 754<br />
Server Address: localhost<br />
Server Port: 6969<br />
Next State: 2<br />
and according to the described protocol this should be all the values, but my client also sends<br />
0A 00 08 6B 61 62 6F 75 74 65 72<br />
I don't have a clue about the first two characters but from 08 and after is my username encoded as a String: kabouter<br />
The server responds with what looks to be an [[Protocol#Encryption_Request]]<br />
Does anyone know about this way to login?<br />
<br />
:There can be multiple Minecraft protocol-level packets in one TCP packet (and one Minecraft packet can be split across multiple TCP packets). What you're seeing is [[Protocol#Handshake|Handshake]] followed by [[Protocol#Login_Start|Login Start]]. --[[User:Pokechu22|Pokechu22]] ([[User talk:Pokechu22|talk]]) 01:27, 15 June 2021 (UTC)<br />
<br />
== Specify the specific DER encoding ==<br />
<br />
I struggled for a while with the DER encoding for Encryption Request because I thought it was PKCS#1 but it's actually PKIX. Could we specify that? [[User:Mattf|Mattf]] ([[User talk:Mattf|talk]]) 19:10, 6 February 2022 (UTC)<br />
<br />
== Differentiation between multiple Minecraft protocol level packets in one TCP packet ==<br />
<br />
I've noticed (and confirmed from this section: https://wiki.vg/Talk:Protocol#Handshake_and_Login_both_in_1_packet.3F) that multiple Minecraft protocol level packets can be put into one TCP packet, and sometimes they can be split across multiple packets. Is there a good way for differentiating between packets/grouping them together? From what I understand there isn't really an "end of packet" marker so it's hard to tell if the client is sending multiple packets or just more data.<br />
<br />
<br />
: You should ignore individual tcp packets and jsut see the input as a stream of bytes. Before each packet there is the packet format stuff. You are to expect that after you read all bytes of a minecraft packet (determined by the length varint), that the next bytes are the length of the next minecraft packet. [[User:Janmm14|Janmm14]] ([[User talk:Janmm14|talk]]) 23:25, 16 March 2023 (UTC)<br />
<br />
== LEB128 ==<br />
<br />
I've been implementing LEB128 VarInt in Java using a combination of this video, https://www.youtube.com/watch?v=GuuhUwn-8ug, and the sample values on this page. I've discovered a discrepancy that I'm hoping to find some clarity on. The Sample VarInts show the decimal value 127 being represented as 0x7f, which is true for unsigned integers, however, it seems that the Minecraft protocol expects integers to be signed, and the signed representation of 127 is 0xff 0x00 to account for the sign bit which is expected to be one position lower than the continuation bit in the last byte. Since the binary representation of 127 is 0b0111 1111, the sign bit is active which would be interpreted as negative according to the LEB128 specification. For this reason, an empty byte is added to show that it is positive, hence 0xff 0x00. A similar thing is true for 2097151. Any positive number where the last byte is 127/0x7f requires an additional byte to account for the sign. This statement, "Because Minecraft uses the normal encoding instead of ZigZag encoding, negative values always use the maximum number of bytes," is also not true if, in fact, Minecraft follows LEB128. As long as the negative number can be represented by fewer than 7 bits, the sign bit can be on in the first byte which will yield the correct number when decoded. This seems pretty clear from LEB128, so do these examples need to be updated, or do we need to remove the statement that Minecraft follows LEB128 (with the 5 byte limit imposed on it)? Of course, it could also just be the case that Minecraft VarInts are actually unsigned LEB128 integers. That would render all the statements true requiring that things are updated to drop sign.</div>Janmm14https://wiki.vg/index.php?title=Mojang_API&diff=17025Mojang API2021-10-04T21:21:29Z<p>Janmm14: /* Response */</p>
<hr />
<div>This page documents the Mojang Minecraft API. You should note that all public APIs are rate limited so you are expected to cache the results. This is currently set at 600 requests per 10 minutes but this may change. For some parts of the API, demo accounts are sometimes included, sometimes not. Mojang keeps changing this. Authenticated API endpoints require authentication with a bearer token in the request headers. For information about the authentication API, see [[Authentication]].<br />
<br />
== API Status ==<br />
GET <nowiki>https://status.mojang.com/check</nowiki><br />
<br />
Returns status of various Mojang services. Possible values are <code>green</code> (no issues), <code>yellow</code> (some issues), <code>red</code> (service unavailable).<br />
<br />
=== Response ===<br />
<syntaxhighlight lang="json"><br />
[<br />
{<br />
"minecraft.net": "green"<br />
},<br />
{<br />
"session.minecraft.net": "green"<br />
},<br />
{<br />
"account.mojang.com": "green"<br />
},<br />
{<br />
"authserver.mojang.com": "green"<br />
},<br />
{<br />
"sessionserver.mojang.com": "red"<br />
},<br />
{<br />
"api.mojang.com": "green"<br />
},<br />
{<br />
"textures.minecraft.net": "green"<br />
},<br />
{<br />
"mojang.com": "green"<br />
}<br />
]<br />
</syntaxhighlight><br />
<br />
== Username to UUID ==<br />
{{Warning2|Since November 2020, Mojang stopped supporting the timestamp parameter. If a timestamp is provided, it is silently ignored and the current uuid is returned. Please remind them to fix this here: [https://bugs.mojang.com/browse/WEB-3367 WEB-3367]}}<br />
<br />
GET <nowiki>https://api.mojang.com/users/profiles/minecraft/<username>?at=<timestamp></nowiki><br />
<br />
This will return the UUID of the name at the timestamp provided.<br />
<br />
<code>?at=0</code> can be used to get the UUID of the original user of that username, however, it only works if the name was changed at least once, or if the account is legacy.<br />
<br />
* The timestamp is a [[wikipedia:Unix time|UNIX timestamp]] (without milliseconds)<br />
* When the <code>at</code> parameter is not sent, the current time is used<br />
<br />
=== Response ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"name": "KrisJelbring",<br />
"id": "7125ba8b1c864508b92bb5c042ccfe2b"<br />
}<br />
</syntaxhighlight><br />
<br />
* <code>id</code> is the uuid<br />
* <code>name</code> is the '''current name of that uuid''', it is '''not the name requested!'''<br />
* <code>legacy</code> only appears when true (not migrated to mojang account)<br />
* <code>demo</code> only appears when true (account unpaid)<br />
<br />
If there is no player with the given username an HTTP status code 204 (No Content) is sent without any HTTP body.<br /><br />
If the timestamp is not a number, too big or too small the HTTP status code 400 (Bad Request) is sent with an error message looking like this:<br />
<br />
<syntaxhighlight lang="json"><br />
{<br />
"error": "IllegalArgumentException",<br />
"errorMessage": "Invalid timestamp."<br />
}<br />
</syntaxhighlight><br />
<br />
== Usernames to UUIDs ==<br />
POST <nowiki>https://api.mojang.com/profiles/minecraft</nowiki><br />
<br />
This will return player UUIDs and some extras.<br />
<br />
=== Payload ===<br />
<syntaxhighlight lang="json"><br />
[<br />
"foo",<br />
"bar",<br />
"nonExistingPlayer"<br />
]<br />
</syntaxhighlight><br />
<br />
=== Headers ===<br />
Content-Type: application/json<br />
<br />
=== Response ===<br />
<syntaxhighlight lang="json"><br />
[<br />
{<br />
"id": "14f19f5050cb44cd9f0bbe906ad59753",<br />
"name": "Bar"<br />
},<br />
{<br />
"id": "9b15dea6606e47a4a241420251703c59",<br />
"name": "Foo"<br />
}<br />
]<br />
</syntaxhighlight><br />
<br />
* name is case-corrected<br />
* legacy only appears when true (profile not migrated to mojang.com)<br />
* demo only appears when true (account unpaid)<br />
* BadRequestException is returned when any of the usernames is null or otherwise invalid<br />
* You cannot request more than 10 names per request<br />
<br />
== UUID to Name History ==<br />
GET <nowiki>https://api.mojang.com/user/profiles/<uuid>/names</nowiki><br />
<br />
Returns all the usernames this user has used in the past and the one they are using currently. The UUID must be given either without, or correctly formatted hyphens.<br />
<br />
=== Response ===<br />
<syntaxhighlight lang="json"><br />
[<br />
{<br />
"name": "Gold"<br />
},<br />
{<br />
"name": "Diamond",<br />
"changedToAt": 1414059749000<br />
}<br />
]<br />
</syntaxhighlight><br />
<br />
The <code>changedToAt</code> field is a unix timestamp in milliseconds.<br />
<br />
== UUID to Profile and Skin/Cape ==<br />
GET <nowiki>https://sessionserver.mojang.com/session/minecraft/profile/<uuid></nowiki><br />
<br />
This will return the player's username plus any additional information about them (e.g. skins). Example: https://sessionserver.mojang.com/session/minecraft/profile/4566e69fc90748ee8d71d7ba5aa00d20<br />
<br />
This has no ratelimit.<br />
<br />
[[Category:Protocol Details]]<br />
[[Category:Minecraft Modern]]<br />
<br />
=== Response ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"id": "<profile identifier>",<br />
"name": "<player name>",<br />
"properties": [ <br />
{<br />
"name": "textures",<br />
"value": "<base64 string>",<br />
"signature": "<base64 string; signed data using Yggdrasil's private key>" // Only provided if ?unsigned=false is appended to url<br />
}<br />
]<br />
}<br />
</syntaxhighlight><br />
<br />
* <code>"legacy": true</code> will appear in the response if the user has not migrated their minecraft.net account to mojang.<br />
The "value" base64 string for the "textures" object decoded:<br />
<syntaxhighlight lang="json"><br />
{<br />
"timestamp": <java time in ms>,<br />
"profileId": "<profile uuid>",<br />
"profileName": "<player name>",<br />
"signatureRequired": true, // Only present if ?unsigned=false is appended to url<br />
"textures": {<br />
"SKIN": {<br />
"url": "<player skin URL>"<br />
},<br />
"CAPE": {<br />
"url": "<player cape URL>"<br />
}<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
* The timestamp is sometimes in the past (probably due to cached results?)<br />
* The <code>"SKIN"</code> object will have <code>"metadata": {"model": "slim"}</code> if the player model has slim arms (“Alex?” style). For square arms (“Steve?” style), <code>"metadata"</code> will be missing.<br />
* If no custom skin has been set, <code>"SKIN"</code> will be missing.<br>Whether the player has the “Alex?” or “Steve?” skin depends on [http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/java/util/UUID.java#l394 the Java hashCode] of their UUID. Steve is used for even hashes. Example implementations:<br />
** [https://github.com/mapcrafter/mapcrafter-playermarkers/blob/c583dd9157a041a3c9ec5c68244f73b8d01ac37a/playermarkers/player.php#L8-L19 PHP]<br />
** [https://github.com/LapisBlue/Lapitar/blob/55ede80ce4ebb5ecc2b968164afb40f61b4cc509/mc/uuid.go#L34-L36 Go]<br />
** [https://github.com/crafatar/crafatar/blob/9d2fe0c45424de3ebc8e0b10f9446e7d5c3738b2/lib/skins.js#L90-L108 JavaScript] (includes explanation)<br />
** [https://web.archive.org/web/20151022205119/https://gist.github.com/jomo/9968b8d572c38e1b1f4c Java] (includes sample UUIDs)<br />
* Likewise <code>"CAPE"</code> will be missing if the account has no cape.<br />
<br />
== Blocked Servers ==<br />
GET <nowiki>https://sessionserver.mojang.com/blockedservers</nowiki><br />
<br />
Returns a list of SHA1 hashes used to check server addresses against when the client tries to connect.<br />
<br />
Clients check the lowercase name, using the ISO-8859-1 charset, against this list. They will also attempt to check subdomains, replacing each level with a <code>*</code>. Specifically, it splits based off of the <code>.</code> in the domain, goes through each section removing one at a time. For instance, for <code>mc.example.com</code>, it would try <code>mc.example.com</code>, <code>*.example.com</code>, and <code>*.com</code>. With IP addresses (verified by having 4 split sections, with each section being a valid integer between 0 and 255, inclusive<!-- Decompiles seem to mess this up with an empty if, but there is logic for checking the range -->) substitution starts from the end, so for <code>192.168.0.1</code>, it would try <code>192.168.0.1</code>, <code>192.168.0.*</code>, <code>192.168.*</code>, and <code>192.*</code>.<br />
<br />
This check is done by the bootstrap class in netty. The default netty class is overridden by one in the com.mojang:netty dependency loaded by the launcher. This allows it to affect any version that used netty (1.7+)<br />
<br />
=== Response ===<br />
A line-separated list of all SHA1 hashes. Some of the current ~2200 hashes have been cracked.<br />
<br />
{| class="mw-collapsible mw-collapsed"<br />
|-<br />
! style="background: #f8f9fa; border: 1px solid #eaecf0; padding:0.2em 0.3em; text-align: left; font-weight: normal;" | <span style="padding-right: 0.5em;">Known cracked hashes</span><br />
|-<br />
| <pre style="margin-top: 0;"><br />
6f2520f8bd70a718c568ab5274c56bdbbfc14ef4:*.minetime.com<br />
7ea72de5f8e70a2ac45f1aa17d43f0ca3cddeedd:*.trollingbrandon.club<br />
c005ad34245a8f2105658da2d6d6e8545ef0f0de:*.skygod.us<br />
c645d6c6430db3069abd291ec13afebdb320714b:*.mineaqua.es<br />
8bf58811e6ebca16a01b842ff0c012db1171d7d6:*.eulablows.host<br />
8789800277882d1989d384e7941b6ad3dadab430:*.moredotsmoredots.xyz<br />
e40c3456fb05687b8eeb17213a47b263d566f179:*.brandonlovescock.bid<br />
278b24ffff7f9f46cf71212a4c0948d07fb3bc35:*.brandonlovescock.club<br />
c78697e385bfa58d6bd2a013f543cdfbdc297c4f:*.mineaqua.net<br />
b13009db1e2fbe05465716f67c8d58b9c0503520:*.endercraft.com<br />
3e560742576af9413fca72e70f75d7ddc9416020:*.insanefactions.org<br />
986204c70d368d50ffead9031e86f2b9e70bb6d0:*.playmc.mx<br />
65ca8860fa8141da805106c0389de9d7c17e39bf:*.howdoiblacklistsrv.host<br />
7dca807cc9484b1eed109c003831faf189b6c8bf:*.brandonlovescock.online<br />
c6a2203285fb0a475c1cd6ff72527209cc0ccc6e:*.brandonlovescock.press<br />
e3985eb936d66c9b07aa72c15358f92965b1194e:*.insanenetwork.org<br />
b140bec2347bfbe6dcae44aa876b9ba5fe66505b:*.phoenixnexus.net<br />
27ae74becc8cd701b19f25d347faa71084f69acd:*.arkhamnetwork.org<br />
48f04e89d20b15de115503f22fedfe2cb2d1ab12:brandonisan.unusualperson.com<br />
9f0f30820cebb01f6c81f0fdafefa0142660d688:*.kidslovemy500dollarranks.club<br />
cc90e7b39112a48064f430d3a08bbd78a226d670:*.eccgamers.com<br />
88f155cf583c930ffed0e3e69ebc3a186ea8cbb7:*.fucktheeula.com<br />
605e6296b8dba9f0e4b8e43269fe5d053b5f4f1b:*.mojangendorsesbrazzers.webcam<br />
5d2e23d164a43fbfc4e6093074567f39b504ab51:touchmybody.redirectme.net<br />
f3df314d1f816a8c2185cd7d4bcd73bbcffc4ed8:*.mojangsentamonkeyinto.space<br />
073ca448ef3d311218d7bd32d6307243ce22e7d0:*.diacraft.org<br />
33839f4006d6044a3a6675c593fada6a690bb64d:*.diacraft.de<br />
e2e12f3b7b85eab81c0ee5d2e9e188df583fe281:*.eulablacklist.club<br />
11a2c115510bfa6cb56bbd18a7259a4420498fd5:*.slaughterhousepvp.com<br />
75df09492c6c979e2db41116100093bb791b8433:*.timelesspvp.net<br />
d42339c120bc10a393a0b1d2c6a2e0ed4dbdd61b:*.herowars.org<br />
4a1b3b860ba0b441fa722bbcba97a614f6af9bb8:justgiveinandblockddnsbitches.ddns.net<br />
b8c876f599dcf5162911bba2d543ccbd23d18ae5:brandonisagainst.health-carereform.com<br />
9a9ae8e9d0b6f3bf54c266dcd1e4ec034e13f714:brandonwatchesporn.onthewifi.com<br />
336e718ffbc705e76b4a72884172c6b95216b57c:canyouwildcardipsplease.gotdns.ch<br />
27cf97ecf24c92f1fe5c84c5ff654728c3ee37dd:letsplaysome.servecounterstrike.com<br />
32066aa0c7dc9b097eed5b00c5629ad03f250a2d:mojangbrokeintomy.homesecuritymac.com<br />
39f4bbfd123a5a5ddbf97489877831c15a70d7f2:*.primemc.org<br />
f32f824d41aaed334aef248fbe3a0f8ecf4ac1a0:*.meep.in<br />
c22efe4cf7fb319ca2387bbc930c1fdf77ab72fc:*.itsjerryandharry.com<br />
cc8e1ae93571d144bf4b37369cb8466093d6db5a:*.thearchon.net<br />
9c0806e5ffaccb45121e57e4ce88c7bc76e057f1:*.goatpvp.com<br />
5ca81746337088b7617c851a1376e4f00d921d9e:*.gotpvp.com<br />
a5944b9707fdb2cc95ed4ef188cf5f3151ac0525:*.guildcraft.org<br />
e7210344ab0a2206da3bb21d03e406c0f1365981:*.redesky.com<br />
de2cbbda331606a68ec2f88827f06e24cc5d0a24:*.mushmc.com.br<br />
</pre><br />
|}<br />
<br />
A quite large list of known hashes is available at: https://github.com/Reecepbcups/FollowTheEULA/blob/master/blockedServersList.txt<br><br />
Some hashes on there might not be in the current hashes list anymore.<br />
<br />
== Statistics ==<br />
POST <nowiki>https://api.mojang.com/orders/statistics</nowiki><br />
<br />
Get statistics on the sales of Minecraft.<br />
<br />
=== Payload ===<br />
The payload is a JSON list of options under the metricKeys key.<br />
You will receive a single object corresponding to the sum of sales of the requested type(s).<br />
You must request at least one type of sale.<br />
Below is the default list used by https://minecraft.net/en/stats/<br />
<syntaxhighlight lang="json"><br />
{<br />
"metricKeys": [<br />
"item_sold_minecraft",<br />
"prepaid_card_redeemed_minecraft"<br />
]<br />
}<br />
</syntaxhighlight><br />
<br />
Valid options are:<br />
item_sold_minecraft<br />
prepaid_card_redeemed_minecraft<br />
item_sold_cobalt<br />
item_sold_scrolls<br />
prepaid_card_redeemed_cobalt<br />
item_sold_dungeons<br />
<br />
=== Headers ===<br />
Content-Type: application/json<br />
<br />
=== Response ===<br />
A JSON object is returned with the total amount of copies sold, the number of copies sold in the last 24 hours and how many sales there are per second.<br />
<syntaxhighlight lang="json"><br />
{<br />
"total": integer total amount sold,<br />
"last24h": integer total sold in last 24 hours,<br />
"saleVelocityPerSeconds": decimal average sales per second<br />
}<br />
</syntaxhighlight><br />
<br />
== Profile Information ==<br />
GET <nowiki>https://api.minecraftservices.com/minecraft/profile</nowiki><br />
<br />
This API endpoint fetches information about the current account including UUID, username, skins, and capes.<br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
<br />
=== Response ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"id": "<profile UUID>",<br />
"name": "<profile name>",<br />
"skins": [<br />
{<br />
"id": "8c94945e-d0b4-4df8-97d1-d8d397624f93",<br />
"state": "ACTIVE",<br />
"url": "<URL to the skin image>",<br />
"variant": "CLASSIC" // Either SLIM or CLASSIC<br />
}<br />
],<br />
"capes": []<br />
}<br />
</syntaxhighlight><br />
<br />
== Profile Name Change Information ==<br />
GET <nowiki>https://api.minecraftservices.com/minecraft/profile/namechange</nowiki><br />
<br />
This API endpoint fetches information about the profile name such as the date the name was changed and the date the account was created.<br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
<br />
=== Response ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"changedAt": "2019-12-17T03:19:31Z",<br />
"createdAt": "2015-11-13T01:59:46Z",<br />
"nameChangeAllowed": true<br />
}<br />
</syntaxhighlight><br />
<br />
== Check Product Voucher ==<br />
GET <nowiki>https://api.minecraftservices.com/productvoucher/giftcode</nowiki><br />
<br />
This API endpoint checks if the gift card is valid.<br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
<br />
=== Error Response ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"path": "/productvoucher/giftcode",<br />
"errorType": "NOT_FOUND",<br />
"error": "NOT_FOUND",<br />
"errorMessage": "The server has not found anything matching the request URI",<br />
"developerMessage": "The server has not found anything matching the request URI"<br />
}<br />
</syntaxhighlight><br />
<br />
{| class="wikitable"<br />
|'''Status Codes'''<br />
|'''Responses'''<br />
|-<br />
|404<br />
|Product Voucher is invalid. (Either claimed or not activated)<br />
|-<br />
|200/204<br />
|Success (Product voucher is valid)<br />
|}<br />
<br />
== Name Availability ==<br />
GET <nowiki>https://api.minecraftservices.com/minecraft/profile/name/</nowiki>'''<name>'''/available<br />
<br />
This API endpoint checks if the given name is available.<br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
<br />
=== Response ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"status": "DUPLICATE" // Either DUPLICATE or AVAILABLE<br />
}<br />
</syntaxhighlight><br />
<br />
== Change Name ==<br />
PUT <nowiki>https://api.minecraftservices.com/minecraft/profile/name/</nowiki>'''<name>'''<br />
<br />
This will set the name for the account that the access token in the Authorization header belongs to.<br />
<br />
=== Payload ===<br />
No payload needed.<br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
<br />
=== Success Response ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"id" : "31e0ccbef5fa4eb988592f30516f65fe",<br />
"name" : "newname34234", // newly acquired name<br />
"skins" : [<br />
{<br />
"id" : "c97f6fea-6ca8-4bf0-bdae-b7cf91fb089c", //uuid of account<br />
"state" : "ACTIVE",<br />
"url" : "<nowiki>http://textures.minecraft.net/texture/3b60a1f6d562f52aaebbf1434f1de147933a3affe0e764fa49ea057536623cd3</nowiki>", //skin URL<br />
"variant" : "SLIM"<br />
}<br />
],<br />
"capes" : []<br />
}<br />
</syntaxhighlight><br />
<br />
=== Error Response ===<br />
Upon error, the server will send back a JSON with the error.<br />
<br />
<syntaxhighlight lang="json"><br />
{<br />
"path": "/minecraft/profile/name/<name>",<br />
"errorType": "FORBIDDEN", // Optional, type of error<br />
"error": "FORBIDDEN", // Optional, name of the error<br />
"details": { // Optional, details about the name<br />
"status": "DUPLICATE"<br />
},<br />
"errorMessage": "Optional error message",<br />
"developerMessage": "Optional error message, same as errorMessage"<br />
}<br />
</syntaxhighlight><br />
<br />
{| class="wikitable"<br />
|'''Status Codes'''<br />
|'''Responses'''<br />
|-<br />
|400<br />
|Name is invalid, longer than 16 characters or contains characters other than (a-zA-Z0-9_)<br />
|-<br />
|403<br />
|Name is unavailable (Either taken or has not become available)<br />
|-<br />
|401<br />
|Unauthorized (Bearer token expired or is not correct)<br />
|-<br />
|429<br />
|Too many requests sent<br />
|-<br />
|500<br />
|Timed out (API lagged out and could not respond)<br />
|-<br />
|200<br />
|Success (Name changed)<br />
|}<br />
<br />
== Change Skin ==<br />
POST <nowiki>https://api.minecraftservices.com/minecraft/profile/skins</nowiki><br />
<br />
This will set the skin for the selected profile, but Mojang's servers will fetch the skin from a URL. <br />
<br />
=== Payload ===<br />
The payload for this API consists of a JSON object containing the URL and variant<br />
<br />
<syntaxhighlight lang="json"><br />
{<br />
"variant": "classic",<br />
"url": "http://assets.mojang.com/SkinTemplates/steve.png"<br />
}<br />
</syntaxhighlight><br />
<br />
variant is either "classic" or "slim"<br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
Content-Type: application/json<br />
<br />
=== Response ===<br />
Upon error, the server will send back a JSON with the error. (Success is a blank payload)<br />
<br />
=== Example ===<br />
curl -H "Authorization: Bearer '''<access token>'''" -H "Content-Type: application/json; charset=utf-8" --request POST --data '{"variant": "classic", "url": "http://assets.mojang.com/SkinTemplates/steve.png"}' <nowiki>https://api.minecraftservices.com/minecraft/profile/skins</nowiki><br />
<br />
== Upload Skin ==<br />
POST <nowiki>https://api.minecraftservices.com/minecraft/profile/skins</nowiki><br />
<br />
This uploads a skin to Mojang's servers. It also sets the user's skin. This works on legacy accounts as well.<br />
<br />
=== Payload ===<br />
The payload for this API consists of multipart form data. There are two parts (order does not matter b/c of boundary):<br />
{| class="wikitable"<br />
|'''variant'''<br />
|Either "classic" for normal models or "slim" for slim models.<br />
|-<br />
|'''file'''<br />
|Raw image file data<br />
|}<br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
<br />
=== Response ===<br />
No response unless an error occurred.<br />
<br />
=== Example ===<br />
curl -X POST -H "Authorization: Bearer '''<access token>'''" -F variant=classic -F file="@steeevee.png;type=image/png" <nowiki>https://api.minecraftservices.com/minecraft/profile/skins</nowiki><br />
<br />
<syntaxhighlight lang="http"><br />
PUT /minecraft/profile/skins HTTP/1.1<br />
Host: api.minecraftservices.com<br />
User-Agent: curl/7.49.0<br />
Accept: */*<br />
Authorization: Bearer '''<access token>'''<br />
Content-Length: '''<length>'''<br />
Content-Type: multipart/form-data; boundary='''<boundary>'''<br />
<br />
--'''<boundary>'''<br />
Content-Disposition: form-data; name="variant"<br />
<br />
classic<br />
--'''<boundary>'''<br />
Content-Disposition: form-data; name="file"; filename="alex.png"<br />
Content-Type: image/png<br />
<br />
'''<image data>'''<br />
--'''<boundary>'''--<br />
</syntaxhighlight><br />
<br />
== Reset Skin ==<br />
DELETE <nowiki>https://api.mojang.com/user/profile/</nowiki>'''<uuid>'''/skin<br />
<br />
Resets the user's skin to the default one.<br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
<br />
=== Response ===<br />
No response unless an error occurred.<br />
<br />
=== Example ===<br />
curl -X DELETE -H "Authorization: Bearer '''<access token>'''" <nowiki>https://api.mojang.com/user/profile/</nowiki>'''<uuid>'''/skin<br />
<br />
<syntaxhighlight lang="http"><br />
DELETE /user/profile/'''<uuid>'''/skin HTTP/1.1<br />
Host: api.mojang.com<br />
User-Agent: curl/7.46.0<br />
Accept: */*<br />
Authorization: Bearer '''<access token>'''<br />
</syntaxhighlight><br />
<br />
== Hide Cape ==<br />
DELETE <nowiki>https://api.minecraftservices.com/minecraft/profile/capes/active</nowiki><br />
<br />
Prevents the current cape from being shown on the account.<br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
<br />
=== Response ===<br />
There is no response body.<br />
<br />
{| class="wikitable"<br />
|'''Status Codes'''<br />
|'''Responses'''<br />
|-<br />
|401<br />
|Unauthorized (Bearer token expired or is not correct)<br />
|-<br />
|200<br />
|Success (Cape has been hidden)<br />
|}<br />
<br />
== Show Cape ==<br />
PUT <nowiki>https://api.minecraftservices.com/minecraft/profile/capes/active</nowiki><br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
Content-Type: application/json<br />
<br />
=== Success Response ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"id": "<profile UUID>",<br />
"name": "<profile name>",<br />
"skins": [<br />
{<br />
"id": "8c94945e-d0b4-4df8-97d1-d8d397624f93",<br />
"state": "ACTIVE",<br />
"url": "<URL to the skin image>",<br />
"variant": "CLASSIC" // Either SLIM or CLASSIC<br />
}<br />
],<br />
"capes": [<br />
{<br />
"id": "capeid",<br />
"state": "ACTIVE",<br />
"url": "<URL to the cape image>",<br />
"alias": "Cape Name"<br />
} <br />
]<br />
}<br />
</syntaxhighlight><br />
<br />
=== Error Response ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"path": "/minecraft/profile/capes/active",<br />
"errorMessage": "profile does not own cape",<br />
"developerMessage": "profile does not own cape"<br />
}<br />
</syntaxhighlight><br />
<br />
=== Payload ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"capeId": "Id"<br />
}<br />
</syntaxhighlight><br />
<br />
{| class="wikitable"<br />
|'''Status Codes'''<br />
|'''Responses'''<br />
|-<br />
|200<br />
|Success<br />
|-<br />
|400<br />
|Bad Request (Profile doesn't own cape)<br />
|-<br />
|401<br />
|Unauthorized (Bearer token expired or is not correct)<br />
|}<br />
<br />
== Verify Security Location ==<br />
GET <nowiki>https://api.mojang.com/user/security/location</nowiki><br />
<br />
Verify's that the current IP is trusted by the server for the account and the token can be used.<br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
<br />
=== Success Response ===<br />
204 NO CONTENT<br />
<br />
=== Error Response ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"error": "ForbiddenOperationException",<br />
"errorMessage": "Current IP is not secured"<br />
}<br />
</syntaxhighlight><br />
<br />
== Get Security Questions ==<br />
GET <nowiki>https://api.mojang.com/user/security/challenges</nowiki><br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
<br />
=== Response ===<br />
<syntaxhighlight lang="json"><br />
[<br />
{<br />
"answer": {<br />
"id": 123<br />
},<br />
"question": {<br />
"id": 1,<br />
"question": "What is your favorite pet's name?"<br />
}<br />
},<br />
{<br />
"answer": {<br />
"id": 456<br />
},<br />
"question": {<br />
"id": 2,<br />
"question": "What is your favorite movie?"<br />
}<br />
},<br />
{<br />
"answer": {<br />
"id": 789<br />
},<br />
"question": {<br />
"id": 3,<br />
"question": "What is your favorite author's last name?"<br />
}<br />
}<br />
],<br />
</syntaxhighlight><br />
<br />
{| class="mw-collapsible mw-collapsed" style="margin-top: 0.5em;"<br />
|-<br />
! style="background: #f8f9fa; border: 1px solid #eaecf0; padding:0.2em 0.3em; text-align: left; font-weight: normal;" | <span style="padding-right: 0.5em;">Possible questions IDs</span><br />
|-<br />
| <pre style="margin-top: 0;"><br />
1 What is your favorite pet's name?<br />
2 What is your favorite movie?<br />
3 What is your favorite author's last name?<br />
4 What is your favorite artist's last name?<br />
5 What is your favorite actor's last name?<br />
6 What is your favorite activity?<br />
7 What is your favorite restaurant?<br />
8 What is the name of your favorite cartoon?<br />
9 What is the name of the first school you attended?<br />
10 What is the last name of your favorite teacher?<br />
11 What is your best friend's first name?<br />
12 What is your favorite cousin's name?<br />
13 What was the first name of your first girl/boyfriend?<br />
14 What was the name of your first stuffed animal?<br />
15 What is your mother's middle name?<br />
16 What is your father's middle name?<br />
17 What is your oldest sibling's middle name?<br />
18 In what city did your parents meet?<br />
19 In what hospital were you born?<br />
20 What is your favorite team?<br />
21 How old were you when you got your first computer?<br />
22 How old were you when you got your first gaming console?<br />
23 What was your first video game?<br />
24 What is your favorite card game?<br />
25 What is your favorite board game?<br />
26 What was your first gaming console?<br />
27 What was the first book you ever read?<br />
28 Where did you go on your first holiday?<br />
29 In what city does your grandmother live?<br />
30 In what city does your grandfather live?<br />
31 What is your grandmother's first name?<br />
32 What is your grandfather's first name?<br />
33 What is your least favorite food?<br />
34 What is your favorite ice cream flavor?<br />
35 What is your favorite ice cream flavor?<br />
36 What is your favorite place to visit?<br />
37 What is your dream job?<br />
38 What color was your first pet?<br />
39 What is your lucky number?<br />
</pre><br />
|}<br />
<br />
== Send Security Answers ==<br />
POST <nowiki>https://api.mojang.com/user/security/location</nowiki><br />
<br />
=== Payload ===<br />
<syntaxhighlight lang="json"><br />
[<br />
{<br />
"id": 123,<br />
"answer" : "foo"<br />
},<br />
{<br />
"id": 456,<br />
"answer" : "bar"<br />
},<br />
{<br />
"id": 589,<br />
"answer" : "baz"<br />
}<br />
]<br />
</syntaxhighlight><br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
Content-Type: application/json<br />
<br />
=== Success Response ===<br />
204 NO CONTENT<br />
<br />
=== Error Response ===<br />
On failure, you will get some sort of error. Unless it's a syntax or json structure error, it will be this:<br />
<br />
<syntaxhighlight lang="json"><br />
{<br />
"error": "ForbiddenOperationException",<br />
"errorMessage": "At least one answer was incorrect"<br />
}<br />
</syntaxhighlight><br />
<br />
== Get Account Migration Information ==<br />
GET <nowiki>https://api.minecraftservices.com/rollout/v1/msamigration</nowiki><br />
<br />
This API endpoint fetches information about the current account's ability to migrate.<br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
<br />
=== Response ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"feature": "msamigration",<br />
"rollout": true<br />
}<br />
</syntaxhighlight><br />
<br />
== Account Migration OTP ==<br />
POST <nowiki>https://api.minecraftservices.com/twofactorauth/migration/otp</nowiki><br />
<br />
This API endpoint returns an OTP Id used for transferring the current account later.<br />
<br />
=== Payload ===<br />
No payload needed.<br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
Content-Type: application/json<br />
<br />
=== Success Response ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"otpId" : "cb694fff-220a-4213-a12e-e54e49fd7dd4"<br />
}<br />
</syntaxhighlight><br />
<br />
{| class="wikitable"<br />
|'''Status Codes'''<br />
|'''Responses'''<br />
|-<br />
|201<br />
|Success (OTP has been received successfully)<br />
|-<br />
|401<br />
|Unauthorized (Bearer token expired or is not correct)<br />
|}<br />
<br />
== Verify Account Migration OTP ==<br />
POST <nowiki>https://api.minecraftservices.com/twofactorauth/migration/otp/<otpId>/verify</nowiki><br />
<br />
Verifies the code sent to an account's email after a POST request to /otp.<br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
Content-Type: application/json<br />
<br />
=== Payload ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"otp": "code"<br />
}<br />
</syntaxhighlight><br />
<br />
{| class="wikitable"<br />
|'''Status Codes'''<br />
|'''Responses'''<br />
|-<br />
|204<br />
|Success<br />
|-<br />
|401<br />
|Unauthorized (Bearer token expired or is not correct)<br />
|}<br />
<br />
=== Response ===<br />
There is no response body.<br />
<br />
<br />
== Submit Migration Token ==<br />
POST <nowiki>https://api.minecraftservices.com/migration/token</nowiki><br />
<br />
Used to submit the current account's email upon migrating.<br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
Content-Type: application/json<br />
<br />
=== Payload ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"sessionEmail": "accountemail"<br />
}<br />
</syntaxhighlight><br />
<br />
{| class="wikitable"<br />
|'''Status Codes'''<br />
|'''Responses'''<br />
|-<br />
|200<br />
|Success<br />
|-<br />
|401<br />
|Unauthorized (Bearer token expired or is not correct)<br />
|}<br />
<br />
=== Response ===<br />
There is no response body.<br />
<br />
== Connect Xbox Live ==<br />
POST <nowiki>https://sisu.xboxlive.com/connect/XboxLive</nowiki><br />
<br />
Connects the Mojang account to Xbox live.<br />
<br />
=== Headers ===<br />
Content-Type: application/json<br />
<br />
=== Payload ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"AppId": "1142970254",<br />
"Callback": "https://www.minecraft.net/en-us/link-accounts",<br />
"CobrandId": "fb937bf5-b9a1-4b61-b744-82f9a1adc248",<br />
"ProfileName": "accountname",<br />
"State": "postUpsell",<br />
"TitleId": "896928775",<br />
"UseModernGamertag": true<br />
}<br />
</syntaxhighlight><br />
<br />
{| class="wikitable"<br />
|'''Status Codes'''<br />
|'''Responses'''<br />
|-<br />
|200<br />
|Success<br />
|-<br />
|401<br />
|Unauthorized<br />
|}<br />
<br />
=== Success Response ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"RedirectTo" : "authflowloginurl"<br />
}<br />
</syntaxhighlight><br />
<br />
== Examples ==<br />
* [https://github.com/hawezo/MojangSharp C#] - Full API wrapper<br />
* [https://github.com/CmlLib/MojangAPI C#] - Full API wrapper with Mojang/Microsoft Authentication<br />
* [https://github.com/spnda/dart_minecraft Dart] - Almost full API wrapper with Mojang Authentication<br />
* [https://github.com/Lukaesebrot/mojango Go] - Full API wrapper<br />
* [https://github.com/PhilipBorgesen/minecraft/tree/master/profile Go] - UUIDs or names to profiles with skins, capes and name histories<br />
* [https://github.com/summer/mojang Python] - Full API Wrapper. Also supports authentication & parts of the Minecraft website<br />
* [https://github.com/Lucino772/pymojang Python] - Pymojang is a full wrapper around de Mojang API and Mojang Authentication API. Also support RCON, Query and Server List Ping<br />
* [https://github.com/SynchronousX/mojang-api Python] - Full API wrapper (not updated since 2018)<br />
* [https://github.com/techkid6/AccountsClientPython Python] - UUIDs or names to profiles (not updated since 2018)<br />
* [https://github.com/elyby/mojang-api PHP] - Complete Mojang's API wrapper<br />
* [https://github.com/MineTheCube/MojangAPI PHP] - UUIDs or names to profiles with skins, heads and name histories<br />
* [https://gist.github.com/ezfe/a71feccd3a837a2592f1 PHP] - UUIDs to names<br />
* [https://github.com/ozzyfant/AccountsClientPHP PHP] - UUIDs to names, names to uuids<br />
* [https://github.com/SparklingComet/java-mojang-api Java] - Almost full API Wrapper<br />
* [https://github.com/dpkgsoft/mojang Java] - Almost full API Wrapper with auth<br />
* [https://github.com/novastosha/NMoyang Java] - Almost full API with Mojang Authentication and can also work as a console Application.<br />
* [https://github.com/thechunknetwork/mojang-api JavaScript] - UUIDs or names to profiles with skins, capes and name histories<br />
<br />
[[Category:Protocol Details]]<br />
[[Category:Minecraft Modern]]</div>Janmm14https://wiki.vg/index.php?title=Mojang_API&diff=17024Mojang API2021-10-04T21:21:04Z<p>Janmm14: /* Blocked Servers */ Add link to someone's known hashes list</p>
<hr />
<div>This page documents the Mojang Minecraft API. You should note that all public APIs are rate limited so you are expected to cache the results. This is currently set at 600 requests per 10 minutes but this may change. For some parts of the API, demo accounts are sometimes included, sometimes not. Mojang keeps changing this. Authenticated API endpoints require authentication with a bearer token in the request headers. For information about the authentication API, see [[Authentication]].<br />
<br />
== API Status ==<br />
GET <nowiki>https://status.mojang.com/check</nowiki><br />
<br />
Returns status of various Mojang services. Possible values are <code>green</code> (no issues), <code>yellow</code> (some issues), <code>red</code> (service unavailable).<br />
<br />
=== Response ===<br />
<syntaxhighlight lang="json"><br />
[<br />
{<br />
"minecraft.net": "green"<br />
},<br />
{<br />
"session.minecraft.net": "green"<br />
},<br />
{<br />
"account.mojang.com": "green"<br />
},<br />
{<br />
"authserver.mojang.com": "green"<br />
},<br />
{<br />
"sessionserver.mojang.com": "red"<br />
},<br />
{<br />
"api.mojang.com": "green"<br />
},<br />
{<br />
"textures.minecraft.net": "green"<br />
},<br />
{<br />
"mojang.com": "green"<br />
}<br />
]<br />
</syntaxhighlight><br />
<br />
== Username to UUID ==<br />
{{Warning2|Since November 2020, Mojang stopped supporting the timestamp parameter. If a timestamp is provided, it is silently ignored and the current uuid is returned. Please remind them to fix this here: [https://bugs.mojang.com/browse/WEB-3367 WEB-3367]}}<br />
<br />
GET <nowiki>https://api.mojang.com/users/profiles/minecraft/<username>?at=<timestamp></nowiki><br />
<br />
This will return the UUID of the name at the timestamp provided.<br />
<br />
<code>?at=0</code> can be used to get the UUID of the original user of that username, however, it only works if the name was changed at least once, or if the account is legacy.<br />
<br />
* The timestamp is a [[wikipedia:Unix time|UNIX timestamp]] (without milliseconds)<br />
* When the <code>at</code> parameter is not sent, the current time is used<br />
<br />
=== Response ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"name": "KrisJelbring",<br />
"id": "7125ba8b1c864508b92bb5c042ccfe2b"<br />
}<br />
</syntaxhighlight><br />
<br />
* <code>id</code> is the uuid<br />
* <code>name</code> is the '''current name of that uuid''', it is '''not the name requested!'''<br />
* <code>legacy</code> only appears when true (not migrated to mojang account)<br />
* <code>demo</code> only appears when true (account unpaid)<br />
<br />
If there is no player with the given username an HTTP status code 204 (No Content) is sent without any HTTP body.<br /><br />
If the timestamp is not a number, too big or too small the HTTP status code 400 (Bad Request) is sent with an error message looking like this:<br />
<br />
<syntaxhighlight lang="json"><br />
{<br />
"error": "IllegalArgumentException",<br />
"errorMessage": "Invalid timestamp."<br />
}<br />
</syntaxhighlight><br />
<br />
== Usernames to UUIDs ==<br />
POST <nowiki>https://api.mojang.com/profiles/minecraft</nowiki><br />
<br />
This will return player UUIDs and some extras.<br />
<br />
=== Payload ===<br />
<syntaxhighlight lang="json"><br />
[<br />
"foo",<br />
"bar",<br />
"nonExistingPlayer"<br />
]<br />
</syntaxhighlight><br />
<br />
=== Headers ===<br />
Content-Type: application/json<br />
<br />
=== Response ===<br />
<syntaxhighlight lang="json"><br />
[<br />
{<br />
"id": "14f19f5050cb44cd9f0bbe906ad59753",<br />
"name": "Bar"<br />
},<br />
{<br />
"id": "9b15dea6606e47a4a241420251703c59",<br />
"name": "Foo"<br />
}<br />
]<br />
</syntaxhighlight><br />
<br />
* name is case-corrected<br />
* legacy only appears when true (profile not migrated to mojang.com)<br />
* demo only appears when true (account unpaid)<br />
* BadRequestException is returned when any of the usernames is null or otherwise invalid<br />
* You cannot request more than 10 names per request<br />
<br />
== UUID to Name History ==<br />
GET <nowiki>https://api.mojang.com/user/profiles/<uuid>/names</nowiki><br />
<br />
Returns all the usernames this user has used in the past and the one they are using currently. The UUID must be given either without, or correctly formatted hyphens.<br />
<br />
=== Response ===<br />
<syntaxhighlight lang="json"><br />
[<br />
{<br />
"name": "Gold"<br />
},<br />
{<br />
"name": "Diamond",<br />
"changedToAt": 1414059749000<br />
}<br />
]<br />
</syntaxhighlight><br />
<br />
The <code>changedToAt</code> field is a unix timestamp in milliseconds.<br />
<br />
== UUID to Profile and Skin/Cape ==<br />
GET <nowiki>https://sessionserver.mojang.com/session/minecraft/profile/<uuid></nowiki><br />
<br />
This will return the player's username plus any additional information about them (e.g. skins). Example: https://sessionserver.mojang.com/session/minecraft/profile/4566e69fc90748ee8d71d7ba5aa00d20<br />
<br />
This has no ratelimit.<br />
<br />
[[Category:Protocol Details]]<br />
[[Category:Minecraft Modern]]<br />
<br />
=== Response ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"id": "<profile identifier>",<br />
"name": "<player name>",<br />
"properties": [ <br />
{<br />
"name": "textures",<br />
"value": "<base64 string>",<br />
"signature": "<base64 string; signed data using Yggdrasil's private key>" // Only provided if ?unsigned=false is appended to url<br />
}<br />
]<br />
}<br />
</syntaxhighlight><br />
<br />
* <code>"legacy": true</code> will appear in the response if the user has not migrated their minecraft.net account to mojang.<br />
The "value" base64 string for the "textures" object decoded:<br />
<syntaxhighlight lang="json"><br />
{<br />
"timestamp": <java time in ms>,<br />
"profileId": "<profile uuid>",<br />
"profileName": "<player name>",<br />
"signatureRequired": true, // Only present if ?unsigned=false is appended to url<br />
"textures": {<br />
"SKIN": {<br />
"url": "<player skin URL>"<br />
},<br />
"CAPE": {<br />
"url": "<player cape URL>"<br />
}<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
* The timestamp is sometimes in the past (probably due to cached results?)<br />
* The <code>"SKIN"</code> object will have <code>"metadata": {"model": "slim"}</code> if the player model has slim arms (“Alex?” style). For square arms (“Steve?” style), <code>"metadata"</code> will be missing.<br />
* If no custom skin has been set, <code>"SKIN"</code> will be missing.<br>Whether the player has the “Alex?” or “Steve?” skin depends on [http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/java/util/UUID.java#l394 the Java hashCode] of their UUID. Steve is used for even hashes. Example implementations:<br />
** [https://github.com/mapcrafter/mapcrafter-playermarkers/blob/c583dd9157a041a3c9ec5c68244f73b8d01ac37a/playermarkers/player.php#L8-L19 PHP]<br />
** [https://github.com/LapisBlue/Lapitar/blob/55ede80ce4ebb5ecc2b968164afb40f61b4cc509/mc/uuid.go#L34-L36 Go]<br />
** [https://github.com/crafatar/crafatar/blob/9d2fe0c45424de3ebc8e0b10f9446e7d5c3738b2/lib/skins.js#L90-L108 JavaScript] (includes explanation)<br />
** [https://web.archive.org/web/20151022205119/https://gist.github.com/jomo/9968b8d572c38e1b1f4c Java] (includes sample UUIDs)<br />
* Likewise <code>"CAPE"</code> will be missing if the account has no cape.<br />
<br />
== Blocked Servers ==<br />
GET <nowiki>https://sessionserver.mojang.com/blockedservers</nowiki><br />
<br />
Returns a list of SHA1 hashes used to check server addresses against when the client tries to connect.<br />
<br />
Clients check the lowercase name, using the ISO-8859-1 charset, against this list. They will also attempt to check subdomains, replacing each level with a <code>*</code>. Specifically, it splits based off of the <code>.</code> in the domain, goes through each section removing one at a time. For instance, for <code>mc.example.com</code>, it would try <code>mc.example.com</code>, <code>*.example.com</code>, and <code>*.com</code>. With IP addresses (verified by having 4 split sections, with each section being a valid integer between 0 and 255, inclusive<!-- Decompiles seem to mess this up with an empty if, but there is logic for checking the range -->) substitution starts from the end, so for <code>192.168.0.1</code>, it would try <code>192.168.0.1</code>, <code>192.168.0.*</code>, <code>192.168.*</code>, and <code>192.*</code>.<br />
<br />
This check is done by the bootstrap class in netty. The default netty class is overridden by one in the com.mojang:netty dependency loaded by the launcher. This allows it to affect any version that used netty (1.7+)<br />
<br />
=== Response ===<br />
A line-separated list of all SHA1 hashes. Some of the current ~2200 hashes have been cracked.<br />
<br />
{| class="mw-collapsible mw-collapsed"<br />
|-<br />
! style="background: #f8f9fa; border: 1px solid #eaecf0; padding:0.2em 0.3em; text-align: left; font-weight: normal;" | <span style="padding-right: 0.5em;">Known cracked hashes</span><br />
|-<br />
| <pre style="margin-top: 0;"><br />
6f2520f8bd70a718c568ab5274c56bdbbfc14ef4:*.minetime.com<br />
7ea72de5f8e70a2ac45f1aa17d43f0ca3cddeedd:*.trollingbrandon.club<br />
c005ad34245a8f2105658da2d6d6e8545ef0f0de:*.skygod.us<br />
c645d6c6430db3069abd291ec13afebdb320714b:*.mineaqua.es<br />
8bf58811e6ebca16a01b842ff0c012db1171d7d6:*.eulablows.host<br />
8789800277882d1989d384e7941b6ad3dadab430:*.moredotsmoredots.xyz<br />
e40c3456fb05687b8eeb17213a47b263d566f179:*.brandonlovescock.bid<br />
278b24ffff7f9f46cf71212a4c0948d07fb3bc35:*.brandonlovescock.club<br />
c78697e385bfa58d6bd2a013f543cdfbdc297c4f:*.mineaqua.net<br />
b13009db1e2fbe05465716f67c8d58b9c0503520:*.endercraft.com<br />
3e560742576af9413fca72e70f75d7ddc9416020:*.insanefactions.org<br />
986204c70d368d50ffead9031e86f2b9e70bb6d0:*.playmc.mx<br />
65ca8860fa8141da805106c0389de9d7c17e39bf:*.howdoiblacklistsrv.host<br />
7dca807cc9484b1eed109c003831faf189b6c8bf:*.brandonlovescock.online<br />
c6a2203285fb0a475c1cd6ff72527209cc0ccc6e:*.brandonlovescock.press<br />
e3985eb936d66c9b07aa72c15358f92965b1194e:*.insanenetwork.org<br />
b140bec2347bfbe6dcae44aa876b9ba5fe66505b:*.phoenixnexus.net<br />
27ae74becc8cd701b19f25d347faa71084f69acd:*.arkhamnetwork.org<br />
48f04e89d20b15de115503f22fedfe2cb2d1ab12:brandonisan.unusualperson.com<br />
9f0f30820cebb01f6c81f0fdafefa0142660d688:*.kidslovemy500dollarranks.club<br />
cc90e7b39112a48064f430d3a08bbd78a226d670:*.eccgamers.com<br />
88f155cf583c930ffed0e3e69ebc3a186ea8cbb7:*.fucktheeula.com<br />
605e6296b8dba9f0e4b8e43269fe5d053b5f4f1b:*.mojangendorsesbrazzers.webcam<br />
5d2e23d164a43fbfc4e6093074567f39b504ab51:touchmybody.redirectme.net<br />
f3df314d1f816a8c2185cd7d4bcd73bbcffc4ed8:*.mojangsentamonkeyinto.space<br />
073ca448ef3d311218d7bd32d6307243ce22e7d0:*.diacraft.org<br />
33839f4006d6044a3a6675c593fada6a690bb64d:*.diacraft.de<br />
e2e12f3b7b85eab81c0ee5d2e9e188df583fe281:*.eulablacklist.club<br />
11a2c115510bfa6cb56bbd18a7259a4420498fd5:*.slaughterhousepvp.com<br />
75df09492c6c979e2db41116100093bb791b8433:*.timelesspvp.net<br />
d42339c120bc10a393a0b1d2c6a2e0ed4dbdd61b:*.herowars.org<br />
4a1b3b860ba0b441fa722bbcba97a614f6af9bb8:justgiveinandblockddnsbitches.ddns.net<br />
b8c876f599dcf5162911bba2d543ccbd23d18ae5:brandonisagainst.health-carereform.com<br />
9a9ae8e9d0b6f3bf54c266dcd1e4ec034e13f714:brandonwatchesporn.onthewifi.com<br />
336e718ffbc705e76b4a72884172c6b95216b57c:canyouwildcardipsplease.gotdns.ch<br />
27cf97ecf24c92f1fe5c84c5ff654728c3ee37dd:letsplaysome.servecounterstrike.com<br />
32066aa0c7dc9b097eed5b00c5629ad03f250a2d:mojangbrokeintomy.homesecuritymac.com<br />
39f4bbfd123a5a5ddbf97489877831c15a70d7f2:*.primemc.org<br />
f32f824d41aaed334aef248fbe3a0f8ecf4ac1a0:*.meep.in<br />
c22efe4cf7fb319ca2387bbc930c1fdf77ab72fc:*.itsjerryandharry.com<br />
cc8e1ae93571d144bf4b37369cb8466093d6db5a:*.thearchon.net<br />
9c0806e5ffaccb45121e57e4ce88c7bc76e057f1:*.goatpvp.com<br />
5ca81746337088b7617c851a1376e4f00d921d9e:*.gotpvp.com<br />
a5944b9707fdb2cc95ed4ef188cf5f3151ac0525:*.guildcraft.org<br />
e7210344ab0a2206da3bb21d03e406c0f1365981:*.redesky.com<br />
de2cbbda331606a68ec2f88827f06e24cc5d0a24:*.mushmc.com.br<br />
</pre><br />
|}<br />
<br />
A quite large list of known hashes is available at: https://github.com/Reecepbcups/FollowTheEULA/blob/master/blockedServersList.txt<br />
Some hashes on there might not be in the current hashes list anymore.<br />
<br />
== Statistics ==<br />
POST <nowiki>https://api.mojang.com/orders/statistics</nowiki><br />
<br />
Get statistics on the sales of Minecraft.<br />
<br />
=== Payload ===<br />
The payload is a JSON list of options under the metricKeys key.<br />
You will receive a single object corresponding to the sum of sales of the requested type(s).<br />
You must request at least one type of sale.<br />
Below is the default list used by https://minecraft.net/en/stats/<br />
<syntaxhighlight lang="json"><br />
{<br />
"metricKeys": [<br />
"item_sold_minecraft",<br />
"prepaid_card_redeemed_minecraft"<br />
]<br />
}<br />
</syntaxhighlight><br />
<br />
Valid options are:<br />
item_sold_minecraft<br />
prepaid_card_redeemed_minecraft<br />
item_sold_cobalt<br />
item_sold_scrolls<br />
prepaid_card_redeemed_cobalt<br />
item_sold_dungeons<br />
<br />
=== Headers ===<br />
Content-Type: application/json<br />
<br />
=== Response ===<br />
A JSON object is returned with the total amount of copies sold, the number of copies sold in the last 24 hours and how many sales there are per second.<br />
<syntaxhighlight lang="json"><br />
{<br />
"total": integer total amount sold,<br />
"last24h": integer total sold in last 24 hours,<br />
"saleVelocityPerSeconds": decimal average sales per second<br />
}<br />
</syntaxhighlight><br />
<br />
== Profile Information ==<br />
GET <nowiki>https://api.minecraftservices.com/minecraft/profile</nowiki><br />
<br />
This API endpoint fetches information about the current account including UUID, username, skins, and capes.<br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
<br />
=== Response ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"id": "<profile UUID>",<br />
"name": "<profile name>",<br />
"skins": [<br />
{<br />
"id": "8c94945e-d0b4-4df8-97d1-d8d397624f93",<br />
"state": "ACTIVE",<br />
"url": "<URL to the skin image>",<br />
"variant": "CLASSIC" // Either SLIM or CLASSIC<br />
}<br />
],<br />
"capes": []<br />
}<br />
</syntaxhighlight><br />
<br />
== Profile Name Change Information ==<br />
GET <nowiki>https://api.minecraftservices.com/minecraft/profile/namechange</nowiki><br />
<br />
This API endpoint fetches information about the profile name such as the date the name was changed and the date the account was created.<br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
<br />
=== Response ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"changedAt": "2019-12-17T03:19:31Z",<br />
"createdAt": "2015-11-13T01:59:46Z",<br />
"nameChangeAllowed": true<br />
}<br />
</syntaxhighlight><br />
<br />
== Check Product Voucher ==<br />
GET <nowiki>https://api.minecraftservices.com/productvoucher/giftcode</nowiki><br />
<br />
This API endpoint checks if the gift card is valid.<br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
<br />
=== Error Response ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"path": "/productvoucher/giftcode",<br />
"errorType": "NOT_FOUND",<br />
"error": "NOT_FOUND",<br />
"errorMessage": "The server has not found anything matching the request URI",<br />
"developerMessage": "The server has not found anything matching the request URI"<br />
}<br />
</syntaxhighlight><br />
<br />
{| class="wikitable"<br />
|'''Status Codes'''<br />
|'''Responses'''<br />
|-<br />
|404<br />
|Product Voucher is invalid. (Either claimed or not activated)<br />
|-<br />
|200/204<br />
|Success (Product voucher is valid)<br />
|}<br />
<br />
== Name Availability ==<br />
GET <nowiki>https://api.minecraftservices.com/minecraft/profile/name/</nowiki>'''<name>'''/available<br />
<br />
This API endpoint checks if the given name is available.<br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
<br />
=== Response ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"status": "DUPLICATE" // Either DUPLICATE or AVAILABLE<br />
}<br />
</syntaxhighlight><br />
<br />
== Change Name ==<br />
PUT <nowiki>https://api.minecraftservices.com/minecraft/profile/name/</nowiki>'''<name>'''<br />
<br />
This will set the name for the account that the access token in the Authorization header belongs to.<br />
<br />
=== Payload ===<br />
No payload needed.<br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
<br />
=== Success Response ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"id" : "31e0ccbef5fa4eb988592f30516f65fe",<br />
"name" : "newname34234", // newly acquired name<br />
"skins" : [<br />
{<br />
"id" : "c97f6fea-6ca8-4bf0-bdae-b7cf91fb089c", //uuid of account<br />
"state" : "ACTIVE",<br />
"url" : "<nowiki>http://textures.minecraft.net/texture/3b60a1f6d562f52aaebbf1434f1de147933a3affe0e764fa49ea057536623cd3</nowiki>", //skin URL<br />
"variant" : "SLIM"<br />
}<br />
],<br />
"capes" : []<br />
}<br />
</syntaxhighlight><br />
<br />
=== Error Response ===<br />
Upon error, the server will send back a JSON with the error.<br />
<br />
<syntaxhighlight lang="json"><br />
{<br />
"path": "/minecraft/profile/name/<name>",<br />
"errorType": "FORBIDDEN", // Optional, type of error<br />
"error": "FORBIDDEN", // Optional, name of the error<br />
"details": { // Optional, details about the name<br />
"status": "DUPLICATE"<br />
},<br />
"errorMessage": "Optional error message",<br />
"developerMessage": "Optional error message, same as errorMessage"<br />
}<br />
</syntaxhighlight><br />
<br />
{| class="wikitable"<br />
|'''Status Codes'''<br />
|'''Responses'''<br />
|-<br />
|400<br />
|Name is invalid, longer than 16 characters or contains characters other than (a-zA-Z0-9_)<br />
|-<br />
|403<br />
|Name is unavailable (Either taken or has not become available)<br />
|-<br />
|401<br />
|Unauthorized (Bearer token expired or is not correct)<br />
|-<br />
|429<br />
|Too many requests sent<br />
|-<br />
|500<br />
|Timed out (API lagged out and could not respond)<br />
|-<br />
|200<br />
|Success (Name changed)<br />
|}<br />
<br />
== Change Skin ==<br />
POST <nowiki>https://api.minecraftservices.com/minecraft/profile/skins</nowiki><br />
<br />
This will set the skin for the selected profile, but Mojang's servers will fetch the skin from a URL. <br />
<br />
=== Payload ===<br />
The payload for this API consists of a JSON object containing the URL and variant<br />
<br />
<syntaxhighlight lang="json"><br />
{<br />
"variant": "classic",<br />
"url": "http://assets.mojang.com/SkinTemplates/steve.png"<br />
}<br />
</syntaxhighlight><br />
<br />
variant is either "classic" or "slim"<br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
Content-Type: application/json<br />
<br />
=== Response ===<br />
Upon error, the server will send back a JSON with the error. (Success is a blank payload)<br />
<br />
=== Example ===<br />
curl -H "Authorization: Bearer '''<access token>'''" -H "Content-Type: application/json; charset=utf-8" --request POST --data '{"variant": "classic", "url": "http://assets.mojang.com/SkinTemplates/steve.png"}' <nowiki>https://api.minecraftservices.com/minecraft/profile/skins</nowiki><br />
<br />
== Upload Skin ==<br />
POST <nowiki>https://api.minecraftservices.com/minecraft/profile/skins</nowiki><br />
<br />
This uploads a skin to Mojang's servers. It also sets the user's skin. This works on legacy accounts as well.<br />
<br />
=== Payload ===<br />
The payload for this API consists of multipart form data. There are two parts (order does not matter b/c of boundary):<br />
{| class="wikitable"<br />
|'''variant'''<br />
|Either "classic" for normal models or "slim" for slim models.<br />
|-<br />
|'''file'''<br />
|Raw image file data<br />
|}<br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
<br />
=== Response ===<br />
No response unless an error occurred.<br />
<br />
=== Example ===<br />
curl -X POST -H "Authorization: Bearer '''<access token>'''" -F variant=classic -F file="@steeevee.png;type=image/png" <nowiki>https://api.minecraftservices.com/minecraft/profile/skins</nowiki><br />
<br />
<syntaxhighlight lang="http"><br />
PUT /minecraft/profile/skins HTTP/1.1<br />
Host: api.minecraftservices.com<br />
User-Agent: curl/7.49.0<br />
Accept: */*<br />
Authorization: Bearer '''<access token>'''<br />
Content-Length: '''<length>'''<br />
Content-Type: multipart/form-data; boundary='''<boundary>'''<br />
<br />
--'''<boundary>'''<br />
Content-Disposition: form-data; name="variant"<br />
<br />
classic<br />
--'''<boundary>'''<br />
Content-Disposition: form-data; name="file"; filename="alex.png"<br />
Content-Type: image/png<br />
<br />
'''<image data>'''<br />
--'''<boundary>'''--<br />
</syntaxhighlight><br />
<br />
== Reset Skin ==<br />
DELETE <nowiki>https://api.mojang.com/user/profile/</nowiki>'''<uuid>'''/skin<br />
<br />
Resets the user's skin to the default one.<br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
<br />
=== Response ===<br />
No response unless an error occurred.<br />
<br />
=== Example ===<br />
curl -X DELETE -H "Authorization: Bearer '''<access token>'''" <nowiki>https://api.mojang.com/user/profile/</nowiki>'''<uuid>'''/skin<br />
<br />
<syntaxhighlight lang="http"><br />
DELETE /user/profile/'''<uuid>'''/skin HTTP/1.1<br />
Host: api.mojang.com<br />
User-Agent: curl/7.46.0<br />
Accept: */*<br />
Authorization: Bearer '''<access token>'''<br />
</syntaxhighlight><br />
<br />
== Hide Cape ==<br />
DELETE <nowiki>https://api.minecraftservices.com/minecraft/profile/capes/active</nowiki><br />
<br />
Prevents the current cape from being shown on the account.<br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
<br />
=== Response ===<br />
There is no response body.<br />
<br />
{| class="wikitable"<br />
|'''Status Codes'''<br />
|'''Responses'''<br />
|-<br />
|401<br />
|Unauthorized (Bearer token expired or is not correct)<br />
|-<br />
|200<br />
|Success (Cape has been hidden)<br />
|}<br />
<br />
== Show Cape ==<br />
PUT <nowiki>https://api.minecraftservices.com/minecraft/profile/capes/active</nowiki><br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
Content-Type: application/json<br />
<br />
=== Success Response ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"id": "<profile UUID>",<br />
"name": "<profile name>",<br />
"skins": [<br />
{<br />
"id": "8c94945e-d0b4-4df8-97d1-d8d397624f93",<br />
"state": "ACTIVE",<br />
"url": "<URL to the skin image>",<br />
"variant": "CLASSIC" // Either SLIM or CLASSIC<br />
}<br />
],<br />
"capes": [<br />
{<br />
"id": "capeid",<br />
"state": "ACTIVE",<br />
"url": "<URL to the cape image>",<br />
"alias": "Cape Name"<br />
} <br />
]<br />
}<br />
</syntaxhighlight><br />
<br />
=== Error Response ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"path": "/minecraft/profile/capes/active",<br />
"errorMessage": "profile does not own cape",<br />
"developerMessage": "profile does not own cape"<br />
}<br />
</syntaxhighlight><br />
<br />
=== Payload ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"capeId": "Id"<br />
}<br />
</syntaxhighlight><br />
<br />
{| class="wikitable"<br />
|'''Status Codes'''<br />
|'''Responses'''<br />
|-<br />
|200<br />
|Success<br />
|-<br />
|400<br />
|Bad Request (Profile doesn't own cape)<br />
|-<br />
|401<br />
|Unauthorized (Bearer token expired or is not correct)<br />
|}<br />
<br />
== Verify Security Location ==<br />
GET <nowiki>https://api.mojang.com/user/security/location</nowiki><br />
<br />
Verify's that the current IP is trusted by the server for the account and the token can be used.<br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
<br />
=== Success Response ===<br />
204 NO CONTENT<br />
<br />
=== Error Response ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"error": "ForbiddenOperationException",<br />
"errorMessage": "Current IP is not secured"<br />
}<br />
</syntaxhighlight><br />
<br />
== Get Security Questions ==<br />
GET <nowiki>https://api.mojang.com/user/security/challenges</nowiki><br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
<br />
=== Response ===<br />
<syntaxhighlight lang="json"><br />
[<br />
{<br />
"answer": {<br />
"id": 123<br />
},<br />
"question": {<br />
"id": 1,<br />
"question": "What is your favorite pet's name?"<br />
}<br />
},<br />
{<br />
"answer": {<br />
"id": 456<br />
},<br />
"question": {<br />
"id": 2,<br />
"question": "What is your favorite movie?"<br />
}<br />
},<br />
{<br />
"answer": {<br />
"id": 789<br />
},<br />
"question": {<br />
"id": 3,<br />
"question": "What is your favorite author's last name?"<br />
}<br />
}<br />
],<br />
</syntaxhighlight><br />
<br />
{| class="mw-collapsible mw-collapsed" style="margin-top: 0.5em;"<br />
|-<br />
! style="background: #f8f9fa; border: 1px solid #eaecf0; padding:0.2em 0.3em; text-align: left; font-weight: normal;" | <span style="padding-right: 0.5em;">Possible questions IDs</span><br />
|-<br />
| <pre style="margin-top: 0;"><br />
1 What is your favorite pet's name?<br />
2 What is your favorite movie?<br />
3 What is your favorite author's last name?<br />
4 What is your favorite artist's last name?<br />
5 What is your favorite actor's last name?<br />
6 What is your favorite activity?<br />
7 What is your favorite restaurant?<br />
8 What is the name of your favorite cartoon?<br />
9 What is the name of the first school you attended?<br />
10 What is the last name of your favorite teacher?<br />
11 What is your best friend's first name?<br />
12 What is your favorite cousin's name?<br />
13 What was the first name of your first girl/boyfriend?<br />
14 What was the name of your first stuffed animal?<br />
15 What is your mother's middle name?<br />
16 What is your father's middle name?<br />
17 What is your oldest sibling's middle name?<br />
18 In what city did your parents meet?<br />
19 In what hospital were you born?<br />
20 What is your favorite team?<br />
21 How old were you when you got your first computer?<br />
22 How old were you when you got your first gaming console?<br />
23 What was your first video game?<br />
24 What is your favorite card game?<br />
25 What is your favorite board game?<br />
26 What was your first gaming console?<br />
27 What was the first book you ever read?<br />
28 Where did you go on your first holiday?<br />
29 In what city does your grandmother live?<br />
30 In what city does your grandfather live?<br />
31 What is your grandmother's first name?<br />
32 What is your grandfather's first name?<br />
33 What is your least favorite food?<br />
34 What is your favorite ice cream flavor?<br />
35 What is your favorite ice cream flavor?<br />
36 What is your favorite place to visit?<br />
37 What is your dream job?<br />
38 What color was your first pet?<br />
39 What is your lucky number?<br />
</pre><br />
|}<br />
<br />
== Send Security Answers ==<br />
POST <nowiki>https://api.mojang.com/user/security/location</nowiki><br />
<br />
=== Payload ===<br />
<syntaxhighlight lang="json"><br />
[<br />
{<br />
"id": 123,<br />
"answer" : "foo"<br />
},<br />
{<br />
"id": 456,<br />
"answer" : "bar"<br />
},<br />
{<br />
"id": 589,<br />
"answer" : "baz"<br />
}<br />
]<br />
</syntaxhighlight><br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
Content-Type: application/json<br />
<br />
=== Success Response ===<br />
204 NO CONTENT<br />
<br />
=== Error Response ===<br />
On failure, you will get some sort of error. Unless it's a syntax or json structure error, it will be this:<br />
<br />
<syntaxhighlight lang="json"><br />
{<br />
"error": "ForbiddenOperationException",<br />
"errorMessage": "At least one answer was incorrect"<br />
}<br />
</syntaxhighlight><br />
<br />
== Get Account Migration Information ==<br />
GET <nowiki>https://api.minecraftservices.com/rollout/v1/msamigration</nowiki><br />
<br />
This API endpoint fetches information about the current account's ability to migrate.<br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
<br />
=== Response ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"feature": "msamigration",<br />
"rollout": true<br />
}<br />
</syntaxhighlight><br />
<br />
== Account Migration OTP ==<br />
POST <nowiki>https://api.minecraftservices.com/twofactorauth/migration/otp</nowiki><br />
<br />
This API endpoint returns an OTP Id used for transferring the current account later.<br />
<br />
=== Payload ===<br />
No payload needed.<br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
Content-Type: application/json<br />
<br />
=== Success Response ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"otpId" : "cb694fff-220a-4213-a12e-e54e49fd7dd4"<br />
}<br />
</syntaxhighlight><br />
<br />
{| class="wikitable"<br />
|'''Status Codes'''<br />
|'''Responses'''<br />
|-<br />
|201<br />
|Success (OTP has been received successfully)<br />
|-<br />
|401<br />
|Unauthorized (Bearer token expired or is not correct)<br />
|}<br />
<br />
== Verify Account Migration OTP ==<br />
POST <nowiki>https://api.minecraftservices.com/twofactorauth/migration/otp/<otpId>/verify</nowiki><br />
<br />
Verifies the code sent to an account's email after a POST request to /otp.<br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
Content-Type: application/json<br />
<br />
=== Payload ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"otp": "code"<br />
}<br />
</syntaxhighlight><br />
<br />
{| class="wikitable"<br />
|'''Status Codes'''<br />
|'''Responses'''<br />
|-<br />
|204<br />
|Success<br />
|-<br />
|401<br />
|Unauthorized (Bearer token expired or is not correct)<br />
|}<br />
<br />
=== Response ===<br />
There is no response body.<br />
<br />
<br />
== Submit Migration Token ==<br />
POST <nowiki>https://api.minecraftservices.com/migration/token</nowiki><br />
<br />
Used to submit the current account's email upon migrating.<br />
<br />
=== Headers ===<br />
Authorization: Bearer '''<access token>'''<br />
Content-Type: application/json<br />
<br />
=== Payload ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"sessionEmail": "accountemail"<br />
}<br />
</syntaxhighlight><br />
<br />
{| class="wikitable"<br />
|'''Status Codes'''<br />
|'''Responses'''<br />
|-<br />
|200<br />
|Success<br />
|-<br />
|401<br />
|Unauthorized (Bearer token expired or is not correct)<br />
|}<br />
<br />
=== Response ===<br />
There is no response body.<br />
<br />
== Connect Xbox Live ==<br />
POST <nowiki>https://sisu.xboxlive.com/connect/XboxLive</nowiki><br />
<br />
Connects the Mojang account to Xbox live.<br />
<br />
=== Headers ===<br />
Content-Type: application/json<br />
<br />
=== Payload ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"AppId": "1142970254",<br />
"Callback": "https://www.minecraft.net/en-us/link-accounts",<br />
"CobrandId": "fb937bf5-b9a1-4b61-b744-82f9a1adc248",<br />
"ProfileName": "accountname",<br />
"State": "postUpsell",<br />
"TitleId": "896928775",<br />
"UseModernGamertag": true<br />
}<br />
</syntaxhighlight><br />
<br />
{| class="wikitable"<br />
|'''Status Codes'''<br />
|'''Responses'''<br />
|-<br />
|200<br />
|Success<br />
|-<br />
|401<br />
|Unauthorized<br />
|}<br />
<br />
=== Success Response ===<br />
<syntaxhighlight lang="json"><br />
{<br />
"RedirectTo" : "authflowloginurl"<br />
}<br />
</syntaxhighlight><br />
<br />
== Examples ==<br />
* [https://github.com/hawezo/MojangSharp C#] - Full API wrapper<br />
* [https://github.com/CmlLib/MojangAPI C#] - Full API wrapper with Mojang/Microsoft Authentication<br />
* [https://github.com/spnda/dart_minecraft Dart] - Almost full API wrapper with Mojang Authentication<br />
* [https://github.com/Lukaesebrot/mojango Go] - Full API wrapper<br />
* [https://github.com/PhilipBorgesen/minecraft/tree/master/profile Go] - UUIDs or names to profiles with skins, capes and name histories<br />
* [https://github.com/summer/mojang Python] - Full API Wrapper. Also supports authentication & parts of the Minecraft website<br />
* [https://github.com/Lucino772/pymojang Python] - Pymojang is a full wrapper around de Mojang API and Mojang Authentication API. Also support RCON, Query and Server List Ping<br />
* [https://github.com/SynchronousX/mojang-api Python] - Full API wrapper (not updated since 2018)<br />
* [https://github.com/techkid6/AccountsClientPython Python] - UUIDs or names to profiles (not updated since 2018)<br />
* [https://github.com/elyby/mojang-api PHP] - Complete Mojang's API wrapper<br />
* [https://github.com/MineTheCube/MojangAPI PHP] - UUIDs or names to profiles with skins, heads and name histories<br />
* [https://gist.github.com/ezfe/a71feccd3a837a2592f1 PHP] - UUIDs to names<br />
* [https://github.com/ozzyfant/AccountsClientPHP PHP] - UUIDs to names, names to uuids<br />
* [https://github.com/SparklingComet/java-mojang-api Java] - Almost full API Wrapper<br />
* [https://github.com/dpkgsoft/mojang Java] - Almost full API Wrapper with auth<br />
* [https://github.com/novastosha/NMoyang Java] - Almost full API with Mojang Authentication and can also work as a console Application.<br />
* [https://github.com/thechunknetwork/mojang-api JavaScript] - UUIDs or names to profiles with skins, capes and name histories<br />
<br />
[[Category:Protocol Details]]<br />
[[Category:Minecraft Modern]]</div>Janmm14https://wiki.vg/index.php?title=User_talk:TkTech&diff=16098User talk:TkTech2020-10-30T12:27:56Z<p>Janmm14: /* Request for adding a custom css rule */ new section</p>
<hr />
<div>Might I ask why my changed were reverted? Other pages such as servers had inactive projects pruned.<br />
: Come talk to us in #mcdevs, we're discussing it. [[User:TkTech|TkTech (tk@tkte.ch)]] ([[User talk:TkTech|talk]]) 02:56, 4 January 2013 (MST)<br />
<br />
==A couple of things regarding the wiki==<br />
Hi, I have registered today and noticed a few things:<br />
<br />
* I could not initially confirm my email because confirmation emails are sent from the domain <code>mg.wiki.vg</code> which does not currently exist. This is the error message I was having on my mail server:<br />
<pre><br />
May 27 01:35:35 m sm-mta[56110]: w4R1ZX0j056110: ruleset=check_mail,<br />
arg1=<bounce+8f0953.dedbf-minecraftdev=6speed.de@mg.wiki.vg>,<br />
relay=mail-s77.mailgun.info [184.173.153.205],<br />
reject=553 5.1.8 <bounce+8f0953.dedbf-minecraftdev=6speed.de@mg.wiki.vg>... Domain of sender address bounce+8f0953.dedbf-minecraftdev=6speed.de@mg.wiki.vg does not exist<br />
</pre> <br />
I have worked around this by disabling domain checks temporarily, but that works only for myself.<br />
* Something is broken with the [[:mw:Manual:Short URL|Short URL configuration]]:<br />
** http://wiki.vg/Special:AllPages?namespace=2 ignores the "namespace=2" parameter - the result should be the same as for http://wiki.vg/index.php?title=Special:AllPages&from=&to=&namespace=2 <br />
**:To reproduce, go to [[Special:AllPages]] and try to switch to "User" from "(main)"<br />
* Some spam is around - I have added a template <nowiki>{{</nowiki>[[Template:Delete|Delete]]<nowiki>}}</nowiki> and marked some pages to [[:Category:Pages to be deleted]].<br />
* Unfortunately most of the [http://wiki.vg/index.php?title=Special:AllPages&from=&to=&namespace=2 userpages] and the [http://wiki.vg/index.php?title=Special:AllPages&from=&to=&namespace=3 corresponding user talk pages] are spam - almost all(?) could be removed and the users blocked.<br />
<br />
Thanks for running this wiki - the technical value of what is posted here is excellent! &nbsp;«&nbsp;[[User:Saper|Saper]]<span style="font-size: 70%">&nbsp;//&nbsp;</span>[[User talk:Saper|@talk]]&nbsp;»&nbsp; 02:21, 27 May 2018 (UTC)<br />
<br />
== Request for adding a custom css rule ==<br />
<br />
I want to improve the page https://wiki.vg/Protocol_version_numbers in a way that the table is showing only release versions by default and has an expand button that will expand the table to show all the snapshot and release candidates.<br />
<br />
Basically I make the entire table collapsible and the custom css rule forces the lines of releases to still show.<br />
<br />
For that I want to edit the template https://wiki.vg/Protocol_version_numbers/Entry that it adds a class to the releases,<br />
first line of that file needs to be updated to<br />
<pre><nowiki><includeonly> |- {{#if: {{{snap|}}} | | class="nocollapse"}}</nowiki></pre><br />
<br />
and the table definition can be edited from<br />
<br />
<pre><nowiki>{| class="wikitable"</nowiki></pre><br />
<br />
to<br />
<br />
<pre><nowiki>{| class="mw-collapsible mw-collapsed wikitable"</nowiki></pre><br />
<br />
I tested this with custom stylesheet in preview already and it worked great, so if you add this custom css to the page, we can improve that too-long-page to be shorter by default:<br />
<pre><nowiki>.nocollapse { display: table-row !important}</nowiki></pre><br />
<br />
This cannot be added as style in-page as the javascript for collapsing does replace it and it is not possible to define css styles in page source code.<br />
--[[User:Janmm14|Janmm14]] ([[User talk:Janmm14|talk]]) 12:27, 30 October 2020 (UTC)</div>Janmm14https://wiki.vg/index.php?title=Protocol_version_numbers&diff=16097Protocol version numbers2020-10-29T20:34:56Z<p>Janmm14: Add links to other 1.8.8 content similar to how its done for 1.12.2</p>
<hr />
<div>This page lists the protocol version numbers used in the various MC releases. Official releases are marked bold, weekly snapshots are in regular font.<br />
<br />
The 1.7 release has seen a complete rewrite of the network protocol (using Netty), including the version numbers. The protocol numbers have been reset. This page contains version numbers for both the pre-Netty and post-Netty protocol versions.<br />
<br />
A list of packet IDs and names per linked protocol version on this page is available [https://gitlab.bixilon.de/bixilon/minosoft/-/blob/developement/src/main/resources/assets/mapping/versions.json here]. The json is minified and allowes inheritance. A documentation about this file is [https://gitlab.bixilon.de/bixilon/minosoft/-/blob/developement/doc/MinecraftVersions.md here]<br />
<br />
== Versions after the Netty rewrite ==<br />
<br />
Beginning with the 1.7.1 pre-release (and release 1.7.2), versioning was reset. <!-- For copy-paste convenience: {{subst:REVISIONID: Pre-release protocol}} --><br />
<br />
{| class="wikitable"<br />
|-<br />
! Release name<br />
! Version number<br />
! Last known documentation<br />
{{/Entry|1.16.4-rc1|1073741827|cur|snap=1}}<br />
{{/Entry|1.16.4-pre2|1073741826|16088|snap=1}}<br />
{{/Entry|1.16.4-pre1|1073741825|16071|snap=1}}<br />
{{/Entry|1.16.3|753|cur}}<br />
{{/Entry|1.16.3-rc1|752|16029|snap=1}}<br />
{{/Entry|1.16.2|751|16001|pre_release_doc=1}}<br />
{{/Entry|1.16.2-rc2|750|15972|snap=1}}<br />
{{/Entry|1.16.2-rc1|749|15967|snap=1}}<br />
{{/Entry|1.16.2-pre3|748|15962|snap=1}}<br />
{{/Entry|1.16.2-pre2|746|15958|snap=1}}<br />
{{/Entry|1.16.2-pre1|744|15956|snap=1}}<br />
{{/Entry|20w30a|743|15952|snap=1}}<br />
{{/Entry|20w29a|741|15931|snap=1}}<br />
{{/Entry|20w28a|740|15924|snap=1}}<br />
{{/Entry|20w27a|738|15902|snap=1}}<br />
{{/Entry|1.16.1|736|15895|pre_release_doc=1}}<br />
{{/Entry|1.16|735|15878|pre_release_doc=1}}<br />
{{/Entry|1.16-rc1|734|15872|snap=1}}<br />
{{/Entry|1.16-pre8|733|15861|snap=1}}<br />
{{/Entry|1.16-pre7|732|15857|snap=1}}<br />
{{/Entry|1.16-pre6|730|15854|snap=1}}<br />
{{/Entry|1.16-pre5|729|15847|snap=1}}<br />
{{/Entry|1.16-pre4|727|15843|snap=1}}<br />
{{/Entry|1.16-pre3|725|15839|snap=1}}<br />
{{/Entry|1.16-pre2|722|15832|snap=1}}<br />
{{/Entry|1.16-pre1|721|15831|snap=1}}<br />
{{/Entry|20w22a|719|15710|snap=1}}<br />
{{/Entry|20w21a|718|15661|snap=1}}<br />
{{/Entry|20w20b|717|15646|snap=1}}<br />
{{/Entry|20w20a|716|15643|snap=1}}<br />
{{/Entry|20w19a|715|15588|snap=1}}<br />
{{/Entry|20w18a|714|15577|snap=1}}<br />
{{/Entry|20w17a|713|15551|snap=1}}<br />
{{/Entry|20w16a|712|15536|snap=1}}<br />
{{/Entry|20w15a|711|15514|snap=1}}<br />
{{/Entry|20w14a|710|15452|snap=1}}<br />
|-<br />
| {{Minecraft Wiki|20w14∞}} || 709 || <ref group="note">April fools snapshot.</ref><br />
{{/Entry|20w13b|709|15392|snap=1}}<br />
{{/Entry|20w13a|708|15382|snap=1}}<br />
{{/Entry|20w12a|707|15368|snap=1}}<br />
{{/Entry|20w11a|706|15336|snap=1}}<br />
{{/Entry|20w10a|705|15326|snap=1}}<br />
{{/Entry|20w09a|704|15310|snap=1}}<br />
{{/Entry|20w08a|703|15306|snap=1}}<br />
{{/Entry|20w07a|702|15304|snap=1}}<br />
{{/Entry|20w06a|701|15295|snap=1}}<br />
{{/Entry|1.15.2|578|16067}}<br />
{{/Entry|1.15.2-pre2|577|15258|snap=1}}<br />
{{/Entry|1.15.2-pre1|576|15256|snap=1}}<br />
{{/Entry|1.15.1|575|15241|pre_release_doc=1}}<br />
{{/Entry|1.15.1-pre1|574|15183|snap=1}}<br />
{{/Entry|1.15|573|15173|pre_release_doc=1}}<br />
{{/Entry|1.15-pre7|572|15164|snap=1}}<br />
{{/Entry|1.15-pre6|571|15158|snap=1}}<br />
{{/Entry|1.15-pre5|570|15149|snap=1}}<br />
{{/Entry|1.15-pre4|569|15140|snap=1}}<br />
{{/Entry|1.15-pre3|567|15122|snap=1}}<br />
{{/Entry|1.15-pre2|566|15111|snap=1}}<br />
{{/Entry|1.15-pre1|565|15101|snap=1}}<br />
{{/Entry|19w46b|564|15073|snap=1}}<br />
{{/Entry|19w46a|563|15070|snap=1}}<br />
{{/Entry|19w45b|562|15056|snap=1}}<br />
{{/Entry|19w45a|561|15054|snap=1}}<br />
{{/Entry|19w44a|560|15050|snap=1}}<br />
{{/Entry|19w42a|559|15044|snap=1}}<br />
{{/Entry|19w41a|558|15032|snap=1}}<br />
{{/Entry|19w40a|557|15013|snap=1}}<br />
{{/Entry|19w39a|556|14987|snap=1}}<br />
{{/Entry|19w38b|555|14971|snap=1}}<br />
{{/Entry|19w38a|554|snap=1}}<br />
{{/Entry|19w37a|553|snap=1}}<br />
{{/Entry|19w36a|552|14970|snap=1}}<br />
{{/Entry|19w35a|551|14969|snap=1}}<br />
{{/Entry|19w34a|550|14968|snap=1}}<br />
{{/Entry|1.14.4|498|15346}}<br />
{{/Entry|1.14.4-pre7|497|14868|snap=1}}<br />
{{/Entry|1.14.4-pre6|496|14864|snap=1}}<br />
{{/Entry|1.14.4-pre5|495|14862|snap=1}}<br />
{{/Entry|1.14.4-pre4|494|14856|snap=1}}<br />
{{/Entry|1.14.4-pre3|493|14849|snap=1}}<br />
{{/Entry|1.14.4-pre2|492|14837|snap=1}}<br />
{{/Entry|1.14.4-pre1|491|14835|snap=1}}<br />
{{/Entry|1.14.3|490|14826|pre_release_doc=1}}<br />
{{/Entry|1.14.3 - Combat Test|500|snap=1}}<br />
{{/Entry|1.14.3-pre4|489|14824|snap=1}}<br />
{{/Entry|1.14.3-pre3|488|14820|snap=1}}<br />
{{/Entry|1.14.3-pre2|487|14816|snap=1}}<br />
{{/Entry|1.14.3-pre1|486|14806|snap=1}}<br />
{{/Entry|1.14.2|485|14794|pre_release_doc=1}}<br />
{{/Entry|1.14.2-pre4|484|14788|snap=1}}<br />
{{/Entry|1.14.2-pre3|483|14785|snap=1}}<br />
{{/Entry|1.14.2-pre2|482|14779|snap=1}}<br />
{{/Entry|1.14.2-pre1|481|14772|snap=1}}<br />
{{/Entry|1.14.1|480|14770|pre_release_doc=1}}<br />
{{/Entry|1.14.1-pre2|479|14762|snap=1}}<br />
{{/Entry|1.14.1-pre1|478|14757|snap=1}}<br />
{{/Entry|1.14|477|14752|pre_release_doc=1}}<br />
{{/Entry|1.14-pre5|476|14697|snap=1}}<br />
{{/Entry|1.14-pre4|475|14695|snap=1}}<br />
{{/Entry|1.14-pre3|474|14691|snap=1}}<br />
{{/Entry|1.14-pre2|473|14687|snap=1}}<br />
{{/Entry|1.14-pre1|472|14683|snap=1}}<br />
{{/Entry|19w14b|471|14670|snap=1}}<br />
{{/Entry|19w14a|470|14649|snap=1}}<br />
{{/Entry|19w13b|469|14642|snap=1}}<br />
{{/Entry|19w13a|468|14639|snap=1}}<br />
{{/Entry|19w12b|467|14627|snap=1}}<br />
{{/Entry|19w12a|466|14625|snap=1}}<br />
{{/Entry|19w11b|465|14613|snap=1}}<br />
{{/Entry|19w11a|464|14607|snap=1}}<br />
{{/Entry|19w09a|463|14591|snap=1}}<br />
{{/Entry|19w08b|462|14586|snap=1}}<br />
{{/Entry|19w08a|461|14585|snap=1}}<br />
{{/Entry|19w07a|460|14575|snap=1}}<br />
{{/Entry|19w06a|459|14562|snap=1}}<br />
{{/Entry|19w05a|458|14555|snap=1}}<br />
{{/Entry|19w04b|457|14550|snap=1}}<br />
{{/Entry|19w04a|456|14548|snap=1}}<br />
{{/Entry|19w03c|455|14544|snap=1}}<br />
{{/Entry|19w03b|454|14536|snap=1}}<br />
{{/Entry|19w03a|453|14530|snap=1}}<br />
{{/Entry|19w02a|452|14515|snap=1}}<br />
{{/Entry|18w50a|451|14491|snap=1}}<br />
{{/Entry|18w49a|450|14467|snap=1}}<br />
{{/Entry|18w48b|449|14461|snap=1}}<br />
{{/Entry|18w48a|448|14459|snap=1}}<br />
{{/Entry|18w47b|447|14452|snap=1}}<br />
{{/Entry|18w47a|446|14449|snap=1}}<br />
{{/Entry|18w46a|445|14441|snap=1}}<br />
{{/Entry|18w45a|444|14418|snap=1}}<br />
{{/Entry|18w44a|443|14414|snap=1}}<br />
{{/Entry|18w43c|442|14397|snap=1}}<br />
{{/Entry|18w43b|441|14381|snap=1}}<br />
{{/Entry|18w43a|441|snap=1}}<br />
{{/Entry|1.13.2|404|14889}} ([{{canonicalurl:Plugin channels|oldid=14658}} Plugin channels])<br />
{{/Entry|1.13.2-pre2|403|14359|snap=1}}<br />
{{/Entry|1.13.2-pre1|402|14357|snap=1}}<br />
{{/Entry|1.13.1|401|14301}}<br />
{{/Entry|1.13.1-pre2|400|14261|snap=1}}<br />
{{/Entry|1.13.1-pre1|399|14255|snap=1}}<br />
{{/Entry|18w33a|398|14252|snap=1}}<br />
{{/Entry|18w32a|397|14247|snap=1}}<br />
{{/Entry|18w31a|396|14196|snap=1}}<br />
{{/Entry|18w30b|395|14189|snap=1}}<br />
{{/Entry|18w30a|394|14158|snap=1}}<br />
{{/Entry|1.13|393|14150|pre_release_doc=1}}<br />
{{/Entry|1.13-pre10|392|14126|snap=1}}<br />
{{/Entry|1.13-pre9|391|14124|snap=1}}<br />
{{/Entry|1.13-pre8|390|14117|snap=1}}<br />
{{/Entry|1.13-pre7|389|14107|snap=1}}<br />
{{/Entry|1.13-pre6|388|14095|snap=1}}<br />
{{/Entry|1.13-pre5|387|14088|snap=1}}<br />
{{/Entry|1.13-pre4|386|14072|snap=1}}<br />
{{/Entry|1.13-pre3|385|14045|snap=1}}<br />
{{/Entry|1.13-pre2|384|14030|snap=1}}<br />
{{/Entry|1.13-pre1|383|13984|snap=1}}<br />
{{/Entry|18w22c|382|13965|snap=1}}<br />
{{/Entry|18w22b|381|13951|snap=1}}<br />
{{/Entry|18w22a|380|13947|snap=1}}<br />
{{/Entry|18w21b|379|13932|snap=1}}<br />
{{/Entry|18w21a|378|13926|snap=1}}<br />
{{/Entry|18w20c|377|13923|snap=1}}<br />
{{/Entry|18w20b|376|13913|snap=1}}<br />
{{/Entry|18w20a|375|13910|snap=1}}<br />
{{/Entry|18w19b|374|13905|snap=1}}<br />
{{/Entry|18w19a|373|13896|snap=1}}<br />
{{/Entry|18w16a|372|13891|snap=1}}<br />
{{/Entry|18w15a|371|13824|snap=1}}<br />
{{/Entry|18w14b|370|13744|snap=1}}<br />
{{/Entry|18w14a|369|13741|snap=1}}<br />
{{/Entry|18w11a|368|13724|snap=1}}<br />
{{/Entry|18w10d|367|13702|snap=1}}<br />
{{/Entry|18w10c|366|13699|snap=1}}<br />
{{/Entry|18w10b|365|13693|snap=1}}<br />
{{/Entry|18w10a|364|13692|snap=1}}<br />
{{/Entry|18w09a|363|13671|snap=1}}<br />
{{/Entry|18w08b|362|13666|snap=1}}<br />
{{/Entry|18w08a|361|13662|snap=1}}<br />
{{/Entry|18w07c|360|13658|snap=1}}<br />
{{/Entry|18w07b|359|13653|snap=1}}<br />
{{/Entry|18w07a|358|13648|snap=1}}<br />
{{/Entry|18w06a|357|13636|snap=1}}<br />
{{/Entry|18w05a|356|13628|snap=1}}<br />
{{/Entry|18w03b|355|13623|snap=1}}<br />
{{/Entry|18w03a|354|snap=1}}<br />
{{/Entry|18w02a|353|13611|snap=1}}<br />
{{/Entry|18w01a|352|13576|snap=1}}<br />
{{/Entry|17w50a|351|13556|snap=1}}<br />
{{/Entry|17w49b|350|13524|snap=1}}<br />
{{/Entry|17w49a|349|13516|snap=1}}<br />
{{/Entry|17w48a|348|13512|snap=1}}<br />
{{/Entry|17w47b|347|13487|snap=1}}<br />
{{/Entry|17w47a|346|13476|snap=1}}<br />
{{/Entry|17w46a|345|13472|snap=1}}<br />
{{/Entry|17w45b|344|13414|snap=1}}<br />
{{/Entry|17w45a|343|13413|snap=1}}<br />
{{/Entry|17w43b|342|13398|snap=1}}<br />
{{/Entry|17w43a|341|13396|snap=1}}<br />
|-<br />
| '''{{Minecraft Wiki|1.12.2}}'''<br />
| 340<br />
| [{{canonicalurl:Protocol|oldid=14204}} page]<br />
{{Warning|<abbr title{{=}}"Note that this permalink links to and embeds content from the current versions of the articles. Use the following links for accurate information instead.">Hover for warning</abbr>}}<br />
<br />
* [{{canonicalurl:Data types|oldid=14256}} Data types]<br />
* [{{canonicalurl:Slot Data|oldid=7835}} Slot Data]<br />
* [{{canonicalurl:Chunk Format|oldid=14135}} Chunk Format]<br />
* [{{canonicalurl:Entity metadata|oldid=14048}} Entity metadata]<br />
* [{{canonicalurl:Entity statuses|14009}} Entity statuses]<br />
* [{{canonicalurl:Object Data|oldid=8314}} Object Data]<br />
* [{{canonicalurl:Block Actions|oldid=12934}} Block Actions]<br />
* [{{canonicalurl:Plugin channels|oldid=14089}} Plugin channels]<br />
|-<br />
| {{Minecraft Wiki|1.12.2-pre2}}<br />
|rowspan="2"| 339<br />
|rowspan="2"| [{{canonicalurl:Pre-release protocol|oldid=13355}} page]<br />
|-<br />
| {{Minecraft Wiki|1.12.2-pre1}}<br />
|-<br />
| '''{{Minecraft Wiki|1.12.1}}'''<br />
| 338<br />
| [{{canonicalurl:Protocol|oldid=13339}} page]<br />
|-<br />
| {{Minecraft Wiki|1.12.1-pre1}}<br />
| 337<br />
| [{{canonicalurl:Pre-release protocol|oldid=13267}} page]<br />
|-<br />
| {{Minecraft Wiki|17w31a}}<br />
| 336<br />
| [{{canonicalurl:Pre-release protocol|oldid=13265}} page]<br />
|-<br />
| '''{{Minecraft Wiki|1.12}}'''<br />
| 335<br />
| [{{canonicalurl:Protocol|oldid=13223}} page]<br />
|-<br />
| {{Minecraft Wiki|1.12-pre7}}<br />
| 334<br />
| [{{canonicalurl:Pre-release protocol|oldid=12918}} page]<br />
|-<br />
| {{Minecraft Wiki|1.12-pre6}}<br />
| 333<br />
| [{{canonicalurl:Pre-release protocol|oldid=12909}} page]<br />
|-<br />
| {{Minecraft Wiki|1.12-pre5}}<br />
| 332<br />
| [{{canonicalurl:Pre-release protocol|oldid=10809}} page]<br />
|-<br />
| {{Minecraft Wiki|1.12-pre4}}<br />
| 331<br />
| [{{canonicalurl:Pre-release protocol|oldid=10804}} page]<br />
|-<br />
| {{Minecraft Wiki|1.12-pre3}}<br />
| 330<br />
| [{{canonicalurl:Pre-release protocol|oldid=10803}} page]<br />
|-<br />
| {{Minecraft Wiki|1.12-pre2}}<br />
| 329<br />
| [{{canonicalurl:Pre-release protocol|oldid=10418}} page]<br />
|-<br />
| {{Minecraft Wiki|1.12-pre1}}<br />
| 328<br />
| [{{canonicalurl:Pre-release protocol|oldid=9819}} page]<br />
|-<br />
| {{Minecraft Wiki|17w18b}}<br />
| 327<br />
| [{{canonicalurl:Pre-release protocol|oldid=8548}} page]<br />
|-<br />
| {{Minecraft Wiki|17w18a}}<br />
| 326<br />
| [{{canonicalurl:Pre-release protocol|oldid=8546}} page]<br />
|-<br />
| {{Minecraft Wiki|17w17b}}<br />
| 325<br />
| [{{canonicalurl:Pre-release protocol|oldid=8536}} page]<br />
|-<br />
| {{Minecraft Wiki|17w17a}}<br />
| 324<br />
| [{{canonicalurl:Pre-release protocol|oldid=8528}} page]<br />
|-<br />
| {{Minecraft Wiki|17w16b}}<br />
| 323<br />
| [{{canonicalurl:Pre-release protocol|oldid=8519}} page]<br />
|-<br />
| {{Minecraft Wiki|17w16a}}<br />
| 322<br />
| [{{canonicalurl:Pre-release protocol|oldid=8515}} page]<br />
|-<br />
| {{Minecraft Wiki|17w15a}}<br />
| 321<br />
| [{{canonicalurl:Pre-release protocol|oldid=8499}} page]<br />
|-<br />
| {{Minecraft Wiki|17w14a}}<br />
| 320<br />
| [{{canonicalurl:Pre-release protocol|oldid=8490}} page]<br />
|-<br />
| {{Minecraft Wiki|17w13b}}<br />
| 319<br />
| [{{canonicalurl:Pre-release protocol|oldid=8475}} page]<br />
|-<br />
| {{Minecraft Wiki|17w13a}}<br />
| 318<br />
| [{{canonicalurl:Pre-release protocol|oldid=8454}} page]<br />
|-<br />
| {{Minecraft Wiki|17w06a}}<br />
| 317<br />
| [{{canonicalurl:Pre-release protocol|oldid=8414}} page]<br />
|-<br />
| '''{{Minecraft Wiki|1.11.2}}'''<br />
|rowspan="3"| 316<br />
|rowspan="3"| [{{canonicalurl:Protocol|oldid=8543}} page]<br />
|-<br />
| '''{{Minecraft Wiki|1.11.1}}'''<br />
|-<br />
| {{Minecraft Wiki|16w50a}}<br />
|-<br />
| '''{{Minecraft Wiki|1.11}}'''<br />
| 315<br />
| [{{canonicalurl:Protocol|oldid=8405}} page]<br />
|-<br />
| {{Minecraft Wiki|1.11-pre1}}<br />
| 314<br />
| [{{canonicalurl:Pre-release protocol|oldid=8249}} page]<br />
|-<br />
| {{Minecraft Wiki|16w44a}}<br />
|rowspan="2"| 313<br />
|rowspan="2"| [{{canonicalurl:Pre-release protocol|oldid=8246}} page]<br />
|-<br />
| {{Minecraft Wiki|16w43a}}<br />
|-<br />
| {{Minecraft Wiki|16w42a}}<br />
| 312<br />
| [{{canonicalurl:Pre-release protocol|oldid=8225}} page]<br />
|-<br />
| {{Minecraft Wiki|16w41a}}<br />
| 311<br />
| [{{canonicalurl:Pre-release protocol|oldid=8218}} page]<br />
|-<br />
| {{Minecraft Wiki|16w40a}}<br />
| 310<br />
| [{{canonicalurl:Pre-release protocol|oldid=8204}} page]<br />
|-<br />
| {{Minecraft Wiki|16w39c}}<br />
| 309<br />
| [{{canonicalurl:Pre-release protocol|oldid=8177}} page]<br />
|-<br />
| {{Minecraft Wiki|16w39b}}<br />
| 308<br />
| [{{canonicalurl:Pre-release protocol|oldid=8149}} page]<br />
|-<br />
| {{Minecraft Wiki|16w39a}}<br />
| 307<br />
| [{{canonicalurl:Pre-release protocol|oldid=8141}} page]<br />
|-<br />
| {{Minecraft Wiki|16w38a}}<br />
| 306<br />
| [{{canonicalurl:Pre-release protocol|oldid=8118}} page]<br />
|-<br />
| {{Minecraft Wiki|16w36a}}<br />
| 305<br />
| [{{canonicalurl:Pre-release protocol|oldid=8099}} page]<br />
|-<br />
| {{Minecraft Wiki|16w35a}}<br />
| 304<br />
| [{{canonicalurl:Pre-release protocol|oldid=8094}} page]<br />
|-<br />
| {{Minecraft Wiki|16w33a}}<br />
| 303<br />
| [{{canonicalurl:Pre-release protocol|oldid=8084}} page]<br />
|-<br />
| {{Minecraft Wiki|16w32b}}<br />
| 302<br />
| [{{canonicalurl:Pre-release protocol|oldid=8063}} page]<br />
|-<br />
| {{Minecraft Wiki|16w32a}}<br />
| 301<br />
| [{{canonicalurl:Pre-release protocol|oldid=8062}} page]<br />
|-<br />
| '''{{Minecraft Wiki|1.10.2}}'''<br />
|rowspan="3"| 210<br />
|rowspan="3"| [{{canonicalurl:Protocol|oldid=8235}} page]<br />
|-<br />
| '''{{Minecraft Wiki|1.10.1}}'''<br />
|-<br />
| '''{{Minecraft Wiki|1.10}}'''<br />
|-<br />
| {{Minecraft Wiki|1.10-pre2}}<br />
| 205<br />
| [{{canonicalurl:Pre-release protocol|oldid=7961}} page]<br />
|-<br />
| {{Minecraft Wiki|1.10-pre1}}<br />
| 204<br />
| [{{canonicalurl:Pre-release protocol|oldid=7950}} page]<br />
|-<br />
| {{Minecraft Wiki|16w21b}}<br />
| 203<br />
| [{{canonicalurl:Pre-release protocol|oldid=7890}} page]<br />
|-<br />
| {{Minecraft Wiki|16w21a}}<br />
| 202<br />
| [{{canonicalurl:Pre-release protocol|oldid=7877}} page]<br />
|-<br />
| {{Minecraft Wiki|16w20a}}<br />
| 201<br />
| [{{canonicalurl:Pre-release protocol|oldid=7859}} page]<br />
|-<br />
| '''{{Minecraft Wiki|1.9.4}}'''<br />
|rowspan="4"| 110<br />
|rowspan="4"| [{{canonicalurl:Protocol|oldid=7959}} page]<br />
|-<br />
| '''{{Minecraft Wiki|1.9.3}}'''<br />
|-<br />
| {{Minecraft Wiki|1.9.3-pre3}}<br />
|-<br />
| {{Minecraft Wiki|1.9.3-pre2}} <br />
|-<br />
| {{Minecraft Wiki|1.9.3-pre1}}<br />
|rowspan="5"| 109<br />
|rowspan="5"| [{{canonicalurl:Protocol|oldid=7817}} page]<br />
|-<br />
| {{Minecraft Wiki|16w15b}}<br />
|-<br />
| {{Minecraft Wiki|16w15a}}<br />
|-<br />
| {{Minecraft Wiki|16w14a}}<br />
|-<br />
| '''{{Minecraft Wiki|1.9.2}}'''<br />
|-<br />
| {{Minecraft Wiki|1.RV-Pre1}}<br />
| 108<br />
| [{{canonicalurl:Pre-release protocol|oldid=7552}} page]<ref group="note">Although it has the same ID as 1.9.1, the April Fools version 1.RV-Pre1 has new blocks and items that cannot be used on 1.9.1 servers.</ref><br />
|-<br />
| '''{{Minecraft Wiki|1.9.1}}'''<br />
|rowspan="3"| 108<br />
|rowspan="3"| [{{canonicalurl:Pre-release protocol|oldid=7552}} page]<br />
|-<br />
| {{Minecraft Wiki|1.9.1-pre3}}<br />
|-<br />
| {{Minecraft Wiki|1.9.1-pre2}}<br />
|-<br />
| {{Minecraft Wiki|1.9.1-pre1}}<br />
|rowspan="2"| 107<br />
|rowspan="2"| [{{canonicalurl:Protocol|oldid=7617}} page]<br />
|-<br />
| '''{{Minecraft Wiki|1.9}}'''<br />
|-<br />
| {{Minecraft Wiki|1.9-pre4}}<br />
| 106<br />
| [{{canonicalurl:Pre-release protocol|oldid=7401}} page]<br />
|-<br />
| {{Minecraft Wiki|1.9-pre3}}<br />
| 105<br />
|<br />
|-<br />
| {{Minecraft Wiki|1.9-pre2}}<br />
| 104<br />
| <br />
|-<br />
| {{Minecraft Wiki|1.9-pre1}}<br />
| 103<br />
| <br />
|-<br />
| {{Minecraft Wiki|16w07b}}<br />
| 102<br />
| <br />
|-<br />
| {{Minecraft Wiki|16w07a}}<br />
| 101<br />
|<br />
|-<br />
| {{Minecraft Wiki|16w06a}}<br />
| 100<br />
|<br />
|-<br />
| {{Minecraft Wiki|16w05b}}<br />
| 99<br />
|<br />
|-<br />
| {{Minecraft Wiki|16w05a}}<br />
| 98<br />
|<br />
|-<br />
| {{Minecraft Wiki|16w04a}}<br />
| 97<br />
|<br />
|-<br />
| {{Minecraft Wiki|16w03a}}<br />
| 96<br />
|<br />
|-<br />
| {{Minecraft Wiki|16w02a}}<br />
| 95<br />
| [{{canonicalurl:Pre-release protocol|oldid=7268}} page]<br />
|-<br />
| {{Minecraft Wiki|15w51b}}<br />
| 94<br />
| [{{canonicalurl:Pre-release protocol|oldid=7193}} page]<br />
|-<br />
| {{Minecraft Wiki|15w51a}}<br />
| 93<br />
| <br />
|-<br />
| {{Minecraft Wiki|15w50a}}<br />
| 92<br />
| <br />
|-<br />
| {{Minecraft Wiki|15w49b}}<br />
| 91<br />
| <br />
|-<br />
| {{Minecraft Wiki|15w49a}}<br />
| 90<br />
| <br />
|-<br />
| {{Minecraft Wiki|15w47c}}<br />
| 89<br />
| <br />
|-<br />
| {{Minecraft Wiki|15w47b}}<br />
| 88<br />
| <br />
|-<br />
| {{Minecraft Wiki|15w47a}}<br />
| 87<br />
| <br />
|-<br />
| {{Minecraft Wiki|15w46a}}<br />
| 86<br />
| <br />
|-<br />
| {{Minecraft Wiki|15w45a}}<br />
| 85<br />
| <br />
|-<br />
| {{Minecraft Wiki|15w44b}}<br />
| 84<br />
| <br />
|-<br />
| {{Minecraft Wiki|15w44a}}<br />
| 83<br />
| <br />
|-<br />
| {{Minecraft Wiki|15w43c}}<br />
| 82<br />
| <br />
|-<br />
| {{Minecraft Wiki|15w43b}}<br />
| 81<br />
| <br />
|-<br />
| {{Minecraft Wiki|15w43a}}<br />
| 80<br />
| <br />
|-<br />
| {{Minecraft Wiki|15w42a}}<br />
| 79<br />
| <br />
|-<br />
| {{Minecraft Wiki|15w41b}}<br />
| 78<br />
| <br />
|-<br />
| {{Minecraft Wiki|15w41a}}<br />
| 77<br />
| <br />
|-<br />
| {{Minecraft Wiki|15w40b}}<br />
| 76<br />
| [{{canonicalurl:Pre-release protocol|oldid=7087}} page]<br />
|-<br />
| {{Minecraft Wiki|15w40a}}<br />
| 75<br />
| <br />
|-<br />
| {{Minecraft Wiki|15w39c}}<br />
|rowspan="3"|74<br />
|rowspan="3"|<br />
|-<br />
| {{Minecraft Wiki|15w39b}}<br />
|-<br />
| {{Minecraft Wiki|15w39a}}<br />
|-<br />
| {{Minecraft Wiki|15w38b}}<br />
| 73<br />
| [{{canonicalurl:Pre-release protocol|oldid=6935}} page]<br />
|-<br />
| {{Minecraft Wiki|15w38a}}<br />
| 72<br />
| [{{canonicalurl:Pre-release protocol|oldid=6932}} page]<br />
|-<br />
| {{Minecraft Wiki|15w37a}}<br />
| 71<br />
| <br />
|-<br />
| {{Minecraft Wiki|15w36d}}<br />
| 70<br />
| [{{canonicalurl:Pre-release protocol|oldid=6901}} page]<br />
|-<br />
| {{Minecraft Wiki|15w36c}}<br />
| 69<br />
| [{{canonicalurl:Pre-release protocol|oldid=6881}} page]<br />
|-<br />
| {{Minecraft Wiki|15w36b}}<br />
| 68<br />
| <br />
|-<br />
| {{Minecraft Wiki|15w36a}}<br />
| 67<br />
| <br />
|-<br />
| {{Minecraft Wiki|15w35e}}<br />
| 66<br />
| [{{canonicalurl:Pre-release protocol|oldid=6851}} page]<br />
|-<br />
| {{Minecraft Wiki|15w35d}}<br />
| 65<br />
| <br />
|-<br />
| {{Minecraft Wiki|15w35c}}<br />
| 64<br />
| <br />
|-<br />
| {{Minecraft Wiki|15w35b}}<br />
| 63<br />
| [{{canonicalurl:Pre-release protocol|oldid=6829}} page]<br />
|-<br />
| {{Minecraft Wiki|15w35a}}<br />
| 62<br />
| <br />
|-<br />
| {{Minecraft Wiki|15w34d}}<br />
| 61<br />
| <br />
|-<br />
| {{Minecraft Wiki|15w34c}}<br />
| 60<br />
| <br />
|-<br />
| {{Minecraft Wiki|15w34b}}<br />
| 59<br />
| <br />
|-<br />
| {{Minecraft Wiki|15w34a}}<br />
| 58<br />
| [{{canonicalurl:Pre-release protocol|oldid=6809}} page]<br />
|-<br />
| {{Minecraft Wiki|15w33c}}<br />
| 57<br />
| [{{canonicalurl:Pre-release protocol|oldid=6806}} page]<br />
|-<br />
| {{Minecraft Wiki|15w33b}}<br />
| 56<br />
| [{{canonicalurl:Pre-release protocol|oldid=6796}} page]<br />
|-<br />
| {{Minecraft Wiki|15w33a}}<br />
| 55<br />
| [{{canonicalurl:Pre-release protocol|oldid=6790}} page]<br />
|-<br />
| {{Minecraft Wiki|15w32c}}<br />
| 54<br />
| [{{canonicalurl:Pre-release protocol|oldid=6788}} page]<br />
|-<br />
| {{Minecraft Wiki|15w32b}}<br />
| 53<br />
| <br />
|- <br />
| {{Minecraft Wiki|15w32a}}<br />
| 52<br />
| [{{canonicalurl:Pre-release protocol|oldid=6785}} page]<br />
|-<br />
| {{Minecraft Wiki|15w31c}}<br />
| 51<br />
| [{{canonicalurl:Pre-release protocol|oldid=6780}} page]<br />
|-<br />
| {{Minecraft Wiki|15w31b}}<br />
| 50<br />
| [{{canonicalurl:Pre-release protocol|oldid=6746}} page]<ref group="note">{{IRC quote|Dinnerbone|Protocol itself didn't change in 31c btw, but we added an entity which warrants incompatibility}}</ref><br />
|-<br />
| {{Minecraft Wiki|15w31a}}<br />
| 49<br />
| <br />
|-<br />
| {{Minecraft Wiki|15w14a}}<br />
| 48<br />
| <br />
|-<br />
| '''{{Minecraft Wiki|1.8.9}}'''<br />
|rowspan="22"| 47<br />
|rowspan="22"| [{{canonicalurl:Protocol|oldid=7368}} page]<br />
{{Warning|<abbr title{{=}}"Note that this permalink links to and embeds content from the current versions of the articles. Use the following links for accurate information instead.">Hover for warning</abbr>}}<br />
<br />
* [{{canonicalurl:Data types|oldid=7250}} Data types]<br />
* [{{canonicalurl:Slot Data|oldid=7094}} Slot Data]<br />
* [{{canonicalurl:Chunk Format|oldid=7164}} Chunk Format]<br />
* [{{canonicalurl:Entity metadata|oldid=7415}} Entity metadata]<br />
* [{{canonicalurl:Object Data|oldid=7248}} Object Data]<br />
* [{{canonicalurl:Block Actions|oldid=6895}} Block Actions]<br />
* [{{canonicalurl:Plugin channels|oldid=7435}} Plugin channels]<br />
<br />
|-<br />
| '''{{Minecraft Wiki|1.8.8}}'''<br />
|-<br />
| '''{{Minecraft Wiki|1.8.7}}'''<br />
|-<br />
| '''{{Minecraft Wiki|1.8.6}}'''<br />
|-<br />
| '''{{Minecraft Wiki|1.8.5}}'''<br />
|-<br />
| '''{{Minecraft Wiki|1.8.4}}'''<br />
|-<br />
| '''{{Minecraft Wiki|1.8.3}}'''<br />
|-<br />
| '''{{Minecraft Wiki|1.8.2}}'''<br />
|-<br />
| {{Minecraft Wiki|1.8.2-pre7}}<br />
|-<br />
| {{Minecraft Wiki|1.8.2-pre6}}<br />
|-<br />
| {{Minecraft Wiki|1.8.2-pre5}}<br />
|-<br />
| {{Minecraft Wiki|1.8.2-pre4}}<br />
|-<br />
| {{Minecraft Wiki|1.8.2-pre3}}<br />
|-<br />
| {{Minecraft Wiki|1.8.2-pre2}}<br />
|-<br />
| {{Minecraft Wiki|1.8.2-pre1}}<br />
|-<br />
| '''{{Minecraft Wiki|1.8.1}}'''<br />
|-<br />
| {{Minecraft Wiki|1.8.1-pre5}}<br />
|-<br />
| {{Minecraft Wiki|1.8.1-pre4}}<br />
|-<br />
| {{Minecraft Wiki|1.8.1-pre3}}<br />
|-<br />
| {{Minecraft Wiki|1.8.1-pre2}}<br />
|-<br />
| {{Minecraft Wiki|1.8.1-pre1}}<br />
|-<br />
| '''{{Minecraft Wiki|1.8}}'''<br />
|-<br />
| {{Minecraft Wiki|1.8-pre3}}<br />
| 46<br />
| <br />
|-<br />
| {{Minecraft Wiki|1.8-pre2}}<br />
| 45<br />
| <br />
|-<br />
| {{Minecraft Wiki|1.8-pre1}}<br />
| 44<br />
| <br />
|-<br />
| {{Minecraft Wiki|14w34d}}<br />
| 43<br />
| <br />
|-<br />
| {{Minecraft Wiki|14w34c}}<br />
| 42<br />
| <br />
|-<br />
| {{Minecraft Wiki|14w34b}}<br />
| 41<br />
| <br />
|-<br />
| {{Minecraft Wiki|14w34a}}<br />
| 40<br />
| <br />
|-<br />
| {{Minecraft Wiki|14w33c}}<br />
| 39<br />
| <br />
|-<br />
| {{Minecraft Wiki|14w33b}}<br />
| 38<br />
| <br />
|-<br />
| {{Minecraft Wiki|14w33a}}<br />
| 37<br />
| <br />
|-<br />
| {{Minecraft Wiki|14w32d}}<br />
| 36<br />
| <br />
|-<br />
| {{Minecraft Wiki|14w32c}}<br />
| 35<br />
| <br />
|-<br />
| {{Minecraft Wiki|14w32b}}<br />
| 34<br />
| <br />
|- <br />
| {{Minecraft Wiki|14w32a}}<br />
| 33<br />
| <br />
|-<br />
| {{Minecraft Wiki|14w31a}}<br />
| 32<br />
| <br />
|-<br />
| {{Minecraft Wiki|14w30c}}<br />
| 31<br />
| <br />
|-<br />
| {{Minecraft Wiki|14w30b}}<br />
|rowspan="2"| 30<br />
|rowspan="2"|<br />
|-<br />
| {{Minecraft Wiki|14w30a}}<br />
|-<br />
| {{Minecraft Wiki|14w29a}}<br />
|rowspan="2"| 29<br />
|rowspan="2"|<br />
|-<br />
| {{Minecraft Wiki|14w29a}}<br />
|-<br />
| {{Minecraft Wiki|14w28b}}<br />
| 28<br />
| <br />
|-<br />
| {{Minecraft Wiki|14w28a}}<br />
| 27<br />
| <br />
|-<br />
| {{Minecraft Wiki|14w27b}}<br />
|rowspan="2"| 26<br />
|rowspan="2"| <br />
|-<br />
| {{Minecraft Wiki|14w27a}}<br />
|-<br />
| {{Minecraft Wiki|14w26c}}<br />
| 25<br />
| <br />
|-<br />
| {{Minecraft Wiki|14w26b}}<br />
| 24<br />
| <br />
|-<br />
| {{Minecraft Wiki|14w26a}}<br />
| 23<br />
| <br />
|-<br />
| {{Minecraft Wiki|14w25b}}<br />
| 22<br />
| <br />
|-<br />
| {{Minecraft Wiki|14w25a}}<br />
| 21<br />
| <br />
|-<br />
| {{Minecraft Wiki|14w21b}}<br />
| 20<br />
| <br />
|-<br />
| {{Minecraft Wiki|14w21a}}<br />
| 19<br />
| <br />
|-<br />
| {{Minecraft Wiki|14w20b}}<br />
|rowspan="2"| 18<br />
|rowspan="2"|<br />
|-<br />
| {{Minecraft Wiki|14w20a}}<br />
|-<br />
| {{Minecraft Wiki|14w19a}}<br />
| 17<br />
| <br />
|-<br />
| {{Minecraft Wiki|14w18b}}<br />
|rowspan="2"| 16<br />
|rowspan="2"|<br />
|-<br />
| {{Minecraft Wiki|14w18a}}<br />
|-<br />
| {{Minecraft Wiki|14w17a}}<br />
| 15<br />
| <br />
|-<br />
| {{Minecraft Wiki|14w11b}}<br />
|rowspan="2"| 14<br />
|rowspan="2"|<br />
|-<br />
| {{Minecraft Wiki|14w11a}}<br />
|-<br />
| {{Minecraft Wiki|14w10c}}<br />
|rowspan="3"| 13<br />
|rowspan="3"| <br />
|-<br />
| {{Minecraft Wiki|14w10b}}<br />
|-<br />
| {{Minecraft Wiki|14w10a}}<br />
|-<br />
| {{Minecraft Wiki|14w08a}}<br />
| 12<br />
| <br />
|-<br />
| {{Minecraft Wiki|14w07a}}<br />
| 11<br />
| <br />
|-<br />
| {{Minecraft Wiki|14w06b}}<br />
|rowspan="2"| 10<br />
|rowspan="2"|<br />
|-<br />
| {{Minecraft Wiki|14w06a}}<br />
|-<br />
| {{Minecraft Wiki|14w05b}}<br />
|rowspan="2"| 9<br />
|rowspan="2"|<br />
|-<br />
| {{Minecraft Wiki|14w05a}}<br />
|-<br />
| {{Minecraft Wiki|14w04b}}<br />
| 8<br />
| <br />
|-<br />
| {{Minecraft Wiki|14w04a}}<br />
| 7<br />
| <br />
|-<br />
| {{Minecraft Wiki|14w03b}}<br />
|rowspan="2"| 6<br />
|rowspan="2"|<br />
|-<br />
| {{Minecraft Wiki|14w03a}}<br />
|-<br />
| {{Minecraft Wiki|14w02c}}<br />
|rowspan="14"| 5<br />
|rowspan="14"| [{{canonicalurl:Protocol|oldid=6003}} page]<br />
|-<br />
| {{Minecraft Wiki|14w02b}}<br />
|-<br />
| {{Minecraft Wiki|14w02a}}<br />
|-<br />
| '''{{Minecraft Wiki|1.7.10}}'''<br />
|-<br />
| {{Minecraft Wiki|1.7.10-pre4}}<br />
|-<br />
| {{Minecraft Wiki|1.7.10-pre3}}<br />
|-<br />
| {{Minecraft Wiki|1.7.10-pre2}}<br />
|-<br />
| {{Minecraft Wiki|1.7.10-pre1}}<br />
|-<br />
| '''{{Minecraft Wiki|1.7.9}}'''<br />
|-<br />
| '''{{Minecraft Wiki|1.7.8}}'''<br />
|-<br />
| '''{{Minecraft Wiki|1.7.7}}'''<br />
|-<br />
| '''{{Minecraft Wiki|1.7.6}}'''<br />
|-<br />
| {{Minecraft Wiki|1.7.6-pre2}}<br />
|-<br />
| {{Minecraft Wiki|1.7.6-pre1}}<br />
|-<br />
| '''{{Minecraft Wiki|1.7.5}}'''<br />
|rowspan="12"| 4<br />
|rowspan="12"| [{{canonicalurl:Protocol|oldid=5486}} page]<br />
|-<br />
| '''{{Minecraft Wiki|1.7.4}}'''<br />
|-<br />
| {{Minecraft Wiki|1.7.3-pre}}<br />
|-<br />
| {{Minecraft Wiki|13w49a}}<br />
|-<br />
| {{Minecraft Wiki|13w48b}}<br />
|-<br />
| {{Minecraft Wiki|13w48a}}<br />
|-<br />
| {{Minecraft Wiki|13w47e}}<br />
|-<br />
| {{Minecraft Wiki|13w47d}}<br />
|-<br />
| {{Minecraft Wiki|13w47c}}<br />
|-<br />
| {{Minecraft Wiki|13w47b}}<br />
|-<br />
| {{Minecraft Wiki|13w47a}}<br />
|-<br />
| '''{{Minecraft Wiki|1.7.2}}'''<br />
|-<br />
| {{Minecraft Wiki|1.7.1-pre}}<br />
|rowspan="2"| 3<br />
|rowspan="2"|<br />
|-<br />
| {{Minecraft Wiki|1.7-pre}}<br />
|-<br />
| {{Minecraft Wiki|13w43a}}<br />
| 2<br />
| <br />
|-<br />
| {{Minecraft Wiki|13w42b}}<br />
| rowspan="2" | 1<br />
| rowspan="2" | [{{canonicalurl:Pre-release protocol|oldid=5042}} page]<br />
|-<br />
| {{Minecraft Wiki|13w42a}}<br />
|-<br />
| {{Minecraft Wiki|13w41b}}<br />
| 0<br />
| [{{canonicalurl:Pre-release protocol|oldid=5007}} page]<ref group="note">Despite having the same ID, 13w41a and 13w41b are incompatible.</ref><br />
|-<br />
| {{Minecraft Wiki|13w41a}}<br />
| 0<br />
| [{{canonicalurl:Pre-release protocol|oldid=4957}} page]<br />
|}<br />
<br />
=== Notes ===<br />
<br />
<references group="note" /><br />
<br />
=== Examples ===<br />
<br />
Json: [https://github.com/PrismarineJS/minecraft-data/blob/master/data/pc/common/protocolVersions.json minecraft-data]<br />
<br />
== Versions before the Netty rewrite ==<br />
<br />
Minecraft version 1.6.4 and older used a protocol versioning scheme separate from the current one. As such, the same version number may ambiguously refer to an old version in this list and a new version in the list above. For ease of navigation, this list is also split by Minecraft release stages, but the versions were not reset between these (other than near the start of alpha).<br />
<br />
=== Release ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Release name<br />
! Version number<br />
! Last known documentation<br />
|-<br />
| {{Minecraft Wiki|13w39b}}<br />
|rowspan="2"| 80<br />
|rowspan="2"| [{{canonicalurl:Pre-release protocol|oldid=4825}} page]<br />
|-<br />
| {{Minecraft Wiki|13w39a}}<br />
|-<br />
| {{Minecraft Wiki|13w38c}}<br />
|rowspan="3"| 79<br />
|rowspan="3"| <br />
|-<br />
| {{Minecraft Wiki|13w38b}}<br />
|-<br />
| {{Minecraft Wiki|13w38a}}<br />
|-<br />
| '''{{Minecraft Wiki|1.6.4}}'''<br />
| 78<br />
| [{{canonicalurl:Protocol|oldid=4899}} page]<br />
|-<br />
| {{Minecraft Wiki|1.6.3-pre}}<br />
| 77<br />
| <br />
|-<br />
| {{Minecraft Wiki|13w37b}}<br />
|rowspan="2"| 76<br />
|rowspan="2"| <br />
|-<br />
| {{Minecraft Wiki|13w37a}}<br />
|-<br />
| {{Minecraft Wiki|13w36b}}<br />
|rowspan="2"| 75<br />
|rowspan="2"| <br />
|-<br />
| {{Minecraft Wiki|13w36a}}<br />
|-<br />
| '''{{Minecraft Wiki|1.6.2}}'''<br />
| 74<br />
| <br />
|-<br />
| '''{{Minecraft Wiki|1.6.1}}'''<br />
| 73<br />
| [{{canonicalurl:Protocol|oldid=1095}} page]<br />
|-<br />
| {{Minecraft Wiki|1.6-pre}}<br />
|rowspan="2"| 72<br />
|rowspan="2"| <br />
|-<br />
| {{Minecraft Wiki|13w26a}}<br />
|-<br />
| {{Minecraft Wiki|13w25c}}<br />
|rowspan="3"| 71<br />
|rowspan="3"| <br />
|-<br />
| {{Minecraft Wiki|13w25b}}<br />
|-<br />
| {{Minecraft Wiki|13w25a}}<br />
|-<br />
| {{Minecraft Wiki|13w24b}}<br />
| 70<br />
| <br />
|-<br />
| {{Minecraft Wiki|13w24a}}<br />
| 69<br />
| <br />
|-<br />
| {{Minecraft Wiki|13w23b}}<br />
| 68<br />
| <br />
|-<br />
| {{Minecraft Wiki|13w23a}}<br />
|rowspan="4"| 67<br />
|rowspan="4"| <br />
|-<br />
| {{Minecraft Wiki|13w22a}}<br />
|-<br />
| {{Minecraft Wiki|13w21b}}<br />
|-<br />
| {{Minecraft Wiki|13w21a}}<br />
|-<br />
| {{Minecraft Wiki|13w19a}}<br />
| 66<br />
| <br />
|-<br />
| {{Minecraft Wiki|13w18c}}<br />
|rowspan="3"| 65<br />
|rowspan="3"|<br />
|-<br />
| {{Minecraft Wiki|13w18b}}<br />
|-<br />
| {{Minecraft Wiki|13w18a}}<br />
|-<br />
| {{Minecraft Wiki|13w17a}}<br />
| 64<br />
| <br />
|-<br />
| {{Minecraft Wiki|13w16b}}<br />
| 63<br />
| <br />
|-<br />
| {{Minecraft Wiki|13w16a}}<br />
| 62<br />
| <br />
|-<br />
| '''{{Minecraft Wiki|1.5.2}}'''<br />
| 61<br />
| <br />
|-<br />
| '''{{Minecraft Wiki|2.0}}''': Purple<br />
| 92<br />
|<br />
|-<br />
| '''{{Minecraft Wiki|2.0}}''': Red<br />
| 91<br />
|<br />
|-<br />
| '''{{Minecraft Wiki|2.0}}''': Blue<br />
| 90<br />
|<br />
|-<br />
| '''{{Minecraft Wiki|1.5.1}}'''<br />
|rowspan="7"| 60<br />
|rowspan="7"|<br />
|-<br />
| {{Minecraft Wiki|13w12~}}<br />
|-<br />
| {{Minecraft Wiki|13w11a}}<br />
|-<br />
| '''{{Minecraft Wiki|1.5}}'''<br />
|-<br />
| {{Minecraft Wiki|13w10b}}<br />
|-<br />
| {{Minecraft Wiki|13w10a}}<br />
|-<br />
| {{Minecraft Wiki|13w09c}}<br />
|-<br />
| {{Minecraft Wiki|13w09b}}<br />
|rowspan="2"| 59<br />
|rowspan="2"|<br />
|-<br />
| {{Minecraft Wiki|13w09a}}<br />
|-<br />
| {{Minecraft Wiki|13w07a}}<br />
|rowspan="2"| 58<br />
|rowspan="2"|<br />
|-<br />
| {{Minecraft Wiki|13w06a}}<br />
|-<br />
| {{Minecraft Wiki|13w05b}}<br />
| 57<br />
| <br />
|-<br />
| {{Minecraft Wiki|13w05a}}<br />
| 56<br />
| <br />
|-<br />
| {{Minecraft Wiki|13w04a}}<br />
| 55<br />
| <br />
|-<br />
| {{Minecraft Wiki|13w03a}}<br />
| 54<br />
| <br />
|-<br />
| {{Minecraft Wiki|13w02b}}<br />
|rowspan="2"| 53<br />
|rowspan="2"|<br />
|-<br />
| {{Minecraft Wiki|13w02a}}<br />
|-<br />
| {{Minecraft Wiki|13w01b}}<br />
|rowspan="2"| 52<br />
|rowspan="2"|<br />
|-<br />
| {{Minecraft Wiki|13w01a}}<br />
|-<br />
| '''{{Minecraft Wiki|1.4.7}}'''<br />
|rowspan="4"| 51<br />
|rowspan="4"| [{{canonicalurl:Protocol|oldid=1039}} page]<br />
|-<br />
| '''{{Minecraft Wiki|1.4.6}}'''<br />
|-<br />
| {{Minecraft Wiki|12w50b}}<br />
|-<br />
| {{Minecraft Wiki|12w50a}}<br />
|-<br />
| {{Minecraft Wiki|12w49a}}<br />
| 50<br />
| <br />
|-<br />
| '''{{Minecraft Wiki|1.4.5}}'''<br />
|rowspan="2"| 49<br />
|rowspan="2"| <br />
|-<br />
| '''{{Minecraft Wiki|1.4.4}}'''<br />
|-<br />
| {{Minecraft Wiki|1.4.3-pre}}<br />
| 48<br />
| <br />
|-<br />
| '''{{Minecraft Wiki|1.4.2}}'''<br />
| 47<br />
| <br />
|-<br />
| {{Minecraft Wiki|12w42b}}<br />
|rowspan="4"| 46<br />
|rowspan="4"|<br />
|-<br />
| {{Minecraft Wiki|12w42a}}<br />
|-<br />
| {{Minecraft Wiki|12w41b}}<br />
|-<br />
| {{Minecraft Wiki|12w41a}}<br />
|-<br />
| {{Minecraft Wiki|12w40b}}<br />
| 45<br />
| <br />
|-<br />
| {{Minecraft Wiki|12w40a}}<br />
| 44<br />
| <br />
|-<br />
| {{Minecraft Wiki|12w39b}}<br />
|rowspan="4"| 43<br />
|rowspan="4"|<br />
|-<br />
| {{Minecraft Wiki|12w39a}}<br />
|-<br />
| {{Minecraft Wiki|12w38b}}<br />
|-<br />
| {{Minecraft Wiki|12w38a}}<br />
|-<br />
| {{Minecraft Wiki|12w37a}}<br />
|rowspan="3"| 42<br />
|rowspan="3"|<br />
|-<br />
| {{Minecraft Wiki|12w36a}}<br />
|-<br />
| {{Minecraft Wiki|12w34b}}<br />
|-<br />
| {{Minecraft Wiki|12w34a}}<br />
| 41<br />
| <br />
|-<br />
| {{Minecraft Wiki|12w32a}}<br />
| 40<br />
| <br />
|-<br />
| '''{{Minecraft Wiki|1.3.2}}'''<br />
|rowspan="5"| 39<br />
|rowspan="5"| [{{canonicalurl:Protocol|oldid=980}} page]<br />
|-<br />
| '''{{Minecraft Wiki|1.3.1}}'''<br />
|-<br />
| {{Minecraft Wiki|12w30e}}<br />
|-<br />
| {{Minecraft Wiki|12w30d}}<br />
|-<br />
| {{Minecraft Wiki|12w30c}}<br />
|-<br />
| {{Minecraft Wiki|12w30b}}<br />
|rowspan="3"| 38<br />
|rowspan="3"|<br />
|-<br />
| {{Minecraft Wiki|12w30a}}<br />
|-<br />
| {{Minecraft Wiki|12w27a}}<br />
|-<br />
| {{Minecraft Wiki|12w26a}}<br />
|rowspan="2"| 37<br />
|rowspan="2"| <br />
|-<br />
| {{Minecraft Wiki|12w25a}}<br />
|-<br />
| {{Minecraft Wiki|12w24a}}<br />
| 36<br />
| <br />
|-<br />
| {{Minecraft Wiki|12w23b}}<br />
|rowspan="2"| 35<br />
|rowspan="2"|<br />
|-<br />
| {{Minecraft Wiki|12w23a}}<br />
|-<br />
| {{Minecraft Wiki|12w22a}}<br />
| 34<br />
| <br />
|-<br />
| {{Minecraft Wiki|12w21b}}<br />
|rowspan="2"| 33<br />
|rowspan="2"| <br />
|-<br />
| {{Minecraft Wiki|12w21a}}<br />
|-<br />
| {{Minecraft Wiki|12w19a}}<br />
|rowspan="2"| 32<br />
|rowspan="2"| <br />
|-<br />
| {{Minecraft Wiki|12w18a}}<br />
|-<br />
| {{Minecraft Wiki|12w17a}}<br />
| 31<br />
| <br />
|-<br />
| {{Minecraft Wiki|12w16a}}<br />
| 30<br />
| <br />
|-<br />
| {{Minecraft Wiki|12w15a}}<br />
|rowspan="3"| 29<br />
|rowspan="3"| [{{canonicalurl:Protocol|oldid=932}} page]<ref group="old note">This protocol has no encryption and a different handshake layout than the previous ones.</ref><br />
|-<br />
| '''{{Minecraft Wiki|1.2.5}}'''<br />
|-<br />
| '''{{Minecraft Wiki|1.2.4}}'''<br />
|-<br />
| '''{{Minecraft Wiki|1.2.3}}'''<br />
|rowspan="4"| 28<br />
|rowspan="4"| <br />
|-<br />
| '''{{Minecraft Wiki|1.2.2}}'''<br />
|-<br />
| '''{{Minecraft Wiki|1.2.1}}'''<br />
|-<br />
| {{Minecraft Wiki|12w08a}}<br />
|-<br />
| {{Minecraft Wiki|12w07b}}<br />
|rowspan="2"| 27<br />
|rowspan="2"|<br />
|-<br />
| {{Minecraft Wiki|12w07a}}<br />
|-<br />
| {{Minecraft Wiki|12w06a}}<br />
| 25<br />
| <br />
|-<br />
| {{Minecraft Wiki|12w05b}}<br />
|rowspan="4"|24<br />
|rowspan="4"|<br />
|-<br />
| {{Minecraft Wiki|12w05a}}<br />
|-<br />
| {{Minecraft Wiki|12w04a}}<br />
|-<br />
| {{Minecraft Wiki|12w03a}}<br />
|-<br />
| '''{{Minecraft Wiki|1.1}}'''<br />
| 23 <ref group="old note">This version is incompatible with 12w01a which also uses protocol 23, due to the removal of 0x1B.</ref><br />
| <br />
|-<br />
| {{Minecraft Wiki|12w01a}}<br />
| 23<br />
| <br />
|-<br />
| {{Minecraft Wiki|11w50a}}<br />
|rowspan=2|22 <ref group="old note">These versions are incompatible with the previous snapshots also using protocol 22, due to the additon of 0xFA Plugin Message.</ref><br />
|rowspan=2|<br />
|-<br />
| {{Minecraft Wiki|11w49a}}<br />
|-<br />
| {{Minecraft Wiki|11w48a}}<br />
|rowspan=4|22<br />
|rowspan=4|[{{canonicalurl:Protocol|oldid=689}} page]<br />
|-<br />
| {{Minecraft Wiki|11w47a}}<br />
|-<br />
| '''{{Minecraft Wiki|1.0.1}}'''<br />
|-<br />
| '''{{Minecraft Wiki|1.0.0}}'''<br />
|}<br />
<br />
=== Beta ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Release name<br />
! Version number<br />
! Last known documentation<br />
|-<br />
| {{Minecraft Wiki|1.0.0-RC2}}<br />
|rowspan=3|22<br />
|rowspan=3|See 1.0.0<br />
|-<br />
| {{Minecraft Wiki|1.0.0-RC1}}<br />
|-<br />
| {{Minecraft Wiki|Beta 1.9-pre6}}<br />
|-<br />
| {{Minecraft Wiki|Beta 1.9-pre5}}<br />
| 21<br />
| <br />
|-<br />
| {{Minecraft Wiki|Beta 1.9-pre4}}<br />
| 20<br />
| <br />
|-<br />
| {{Minecraft Wiki|Beta 1.9-pre3}}<br />
|rowspan="2"|19<br />
|rowspan="2"|<br />
|-<br />
| {{Minecraft Wiki|Beta 1.9-pre2}}<br />
|-<br />
| {{Minecraft Wiki|Beta 1.9-pre1}}<br />
| 18<br />
| <br />
|-<br />
| '''{{Minecraft Wiki|Beta 1.8.1}}'''<br />
|rowspan="2"|17<br />
|rowspan="2"| <br />
|-<br />
| '''{{Minecraft Wiki|Beta 1.8}}'''<br />
|-<br />
| {{Minecraft Wiki|Beta 1.8-pre2}}<br />
| 16<br />
| <br />
|-<br />
| {{Minecraft Wiki|Beta 1.8-pre1}}<br />
| 15<br />
| <br />
|-<br />
| '''{{Minecraft Wiki|Beta 1.7.3}}'''<br />
|rowspan="4"|14<br />
|rowspan="4"|<br />
|-<br />
| '''{{Minecraft Wiki|Beta 1.7.2}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Beta 1.7.1}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Beta 1.7}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Beta 1.6.6}}'''<br />
|rowspan="7"|13<br />
|rowspan="7"|<br />
|-<br />
| '''{{Minecraft Wiki|Beta 1.6.5}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Beta 1.6.4}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Beta 1.6.3}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Beta 1.6.2}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Beta 1.6.1}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Beta 1.6}}'''<br />
|-<br />
| {{Minecraft Wiki|Beta 1.6 Test Build 3}}<br />
| 12<br />
| <ref group="old note">This version was never publicly released, but is found lurking on the old update site. It's equivalent to beta 1.6 in terms of protocol. Curiously, it has a unique protocol version.</ref><br />
|-<br />
| '''{{Minecraft Wiki|Beta 1.5_02}}'''<br />
|rowspan="3"| 11<br />
|<ref group="old note">Beta 1.5_02 was a server-only update.</ref><br />
|-<br />
| '''{{Minecraft Wiki|Beta 1.5_01}}'''<br />
|rowspan="2"|<br />
|-<br />
| '''{{Minecraft Wiki|Beta 1.5}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Beta 1.4_01}}'''<br />
|rowspan="2"| 10<br />
|rowspan="2"|<br />
|-<br />
| '''{{Minecraft Wiki|Beta 1.4}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Beta 1.3_01}}'''<br />
|rowspan="2"| 9<br />
|rowspan="2"|<br />
|-<br />
| '''{{Minecraft Wiki|Beta 1.3}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Beta 1.2_02}}'''<br />
|rowspan="4"| 8<br />
|rowspan="4"|<br />
|-<br />
| '''{{Minecraft Wiki|Beta 1.2_01}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Beta 1.2}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Beta 1.1_02}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Beta 1.1_01}}'''<br />
|rowspan="2"| 7<br />
|rowspan="2"|<br />
|-<br />
| '''{{Minecraft Wiki|Beta 1.1}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Beta 1.0_02}}'''<br />
|rowspan="3"| 7<br />
|rowspan="3"|<br />
|-<br />
| '''{{Minecraft Wiki|Beta 1.0_01}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Beta 1.0}}'''<br />
|}<br />
<br />
=== Alpha ===<br />
<br />
Note: the position of alpha servers with relation to clients is mostly guesswork partially based on timestamps, and shouldn't be treated as an exact record of when things were released publicly.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Release name<br />
! Version number<br />
! Last known documentation<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.2.6}}'''<br />
|rowspan="9"| 6<br />
|rowspan="8"|<br />
|-<br />
| Alpha server 0.2.8<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.2.5}}'''<br />
|-<br />
| Alpha server 0.2.7<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.2.4_01}}'''<br />
|-<br />
| Alpha server 0.2.6_02<br />
|-<br />
| Alpha server 0.2.6_01<br />
|-<br />
| Alpha server 0.2.6<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.2.3_05}}'''<br />
| <ref group="old note">Alpha 1.2.3_05 is actually the first release of Alpha 1.2.4.</ref><br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.2.3_04}}'''<br />
|rowspan="7"| 5<br />
|rowspan="7"|<br />
|-<br />
| Alpha server 0.2.5_02<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.2.3_02}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.2.3_01}}'''<br />
|-<br />
| Alpha server 0.2.5_01<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.2.3}}'''<br />
|-<br />
| Alpha server 0.2.5<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.2.2}}'''<br />
|rowspan="2"| 4<br />
|rowspan="2"|<br />
|-<br />
| Alpha server 0.2.4<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.2.1_01}}'''<br />
|rowspan="2"| 3<br />
|rowspan="2"|<br />
|-<br />
| Alpha server 0.2.3<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.2.1}}'''<br />
| {{Unknown|Unknown (3?)}}<br />
|<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.2.0_02}}'''<br />
|rowspan="5"| 3<br />
|rowspan="5"|<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.2.0_01}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.2.0}}'''<br />
|-<br />
| Alpha server 0.2.2_01<br />
|-<br />
| Alpha server 0.2.2<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.1.2_01}}'''<br />
|rowspan="3"| 2<br />
|rowspan="3"|<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.1.2}}'''<br />
|-<br />
| Alpha server 0.2.1<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.1.1}}'''<br />
| {{Unknown|Unknown (2?)}}<br />
|<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.1.0}}'''<br />
|rowspan="4"| 2<br />
|rowspan="4"|<br />
|-<br />
| Alpha server 0.2.1<br />
|-<br />
| Alpha server 0.2.0_01<br />
|-<br />
| Alpha server 0.2.0<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.17_04}}'''<br />
|rowspan="4"| 1<br />
|rowspan="4"|<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.17_03}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.17_02}}'''<br />
|-<br />
| Alpha server 0.1.4<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.17_01}}'''<br />
|rowspan="2" {{Unknown|Unknown (1?)}}<br />
|rowspan="2"|<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.17}}'''<br />
|-<br />
| Alpha server 0.1.3<br />
|rowspan="5"|14<br />
|rowspan="5"|<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.16_02}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.16_01}}'''<br />
|-<br />
| Alpha server 0.1.2_01<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.16}}'''<br />
|-<br />
| Alpha server 0.1.0<br />
|rowspan="2"|13<br />
|<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.15}}'''<br />
| <ref group="old note">1.0.15 is the first version publicly supporting SMP</ref><br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.14}}'''<br />
|rowspan="3"| 12<br />
|rowspan="6"| <ref group="old note">These versions have a multiplayer button, but a specific server is hardcoded.</ref><br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.13_01}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.13}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.12}}'''<br />
| 11<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.11}}'''<br />
|rowspan="4"| 10<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.10}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.9}}'''<br />
|rowspan="10"| <ref group="old note">These versions have multiplayer code, but no multiplayer interface.</ref><br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.8_01}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.8}}'''<br />
| {{Unknown|Unknown (10?)}}<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.7}}'''<br />
|rowspan="2"| 10<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.6_03}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.6_02}}'''<br />
|{{Unknown|Unknown (10?)}}<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.6_01}}'''<br />
|rowspan="4"| 10<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.6}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.5_01}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.5}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.4}}'''<br />
|rowspan="8" {{No|Multiplayer did not exist at this time}}<br />
|rowspan="8" |<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.3}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.2_02}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.2_01}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.2}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.1_01}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.1}}'''<br />
|-<br />
| '''{{Minecraft Wiki|Alpha 1.0.0}}'''<br />
|}<br />
<br />
=== Classic ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Release name<br />
! Version number<br />
! Last known documentation<br />
|-<br />
| c0.30-3<br />
|rowspan="5"| 7<br />
|rowspan="5"| [[Classic Protocol|page]]<br />
|-<br />
| c0.30-2<br />
|-<br />
| c0.30-1<br />
|-<br />
| c0.29_02<br />
|-<br />
| c0.29_01<br />
|-<br />
| c0.29<br />
|rowspan="1" {{Unknown|Unknown (7?)}}<br />
|rowspan="1" |<br />
|-<br />
| c0.28_01<br />
| 7<br />
|<br />
|-<br />
| c0.28<br />
| {{Unknown|Unknown (7?)}}<br />
|<br />
|-<br />
| c0.27_st_c<br />
|rowspan="2" {{Unknown|Unknown (6?)}}<br />
|rowspan="2" |<br />
|-<br />
| c0.27_st_b<br />
|-<br />
| c0.27_st_a<br />
| 6<br />
|<br />
|-<br />
| c0.26_st_g<br />
|rowspan="7" {{Unknown|Unknown (6?)}}<br />
|rowspan="7" |<br />
|-<br />
| c0.26_st_f<br />
|-<br />
| c0.26_st_e<br />
|-<br />
| c0.26_st_d<br />
|-<br />
| c0.26_st_c<br />
|-<br />
| c0.26_st_b<br />
|-<br />
| c0.26_st_a<br />
|-<br />
| c0.25_05_st<br />
| 6<br />
|-<br />
| c0.25_04_st<br />
|rowspan="6" {{Unknown|Unknown (6?)}}<br />
|rowspan="6" |<br />
|-<br />
| c0.25_03_st<br />
|-<br />
| c0.25_02_st<br />
|-<br />
| c0.25_01_st<br />
|-<br />
| c0.25_st<br />
|-<br />
| c0.24_st_d<br />
|-<br />
| c0.24_st_c<br />
| 6<br />
|-<br />
| c0.24_st_b<br />
|rowspan="10" {{Unknown|Unknown (6?)}}<br />
|rowspan="10" |<br />
|-<br />
| c0.24_st_a<br />
|-<br />
| c0.24_07<br />
|-<br />
| c0.24_06<br />
|-<br />
| c0.24_05<br />
|-<br />
| c0.24_04<br />
|-<br />
| c0.24_03<br />
|-<br />
| c0.24_02<br />
|-<br />
| c0.24_01<br />
|-<br />
| c0.24<br />
<!-- There is a version of this, but it is definitely tampered with; it has protocol 7 strangely but probably because it was modified from a newer version --><br />
|-<br />
| c0.0.23a_01<br />
| 6<br />
|<br />
|-<br />
| c0.0.23a<br />
| {{Unknown|Unknown (6?)}}<br />
|<br />
|-<br />
| c0.0.22a_05<br />
| 6<br />
|<br />
|-<br />
| c0.0.22a_04<br />
|rowspan="6" {{Unknown|Unknown (6?)}}<br />
|rowspan="6"|<br />
|-<br />
| c0.0.22a_03<br />
|-<br />
| c0.0.22a_02<br />
|-<br />
| c0.0.22a_01<br />
|-<br />
| c0.0.22a<br />
|-<br />
| c0.0.21a_01<br />
|-<br />
| c0.0.21a<br />
| 6<br />
|<br />
|-<br />
| c0.0.20a_02<br />
| {{Unknown}} (6?)<br />
|rowspan="16" |<br />
|-<br />
| c0.0.20a_01<br />
| 6<br />
|-<br />
| c0.0.20a<br />
|rowspan="14" {{Unknown}}<br />
|-<br />
| c0.0.19a_06<br />
|-<br />
| c0.0.19a_05<br />
|-<br />
| c0.0.19a_04<br />
|-<br />
| c0.0.19a_03<br />
|-<br />
| c0.0.19a_02<br />
|-<br />
| c0.0.19a_01<br />
|-<br />
| c0.0.19a<br />
|-<br />
| c0.0.18a_02<br />
|-<br />
| c0.0.18a_01<br />
|-<br />
| c0.0.18a<br />
|-<br />
| c0.0.17a_02<br />
|-<br />
| c0.0.17a_01<br />
|-<br />
| c0.0.17a<br />
|-<br />
| c0.0.16a_02<br />
| 3<br />
|<br />
|-<br />
| c0.0.16a_01<br />
| rowspan="4" {{Unknown}}<br />
| rowspan="4" |<br />
|-<br />
| c0.0.16a<br />
|-<br />
| c0.0.15a-3<br />
|-<br />
| c0.0.15a-2<br />
|-<br />
| c0.0.15a-1<br />
| None<ref group="old note">The Player Identification packet is only a single string, and does not include a version number.</ref><br />
|<br />
|-<br />
| c0.0.14a_08<br />
| rowspan="23" {{No|Multiplayer did not exist at this time}}<br />
| rowspan="23" |<br />
|-<br />
| c0.0.14a_07<br />
|-<br />
| c0.0.14a_06<br />
|-<br />
| c0.0.14a_05<br />
|-<br />
| c0.0.14a_04<br />
|-<br />
| c0.0.14a_03<br />
|-<br />
| c0.0.14a_02<br />
|-<br />
| c0.0.14a_01<br />
|-<br />
| c0.0.14a<br />
|-<br />
| c0.0.13a_04<br />
|-<br />
| c0.0.13a_03<br />
|-<br />
| c0.0.13a_02<br />
|-<br />
| c0.0.13a_01<br />
|-<br />
| c0.0.13a<br />
|-<br />
| c0.0.12a_03<br />
|-<br />
| c0.0.12a_02<br />
|-<br />
| c0.0.12a_01<br />
|-<br />
| c0.0.12a<br />
|-<br />
| c0.0.11a<br />
|-<br />
| c0.0.10a<br />
|-<br />
| c0.0.9a<br />
|-<br />
| c0.0.3a<br />
|-<br />
| c0.0.2a<br />
|}<br />
<br />
=== Notes ===<br />
<br />
<references group="old note" /><br />
<br />
[[Category:Minecraft Modern]]</div>Janmm14https://wiki.vg/index.php?title=NBT&diff=16096NBT2020-10-29T20:27:01Z<p>Janmm14: As mojang.com turned into a minecraft.net redirect, use web.archive.org link</p>
<hr />
<div>The Named Binary Tag (NBT) file format is an extremely simple, albeit annoying (did we really need yet ''another'' format?)<sup>[See Discussion]</sup> structured binary format used by the [http://www.minecraft.net Minecraft] game for a variety of things. Due to this, several third-party utilities now also utilize the format. You may find example files at the bottom of this article.<br />
<br />
Mojang has also released a reference implementation along with their Anvil conversion tool, available from https://web.archive.org/web/20190710093131/https://mojang.com/2012/02/new-minecraft-map-format-anvil/<br />
<br />
== Current Uses ==<br />
The NBT format is currently used in several places, chiefly:<br />
* In the [[Protocol]] as part of [[Slot Data]]<br />
* Multiplayer saved server list (<code>servers.dat</code>).<br />
* Player data (both single player and multiplayer, one file per player). This includes such things as inventory and location.<br />
* Saved worlds (both single player and multiplayer).<br />
** World index file (<code>level.dat</code>) that contains general information (spawn point, time of day, etc...)<br />
** Chunk data (see [[Region Files]])<br />
<br />
Unfortunately, the NBT files you can encounter as a developer will be stored in three different ways, just to make things interesting.<br />
* Uncompressed,<br />
* [[wikipedia:Gzip|gzip'd]],<br />
* [[wikipedia:Zlib|zlib'd]] (aka DEFLATE with a few bytes extra)<br />
<br />
=== Libraries ===<br />
<br />
There are many, many libraries for manipulating NBT, written in several languages, and often several per language. For example,<br />
<br />
* [https://github.com/nickelpro/cNBT C],<br />
* [https://github.com/SpockBotMC/cpp-nbt C++20],<br />
* [https://github.com/fragmer/fNbt C#], <br />
* [https://github.com/Dav1dde/nbd D],<br />
* [https://github.com/Tnze/go-mc/tree/master/nbt Go (New)],<br />
* [https://github.com/toqueteos/minero/tree/master/proto/nbt Go (Old, without TagLongArray)],<br />
* [https://github.com/flow/nbt Java (Old, without TagLongArray)],<br />
* [https://github.com/sjmulder/nbt-js Javascript], <br />
* [https://github.com/TheFrozenFire/PHP-NBT-Decoder-Encoder PHP],<br />
* [https://github.com/twoolie/NBT Python],<br />
* [https://github.com/mental/nbtfile Ruby],<br />
* [https://github.com/PistonDevelopers/hematite_nbt Rust],<br />
* [https://github.com/drXor/ScalaNBT Scala],<br />
* [https://gist.github.com/camdenorrb/bec73c5608267f0232bd8f5c42e0784d Kotlin (Streams, ByteBuffer, NIO, Endianness, Zlib, Gzip, Any Input/Output, Examples in Comments)], <br />
* [https://github.com/MrPNG/KotlinNBT Kotlin (with a builder DSL and type-safety)],<br />
* [https://github.com/DevSrSouza/KotlinNBT Kotlin Multiplatform], <br />
* You get the idea…<br />
<br />
Unless you have specific goals or licence requirements, it is ''extremely recommended'' to go with one of the existing libraries.<br />
<br />
=== Utilities ===<br />
Almost every 3rd-party Minecraft application uses NBT on some level. There also exist several dedicated NBT editors, which will likely be useful to you if you are developing an NBT library of your own. These include:<br />
* [https://www.minecraftforum.net/forums/mapping-and-modding-java-edition/minecraft-tools/1262665-nbtexplorer-nbt-editor-for-windows-and-mac NBTExplorer] (C#) NBT Directory-tree interface that fully supports the Minecraft .mcr/.mca region files.<br />
* [https://web.archive.org/web/20180428090808/http://gerritg.de/wp/archives/152 NEINedit] (Obj-C), an OS X specific editor.<br />
* [https://bitbucket.org/zzzeek/nbt2yaml nbt2yaml] (Python), provides command-line editing of NBT via the YAML format, as well as a fast and minimalist NBT parsing/rendering API.<br />
* [https://github.com/C4K3/nbted nbted] (Rust; CC0), provides command-line editing of NBT files via your $EDITOR<br />
* [https://github.com/midnightfreddie/nbt2json nbt2json] (Golang; MIT) Command-line utility for NBT to JSON/YAML conversion and back. MCPE-NBT support. Can be used as library.<br />
<br />
== Specification ==<br />
The NBT file format is extremely simple, and writing a library capable of reading/writing it is a simple affair. There are 13 datatypes supported by this format, one of which is used to close compound tags. It is strongly advised to read this entire section or you may run into issues.<br />
<br />
<br />
{| class="wikitable"<br />
|-<br />
! Type ID<br />
! Type Name<br />
! Payload Size (Bytes)<br />
! Description<br />
|-<br />
| 0 <br />
| TAG_End <br />
| 0 <br />
| Signifies the end of a TAG_Compound. It is only ever used inside a TAG_Compound, and is not named despite being in a TAG_Compound<br />
|-<br />
| 1<br />
| TAG_Byte<br />
| 1<br />
| A single signed byte<br />
|-<br />
| 2<br />
| TAG_Short<br />
| 2<br />
| A single signed, big endian 16 bit integer<br />
|-<br />
| 3<br />
| TAG_Int<br />
| 4<br />
| A single signed, big endian 32 bit integer<br />
|-<br />
| 4<br />
| TAG_Long<br />
| 8<br />
| A single signed, big endian 64 bit integer<br />
|-<br />
| 5<br />
| TAG_Float<br />
| 4<br />
| A single, big endian [[wikipedia:IEEE 754-2008|IEEE-754]] single-precision floating point number ([[wikipedia:NaN|NaN]] possible)<br />
|-<br />
| 6<br />
| TAG_Double<br />
| 8<br />
| A single, big endian [[wikipedia:IEEE 754-2008|IEEE-754]] double-precision floating point number (NaN possible)<br />
|-<br />
| 7<br />
| TAG_Byte_Array<br />
| ...<br />
| A length-prefixed array of '''signed''' bytes. The prefix is a '''signed''' integer (thus 4 bytes)<br />
|-<br />
| 8<br />
| TAG_String<br />
| ...<br />
| A length-prefixed [https://docs.oracle.com/javase/8/docs/api/java/io/DataInput.html#modified-utf-8 modified UTF-8] string. The prefix is an '''unsigned''' short (thus 2 bytes) signifying the length of the string in bytes<br />
|-<br />
| 9<br />
| TAG_List<br />
| ...<br />
| A list of '''nameless''' tags, all of the same type. The list is prefixed with the <code>Type ID</code> of the items it contains (thus 1 byte), and the length of the list as a '''signed''' integer (a further 4 bytes). If the length of the list is 0 or negative, the type may be 0 (TAG_End) but otherwise it must be any other type. (The notchian implementation uses TAG_End in that situation, but another reference implementation by Mojang uses 1 instead; parsers should accept any type if the length is <= 0).<br />
|-<br />
| 10<br />
| TAG_Compound<br />
| ...<br />
| Effectively a list of a '''named''' tags. Order is not guaranteed.<br />
|-<br />
| 11<br />
| TAG_Int_Array<br />
| ...<br />
| A length-prefixed array of '''signed''' integers. The prefix is a '''signed''' integer (thus 4 bytes) and indicates the number of 4 byte integers.<br />
|-<br />
| 12<br />
| TAG_Long_Array<br />
| ...<br />
| A length-prefixed array of '''signed''' longs. The prefix is a '''signed''' integer (thus 4 bytes) and indicates the number of 8 byte longs.<br />
|}<br />
<br />
There are a couple of simple things to remember:<br />
* The datatypes representing numbers are in big-endian in Java edition, but Bedrock edition changes things up a bit. See the below section on Bedrock edition<br />
* Every NBT file will '''always''' implicitly be inside a tag compound, and also begin with a TAG_Compound (except in Bedrock edition, see below)<br />
* The structure of a NBT file is defined by the TAG_List and TAG_Compound types, as such a tag itself will only contain the payload, but depending on what the tag is contained within may contain additional headers. I.e. if it's inside a Compound, then each tag will begin with the TAG_id, and then a string (the tag's name), and finally the payload. While in a list it will be only the payload, as there is no name and the tag type is given in the beginning of the list.<br />
<br />
For example, here's the example layout of a <code>TAG_Short</code> on disk:<br />
<br />
{| class="wikitable"<br />
|-<br />
| <br />
! Type ID<br />
! Length of Name<br />
! Name<br />
! Payload<br />
|-<br />
! Decoded<br />
| 2<br />
| 9<br />
| <code>shortTest</code><br />
| <code>32767</code><br />
|-<br />
! On Disk (in hex)<br />
| <code>02</code><br />
| <code>00 09</code><br />
| <code>73 68 6F 72 74 54 65 73 74</code><br />
| <code>7F FF</code><br />
|}<br />
<br />
If this <code>TAG_Short</code> had been in a <code>TAG_List</code>, it would have been nothing more than the payload, since the type is implied and tags within the first level of a list are nameless.<br />
<br />
=== Bedrock edition ===<br />
Bedrock edition makes a couple of significant changes to the NBT format. First of all, first tag in an NBT file can sometimes be a TAG_List instead of a TAG_Compound. Additionally, NBT data is encoded in one of two different formats, a little-endian version intended for writing to disk, and a VarInt version intended for transport over the network.<br />
<br />
==== Little-endian ====<br />
Identical to the big-endian format used by Java edition, but all numbers are encoded in little-endian. This includes the 16-bit length prefix before tag names and TAG_String values, as well as TAG_Float and TAG_Double values.<br />
<br />
==== VarInt ====<br />
This format is a bit more complex than the others. The differences from Java edition's big-endian format are as follows:<br />
* TAG_Short, TAG_Float and TAG_Double values are encoded as their little-endian counterparts<br />
* TAG_Int values and the length prefixes for TAG_List, TAG_Byte_Array, TAG_Int_Array and TAG_Long_Array are encoded as [https://developers.google.com/protocol-buffers/docs/encoding#varints VarInts with ZigZag encoding]<br />
* TAG_Long values are encoded as [https://developers.google.com/protocol-buffers/docs/encoding#varints VarLongs with ZigZag encoding]<br />
* All strings (Tag names and TAG_String values) are length-prefixed with a normal [https://wiki.vg/Protocol#VarInt_and_VarLong VarInt]<br />
<br />
=== Examples ===<br />
There are two defacto example files used for testing your implementation (<code>test.nbt</code> & <code>bigtest.nbt</code>), originally provided by Markus. The example output provided below was generated using [https://github.com/TkTech/PyNBT PyNBT]'s ''debug-nbt'' tool.<br />
<br />
==== test.nbt ====<br />
This first example is an uncompressed [[wikipedia:Hello world program|"Hello World"]] NBT example. Should you parse it correctly, you will get a structure similar to the following:<br />
<br />
<pre><br />
TAG_Compound('hello world'): 1 entry<br />
{<br />
TAG_String('name'): 'Bananrama'<br />
}<br />
</pre><br />
<br />
Here is the example explained:<br />
{| class="wikitable"<br />
|-<br />
| (The entire thing is implicitly inside a compound)<br />
! Type ID (first element in the implicit compound)<br />
! Length of name of the root compound<br />
! Name of the root compound<br />
! Type ID of first element in root compound<br />
! Length of name of first element in root<br />
! Name of first element<br />
! Length of string<br />
! String<br />
! Tag end (of root compound)<br />
|-<br />
! Decoded<br />
| Compound<br />
| 11<br />
| ''hello world''<br />
| String<br />
| 4<br />
| ''name''<br />
| 9<br />
| ''Bananrama''<br />
|<br />
|-<br />
! On Disk (in hex)<br />
| <code>0a</code><br />
| <code>00 0b</code><br />
| <code>68 65 6c 6c 6f 20 77 6f 72 6c 64</code><br />
| <code>08</code><br />
| <code>00 04</code><br />
| <code>6e 61 6d 65</code><br />
| <code>00 09</code><br />
| <code>42 61 6e 61 6e 72 61 6d 61</code><br />
| <code>00</code><br />
|}<br />
<br />
==== bigtest.nbt ====<br />
This second example is a gzip compressed test of every available tag. If your program can successfully parse this file, then you've done well. Note that the tags under ''TAG_List'' do not have a name, as mentioned above. <br />
<pre><br />
TAG_Compound('Level'): 11 entries<br />
{<br />
TAG_Compound('nested compound test'): 2 entries<br />
{<br />
TAG_Compound('egg'): 2 entries<br />
{<br />
TAG_String('name'): 'Eggbert'<br />
TAG_Float('value'): 0.5<br />
}<br />
TAG_Compound('ham'): 2 entries<br />
{<br />
TAG_String('name'): 'Hampus'<br />
TAG_Float('value'): 0.75<br />
}<br />
}<br />
TAG_Int('intTest'): 2147483647<br />
TAG_Byte('byteTest'): 127<br />
TAG_String('stringTest'): 'HELLO WORLD THIS IS A TEST STRING \xc3\x85\xc3\x84\xc3\x96!'<br />
TAG_List('listTest (long)'): 5 entries<br />
{<br />
TAG_Long(None): 11<br />
TAG_Long(None): 12<br />
TAG_Long(None): 13<br />
TAG_Long(None): 14<br />
TAG_Long(None): 15<br />
}<br />
TAG_Double('doubleTest'): 0.49312871321823148<br />
TAG_Float('floatTest'): 0.49823147058486938<br />
TAG_Long('longTest'): 9223372036854775807L<br />
TAG_List('listTest (compound)'): 2 entries<br />
{<br />
TAG_Compound(None): 2 entries<br />
{<br />
TAG_Long('created-on'): 1264099775885L<br />
TAG_String('name'): 'Compound tag #0'<br />
}<br />
TAG_Compound(None): 2 entries<br />
{<br />
TAG_Long('created-on'): 1264099775885L<br />
TAG_String('name'): 'Compound tag #1'<br />
}<br />
}<br />
TAG_Byte_Array('byteArrayTest (the first 1000 values of (n*n*255+n*7)%100, starting with n=0 (0, 62, 34, 16, 8, ...))'): [1000 bytes]<br />
TAG_Short('shortTest'): 32767<br />
}<br />
</pre><br />
<br />
==== servers.dat ====<br />
The ''servers.dat'' file contains a list of multiplayer servers you've added to the game. To mix things up a bit, this file will always be uncompressed. Below is an example of the structure seen in ''servers.dat''.<br />
<pre><br />
TAG_Compound(<nowiki>''</nowiki>): 1 entry<br />
{<br />
TAG_List('servers'): 2 entries<br />
{<br />
TAG_Compound(None): 3 entries<br />
{<br />
TAG_Byte('acceptTextures'): 1 (Automatically accept resourcepacks from this server)<br />
TAG_String('ip'): '199.167.132.229:25620'<br />
TAG_String('name'): 'Dainz1 - Creative'<br />
<br />
}<br />
TAG_Compound(None): 3 entries<br />
{<br />
TAG_String('icon'): 'iVBORw0KGgoAAAANUhEUgAAAEAAAABACA...' (The base64-encoded server icon. Trimmed here for the example's sake)<br />
TAG_String('ip'): '76.127.122.65:25565'<br />
TAG_String('name'): 'minstarmin4'<br />
<br />
}<br />
}<br />
}<br />
</pre><br />
<br />
==== level.dat ====<br />
This final example is of a single player ''level.dat'', which is compressed using gzip. Notice the player's inventory and general world details such as spawn position, world name, and the game seed.<br />
<pre><br />
TAG_Compound(<nowiki>''</nowiki>): 1 entry<br />
{<br />
TAG_Compound('Data'): 17 entries<br />
{<br />
TAG_Byte('raining'): 0<br />
TAG_Long('RandomSeed'): 3142388825013346304L<br />
TAG_Int('SpawnX'): 0<br />
TAG_Int('SpawnZ'): 0<br />
TAG_Long('LastPlayed'): 1323133681772L<br />
TAG_Int('GameType'): 1<br />
TAG_Int('SpawnY'): 63<br />
TAG_Byte('MapFeatures'): 1<br />
TAG_Compound('Player'): 24 entries<br />
{<br />
TAG_Int('XpTotal'): 0<br />
TAG_Compound('abilities'): 4 entries<br />
{<br />
TAG_Byte('instabuild'): 1<br />
TAG_Byte('flying'): 1<br />
TAG_Byte('mayfly'): 1<br />
TAG_Byte('invulnerable'): 1<br />
}<br />
TAG_Int('XpLevel'): 0<br />
TAG_Int('Score'): 0<br />
TAG_Short('Health'): 20<br />
TAG_List('Inventory'): 13 entries<br />
{<br />
TAG_Compound(None): 4 entries<br />
{<br />
TAG_Byte('Count'): 1<br />
TAG_Byte('Slot'): 0<br />
TAG_Short('id'): 24<br />
TAG_Short('Damage'): 0<br />
}<br />
TAG_Compound(None): 4 entries<br />
{<br />
TAG_Byte('Count'): 1<br />
TAG_Byte('Slot'): 1<br />
TAG_Short('id'): 25<br />
TAG_Short('Damage'): 0<br />
}<br />
TAG_Compound(None): 4 entries<br />
{<br />
TAG_Byte('Count'): 1<br />
TAG_Byte('Slot'): 2<br />
TAG_Short('id'): 326<br />
TAG_Short('Damage'): 0<br />
}<br />
TAG_Compound(None): 4 entries<br />
{<br />
TAG_Byte('Count'): 1<br />
TAG_Byte('Slot'): 3<br />
TAG_Short('id'): 29<br />
TAG_Short('Damage'): 0<br />
}<br />
TAG_Compound(None): 4 entries<br />
{<br />
TAG_Byte('Count'): 10<br />
TAG_Byte('Slot'): 4<br />
TAG_Short('id'): 69<br />
TAG_Short('Damage'): 0<br />
}<br />
TAG_Compound(None): 4 entries<br />
{<br />
TAG_Byte('Count'): 3<br />
TAG_Byte('Slot'): 5<br />
TAG_Short('id'): 33<br />
TAG_Short('Damage'): 0<br />
}<br />
TAG_Compound(None): 4 entries<br />
{<br />
TAG_Byte('Count'): 43<br />
TAG_Byte('Slot'): 6<br />
TAG_Short('id'): 356<br />
TAG_Short('Damage'): 0<br />
}<br />
TAG_Compound(None): 4 entries<br />
{<br />
TAG_Byte('Count'): 64<br />
TAG_Byte('Slot'): 7<br />
TAG_Short('id'): 331<br />
TAG_Short('Damage'): 0<br />
}<br />
TAG_Compound(None): 4 entries<br />
{<br />
TAG_Byte('Count'): 20<br />
TAG_Byte('Slot'): 8<br />
TAG_Short('id'): 76<br />
TAG_Short('Damage'): 0<br />
}<br />
TAG_Compound(None): 4 entries<br />
{<br />
TAG_Byte('Count'): 64<br />
TAG_Byte('Slot'): 9<br />
TAG_Short('id'): 331<br />
TAG_Short('Damage'): 0<br />
}<br />
TAG_Compound(None): 4 entries<br />
{<br />
TAG_Byte('Count'): 1<br />
TAG_Byte('Slot'): 10<br />
TAG_Short('id'): 323<br />
TAG_Short('Damage'): 0<br />
}<br />
TAG_Compound(None): 4 entries<br />
{<br />
TAG_Byte('Count'): 16<br />
TAG_Byte('Slot'): 11<br />
TAG_Short('id'): 331<br />
TAG_Short('Damage'): 0<br />
}<br />
TAG_Compound(None): 4 entries<br />
{<br />
TAG_Byte('Count'): 1<br />
TAG_Byte('Slot'): 12<br />
TAG_Short('id'): 110<br />
TAG_Short('Damage'): 0<br />
}<br />
}<br />
TAG_Short('HurtTime'): 0<br />
TAG_Short('Fire'): -20<br />
TAG_Float('foodExhaustionLevel'): 0.0<br />
TAG_Float('foodSaturationLevel'): 5.0<br />
TAG_Int('foodTickTimer'): 0<br />
TAG_Short('SleepTimer'): 0<br />
TAG_Short('DeathTime'): 0<br />
TAG_List('Rotation'): 2 entries<br />
{<br />
TAG_Float(None): 1151.9342041015625<br />
TAG_Float(None): 32.249679565429688<br />
}<br />
TAG_Float('XpP'): 0.0<br />
TAG_Float('FallDistance'): 0.0<br />
TAG_Short('Air'): 300<br />
TAG_List('Motion'): 3 entries<br />
{<br />
TAG_Double(None): -2.9778325794951344e-11<br />
TAG_Double(None): -0.078400001525878907<br />
TAG_Double(None): 1.1763942772801152e-11<br />
}<br />
TAG_Int('Dimension'): 0<br />
TAG_Byte('OnGround'): 1<br />
TAG_List('Pos'): 3 entries<br />
{<br />
TAG_Double(None): 256.87499499518492<br />
TAG_Double(None): 112.62000000476837<br />
TAG_Double(None): -34.578128612797634<br />
}<br />
TAG_Byte('Sleeping'): 0<br />
TAG_Short('AttackTime'): 0<br />
TAG_Int('foodLevel'): 20<br />
}<br />
TAG_Int('thunderTime'): 2724<br />
TAG_Int('version'): 19132<br />
TAG_Int('rainTime'): 5476<br />
TAG_Long('Time'): 128763<br />
TAG_Byte('thundering'): 1<br />
TAG_Byte('hardcore'): 0<br />
TAG_Long('SizeOnDisk'): 0<br />
TAG_String('LevelName'): 'Sandstone Test World'<br />
}<br />
}<br />
</pre><br />
<br />
==== Download ====<br />
* [https://raw.github.com/Dav1dde/nbd/master/test/hello_world.nbt test.nbt/hello_world.nbt] (uncompressed),<br />
* [https://raw.github.com/Dav1dde/nbd/master/test/bigtest.nbt bigtest.nbt] (gzip compressed)<br />
* [https://github.com/VADemon/nbd/raw/5de7a3f37569e1ffee11afbc017ae08e2c24523e/test/Player-nan-value.dat NaN-value-double.dat] (compressed, origin version unknown)<br />
* [https://web.archive.org/web/20110723210920/http://www.minecraft.net/docs/NBT.txt NBT.txt] (original NBT specification)<br />
<br />
[[Category:Protocol_Details]]<br />
[[Category:Minecraft_Modern]]<br />
[[Category:File_Formats]]</div>Janmm14https://wiki.vg/index.php?title=Talk:Protocol&diff=15045Talk:Protocol2019-10-16T17:32:03Z<p>Janmm14: /* Click Window */</p>
<hr />
<div>== zlib compress instead of deflate? (0x33) ==<br />
Whilst implementing chunk creation server side in PHP I've found deflate does not work, however the zlib compressed format does. Can anyone else confirm this? --[[User:ody|ody]]<br />
<br />
I can confirm it uses zlib. I'm using the Ionic Zlib library. Using deflate makes the Minecraft client show the error "Bad compressed data format." [[User:DotMaiku|dotMaiku]] 10:13, 23 October 2011 (MST)<br />
<br />
Just strip the first 2 chars... then it works (Java deflate issue) --[[User:Shoghicp|Shoghicp]] 14:21, 12 December 2011 (MST)<br />
<br />
== Too Large? ==<br />
MediaWiki gave me a warning about this page being too large for some browsers. Perhaps it should be split in half? --[[User:SpaceManiac|SpaceManiac]] 00:44, 6 November 2010 (EDT)<br />
<br />
Don't hit Edit for the entire page :P -- [[User:Jailout2000|<span style="color: #0080C0; font-weight: bold;">Jailout2000</span>]] 04:48, 2 January 2012 (MST)<br />
<br />
== Player Position (0x0B) really absolute position? ==<br />
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. [[User:Yen|Yen]]<br />
<br />
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. [[User:ReDucTor|ReDucTor]]<br />
<br />
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. --[[User:Thejoshwolfe|Thejoshwolfe]] 22:55, 25 January 2011 (MST)<br />
<br />
== New Server Packet 0x1c ==<br />
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. [[User:Jorgon3d|Jorgon3d]] 20:34, 10 November 2010 (EST)<br />
<br />
== New Client Packet 0x15 ==<br />
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". [[User:Jorgon3d|Jorgon3d]] 20:34, 10 November 2010 (EST)<br />
<br />
== Version 4 ==<br />
<br />
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 irc.esper.net / #mcc to discuss this new protocol. [[User:ReDucTor|ReDucTor]]<br />
<br />
== C->S Block change with direction=-1 ==<br />
<br />
(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? [[User:ReDucTor|ReDucTor]]<br />
<br />
== New packets introduced in SMP Health update ==<br />
<br />
Looking at the new server JAR I've seen three new packets. IDs are 0x08(<byte>), 0x09(), and 0x26(<int>,<byte>).<br />
<br />
0x08 I'm thinking could be the players health update packet, 0x26 perhaps the 'hit entity' packet, 0x09 I'm not sure.<br />
<br />
I'll confirm what these packets do tonight when I get back from work.<br />
<br />
: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. [[User:Blixt|Blixt]] 08:17, 24 November 2010 (EST)<br />
<br />
: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. [[User:Blixt|Blixt]] 10:01, 24 November 2010 (EST)<br />
<br />
: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. [[User:Blixt|Blixt]] 10:14, 24 November 2010 (EST)<br />
<br />
: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). [[User:benmanns|benmanns]] 10:24, 24 November 2010 (EST)<br />
<br />
::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. [[User:Blixt|Blixt]] 10:59, 24 November 2010 (EST)<br />
<br />
: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 (http://github.com/blixt/pyminecraft) is working fine now, but there seems to be a few bugs relating to burning mobs... don't know why. [[User:Blixt|Blixt]] 10:59, 24 November 2010 (EST)<br />
<br />
::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. :) [[User:Blixt|Blixt]] 14:15, 24 November 2010 (EST)<br />
<br />
== Complex entity packet (0x3B) client->server ==<br />
<br />
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. [[User:Blixt|Blixt]] 11:37, 29 November 2010 (EST)<br />
<br />
== Nov 30 update ==<br />
<br />
Today's update seems to change the following:<br />
<br />
* 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.<br />
* 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.<br />
* There are a lot of new values for packet 0x12 (animate), such as 104 for crouching, 105 for standing up.<br />
<br />
- [[User:Blixt|Blixt]] 17:58, 30 November 2010 (EST)<br />
<br />
: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. – [[User:Blixt|Blixt]] 05:12, 1 December 2010 (EST)<br />
<br />
: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. – [[User:Blixt|Blixt]] 18:04, 1 December 2010 (EST)<br />
<br />
== Map chunks vs. mini chunks ==<br />
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.<br />
<br />
"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<br />
<br />
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.<br />
<br />
== Currently unlisted packets. ==<br />
<br />
Some packets are listed as only going in one direction, but are actually sent the other too. To my knowledge, these are:<br />
<br />
*S->C 0x0a<br />
*S->C 0x0b<br />
*C->S 0x3b (mentioned [[Talk:Protocol#Complex_entity_packet_.280x3B.29_client-.3Eserver|above]])<br />
<br />
The packets are identical to their counterparts. [[User:Barneygale|Barneygale]] 17:02, 15 December 2010 (EST)<br />
<br />
<br />
Were you connecting to a standard server? I've only received 0xa and 0xb from unofficial servers.<br />
--[[User:Axus|Axus]] 13:21, 16 December 2010 (EST)<br />
<br />
== beta update December 20, 2010 ==<br />
<br />
Someone pasted some notes about the protocol changes here:<br />
http://pastebin.com/YfR9XgC2<br />
<br />
Question: Does 0x0D Player Position and Look Client->Server still differ from Server->Client?<br />
<br />
: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: https://github.com/blixt/pyminecraft/commit/af4c9f6b9b2387e429fa425dd5061ef01e03c5aa#diff-1 – [[User:Blixt|Blixt]] 10:30, 21 December 2010 (EST)<br />
<br />
: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. - [[User:Blixt|Blixt]] 19:25, 21 December 2010 (EST)<br />
<br />
::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). - [[User:Blixt|Blixt]] 07:18, 22 December 2010 (EST)<br />
<br />
'''Note!''' As of 1.1, the Transaction packet goes in both direction (previously it was only sent by the server). - [[User:Blixt|Blixt]] 09:56, 22 December 2010 (EST)<br />
<br />
== Why the merge? ==<br />
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. --[[User:SpaceManiac|SpaceManiac]] 13:31, 21 December 2010 (EST)<br />
<br />
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. --[[User:Kev009|kev009]]<br />
<br />
: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. - [[User:Blixt|Blixt]] 19:23, 21 December 2010 (EST)<br />
<br />
== Y/Stance ==<br />
<br />
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.<br />
<br />
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.<br />
<br />
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".<br />
[[User:Moo|Moo]] 10:15, 1 January 2011 (MST)<br />
<br />
<br />
: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. --[[User:Axus|Axus]] 07:16, 3 January 2011 (MST)<br />
<br />
<br />
::"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". [[User:Moo|Moo]] 16:15, 6 January 2011 (MST)<br />
<br />
:I agree with [[User:Axus|Axus]] that "Y" should be the foot position to be consistent with mobs and such. But "Stance" is really the wrong name for the field in the Player Position messages. Like [[User:Moo|Moo]] said, the server calls "stance" the difference between the eyes and feet. The fields in the Player Position messages should be "Y" and "Eye Y". Note that Eye Y is NOT the top of the player's bounding box. Players are 1.74 meters tall, and foot-to-eye distance only goes up to 1.65 meters. Also changing your Eye Y does not make you appear to crouch according to my experiments. --[[User:Thejoshwolfe|Thejoshwolfe]] 04:35, 9 February 2011 (MST)<br />
<br />
== Connection "hash" somewhat misleading? ==<br />
<br />
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:<br />
<br />
public void a(h paramh) {<br />
if (this.e.l) {<br />
this.i = Long.toHexString(d.nextLong());<br />
this.b.a(new h(this.i));<br />
} else {<br />
this.b.a(new h("-"));<br />
}<br />
}<br />
<br />
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? [[User:AnonymousJohn|AnonymousJohn]] 21:21, 9 January 2011 (MST)<br />
<br />
== Beta 1.2 Update ==<br />
<br />
Lots of "interesting" things. <br />
<br />
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 [http://pastebin.com/8fF60ZwQ pastebin]:<br />
<br />
The "metadata" byte is split this way:<br />
*j: First 3 bits, data type<br />
*k: Last 5 bits, data key<br />
<br />
"j" data type:<br />
*0: byte<br />
*1: short<br />
*2: int<br />
*3: float<br />
*4: string (short, bytes)<br />
*5: inventory item (short, byte, short)<br />
<br />
After the "metadata" byte is data of the "data type".<br />
<br />
Example:<br />
*0x00, 0x00, 0x7F:<br />
**j = 0, k = 0. Key = 0, byte value = 0x00.<br />
**End of stream marked by 0x7F.<br />
<br />
*0x00, 0x00, 0x10, 0xFF, 0x7F:<br />
**j = 0, k = 0. Key = 0, byte value = 0x00.<br />
**j = 0, k = 16. Key = 16, byte value = 255.<br />
**End of stream marked by 0x7F.<br />
<br />
== Packet ID datatype explanation ==<br />
<br />
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<br />
whether this is correct, and if so, where it should appear on the page. --[[User:ElectronicsRules|ElectronicsRules]] 04:40, 17 January 2011 (MST)<br />
<br />
OK I added something. --[[User:Axus|Axus]] 05:24, 17 January 2011 (MST)<br />
<br />
== Signed/Unsigned Byte Values ==<br />
<br />
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. --[[User:Thejoshwolfe|Thejoshwolfe]] 20:31, 23 January 2011 (MST)<br />
<br />
== Absolute integer relation to absolute position ==<br />
<br />
The formula is currently stated as:<br />
<br />
absolute_int = (int)(absolute_double / 32.0);<br />
<br />
But in my understanding it should be:<br />
<br />
absolute_int = (int)(absolute_double * 32.0);<br />
<br />
<br />
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 --[[User:Axus|Axus]] 08:44, 30 January 2011 (MST)<br />
<br />
Oops. Good catch. Thanks. --[[User:Thejoshwolfe|Thejoshwolfe]] 16:19, 30 January 2011 (MST)<br />
<br />
== Packet 0xA ==<br />
<br />
I've removed the note about this packet being used for speedhacking detection as it doesn't really make sense considering it is a client-to-server packet. The client is authoritative on movement of the player. Note that the "Player moved wrongly" server console warning is based on movement delta thresholds and not ground/airborne state, which seems to be used exclusively for fall damage application (try forcing the "on ground" state to be True in all c>s player movement packets)<br />
--[[User:Entity|Entity]] 06:05, 5 February 2011 (MST)<br />
<br />
: Forcing 'on ground' state to be True on all c->s movement does indeed eliminate fall damage. However, when 'on ground' is forced True, you cannot ride minecarts - I haven't tested this yet for boats. [[User:Coldelectrons|Coldelectrons]] 09:00, 1 May 2011 (MST)<br />
<br />
== big endian conversion c++ ==<br />
<br />
converting integer types from big endian to little endian and vice versa is rather simple<br />
<br />
when using visual studio this might need some adjusting thou<br />
please make sure you understand this and reimplement it to fit your needs, this is basically just pseudo code that could be compiled with a c++ compiler<br />
<br />
<pre><br />
#include <endian.h><br />
<br />
int32_t toInt(char* somedata)<br />
{<br />
int32_t result = *((int32_t*)somedata);<br />
result = be32toh(result);<br />
return result;<br />
}<br />
<br />
//for doubles and floats you need some more pointer magic (I know it's evil)<br />
<br />
float toFloat(char* somedata)<br />
{<br />
int32_t result = *((int32_t*)somedata);<br />
float* result_pointer = & result;<br />
result = be32toh(result);<br />
return *result_pointer;<br />
}<br />
</pre><br />
--[[User:Ker|Ker]] 14:53, 17 February 2011 (MST)<br />
<br />
== Wolves metadata ==<br />
<br />
I'm handling metadata as explained here http://mc.kev009.com/Protocol#Metadata<br />
When i do ''byte y = x >> 5;'' i keep getting -4 for wolves.<br />
New type of metadata, or is it just my fault? --[[User:Ligustah|Ligustah]] 04:18, 1 April 2011 (MST)<br />
<br />
Not necessarily wrong, X might really be 0xFFC?????, which would make Y look like "-4". Need to be checked of course. --[[User:Axus|Axus]] 08:03, 2 April 2011 (MST)<br />
<br />
I did a little more testing:<br />
https://gist.github.com/900428 I added metadata packets that i received in different situations. --[[User:Ligustah|Ligustah]] 06:35, 3 April 2011 (MST)<br />
<br />
The -4 mentioned earlier was actually my bad. I was using a byte to hold my x while it should have been an unsigned byte. I also updated the paste above and added all indices i observed with this packet. --[[User:Ligustah|Ligustah]] 08:16, 3 April 2011 (MST)<br />
<br />
== Version 11 (Beta 1.5) ==<br />
<br />
Changes I've noticed so far:<br />
<br />
All strings in packets are now 2-byte Big-Endian Unicode. The string length prefix value specifies #of chars not bytes;<br />
<br />
Packet 0x64 appears all different. String remains Modified-UTF. That's a big consistency WTF.<br />
<br />
Packet 0x66 gained a byte between Action and Item ID<br />
<br />
Login 0x01 response from server now appears EID (''int'') followed by 11 bytes (in my case); Looks like ''short,string,long,byte'' and that the second string was dropped. Total packet len 16 + (2 * strSize).<br />
<br />
Weather Event Packet 0x47 (71). (''int, byte, int, int, int'')<br/><br />
So far this packet has only shown itself for a lightning strike. The value of the ''byte'' was then always 1. During all other events (rain start/stop) this packet was nowhere to be seen whether during gameplay or when logging to SMP during a rainstorm. The first ''int'' appears to be an ''Entity ID'' as it always grew with every new strike. Last 3 ''int''s were the X,Y,Z coords respectively of the strike on the ground. It appears to be only S->C --[[User:Xiix|xiix]] 11:19, 20 April 2011 (MST)<br />
<br />
Packet 0x46 was also updated. The packet is the ba class. I grepped for "new ba" and got 3 hits<br />
<br />
The first 2 are in the dg class. These extends the da class which has code that seems to slowly change the raining state. <br />
<code><br />
protected void i()<br />
{<br />
boolean bool = v();<br />
super.i();<br />
<br />
if (bool != v())<br />
if (bool)<br />
this.z.f.a(new ba(2));<br />
else<br />
this.z.f.a(new ba(1));<br />
}<br />
<br />
</code><br />
<br />
The call to v() checks if it is still raining and the call to i() updates the raining counter.<br />
<br />
This basically says that if the rain state changes, send a 0x46 packet.<br />
<br />
1 = begin raining<br />
<br />
2 = end raining<br />
<br />
The next hit is in the du class.<br />
<br />
<code><br />
if (this.e.e.v()) {<br />
localgj.b(new ba(1));<br />
}<br />
</code><br />
<br />
this.e is the MinecraftServer and this.e.e is of type dg. This says that if it is raining, then send a packet with code 1. This method seems to be for logging in.<br />
<br />
The final hit is in the ep class.<br />
<br />
<code><br />
if (localaq2 != null) {<br />
localdc.c(localaq2.a + 0.5F, localaq2.b + 0.1F, localaq2.c + 0.5F, 0.0F, 0.0F);<br />
localdc.a(localaq1);<br />
} else {<br />
localdc.a.b(new ba(0));<br />
}<br />
</code><br />
<br />
The is probably the bed case.<br />
<br />
So, anyway, the possible values would be:<br />
{| class="wikitable"<br />
|-<br />
! Code<br />
! Effect<br />
|-<br />
| 0<br />
| Invalid Bed<br />
|-<br />
| 1<br />
| Begin raining<br />
|-<br />
| 2<br />
| End raining<br />
|}<br />
<br />
Tested and confirmed --[[User:Xiix|xiix]] 15:30, 23 April 2011 (MST)<br />
<br />
The reason byte is a public variable, so it is possible that the code is set from other places. However, since the string array only has 3 values, that suggests that these are the 3 valid values.<br />
<br />
Btw, what is the policy on editing the main protocol page itself?<br />
--[[User:Raphfrk|Raphfrk]] 13:57, 23 April 2011 (MST)<br />
<br />
Mystery packet 0xC8 (200). Follows hitting entities (cows and whatnot) or destroying/placing anything else:<br />
<br />
:* '''bool''' : ''0 entity destroyed; 1 otherwise, even if block is dug out it still exists so maybe that's why this one's always 1'';<br />
:* '''byte''' : ''0 entity/block destroyed; 2 block or item placed'';<br />
:* '''byte''' : ''???'';<br />
:* '''byte''' : ''block/item ID; for entities no clue'';<br />
:* '''byte''' : ''for bool=0 changes depending on what you hold, hit strength maybe'';<br />
<br />
Sent only ''Server''->''Client''.<br />
<br />
--[[User:Xiix|xiix]] 18:20, 19 April 2011 (MST)<br />
<br />
== /* Item data type */ ==<br />
<br />
In my own code, I've simplified things by treating the 3 items (short, optional byte,short) as an Item. It makes my packet format definitions far more readable.<br />
<br />
Any votes in favor of applying the Item definition to the existing page?<br />
<br />
{| class="wikitable"<br />
|- class="row0"<br />
| class="col0" |<br />
! class="col1" | Size<br />
! class="col2" | Range<br />
! class="col3" | Notes<br />
|- class="row1"<br />
! class="col0 centeralign" | Item<br />
| class="col1 centeralign" | 2-5<br />
| class="col2" | N/A<br />
| class="col3" | The structure is (short ItemID, [byte Count, short MetaDamage]). If ItemID == -1, the latter two items are omitted.<br />
|}<br />
-- Coldelectrons<br />
<br />
Would have been fine but 0x05 does not comply with this. Personally I'd rather deal with no rules than rules that have exceptions to them. --[[User:Xiix|xiix]] 09:43, 20 April 2011 (MST)<br />
<br />
== 0x01 Login C->S (Version 11) ==<br />
<br />
'''Since''' I'm a n00b here I won't edit the wiki itself for the fear of being an idiot, but to whoever did: from my own packet analysis the ''''''Client->Server'''''' login 0x01 packet remains unchanged except for the String8->String16 mod. Either Password (or other text) is still possibly sent (now empty) or it has 2 extra (0,0) bytes for whatever reason after username. So the makeup for my money is ''int, string16, string16, long, sbyte''. The length of the packet remains 18 + len of string16's.<br />
<br />
'''Also''', re new String16 thing. Maybe this is common knowledge for java folk, but for us MS/.NET dweebs it is important to know that the new string16 is actually UTF-16BE, as UTF-16 (implies UTF-16LE) decode will render gibberish.<br />
<br />
--[[User:Xiix|xiix]] 09:38, 20 April 2011 (MST)<br />
<br />
Note that it's actually big-endian UCS-2. Treating it as UTF-16 will likely work most of the time, except for crafted packets or otherwise misbehaving peers.<br />
<br />
--[[User:Huin|Huin]] 14:22, 15 May 2011 (MST)<br />
<br />
== /* Byte-packed double? */ ==<br />
<br />
The 3 ints int the weather packet:<br />
Can someone please explain or link to an explanation of how it is you pack a double-precision floating point (8 bytes) number into an int (4 bytes)? Bonus points for why you would want to do it that way?<br />
<br />
I might be wrong but I don't think it is a packed double in a true packing sense. What you do is in this instance is:<br/><br />
: '''double = int / 32.0''' --[[User:Xiix|xiix]] 08:26, 21 April 2011 (MST)<br />
<br />
== 0x32 (pre-chunk) packet optional? ==<br />
<br />
I've tried sending 0x33 packets without 0x32 packets to a 1.5 Beta client on initial connection - the client simply doesn't like it, and just jiggles up and down and the chunks are not visible.<br />
<br />
Sending the same 0x33 packets with 0x32 packets following results in the client falling, but the chunks being completely air-blocks.<br />
<br />
The chunks only appear to load correctly if each 0x33 packet is preceded by the corresponding 0x32 packet (even if not immediately preceding).<br />
<br />
Any other observations on this matter? It appears to me that the 0x32 packet to initialize the chunk is always required, rather than optional as the current text about packet 0x33 might suggest.<br />
<br />
--[[User:Huin|Huin]] 14:19, 15 May 2011 (MST)<br />
<br />
It might only matter on chunks close to the player. I think the "optional" note was more for client writers to allow strange exceptions from Notch's server, than for letting server writers take it easy ;)<br />
--[[User:Axus|Axus]] 16:03, 16 May 2011 (MST)<br />
<br />
Perhaps the times when the notchian server *doesn't* send the 0x32 is when the 0x33 packet is for a subset of the chunk (that is: an already loaded chunk). It would be nice to back this up with evidence of course. --[[User:Huin|Huin]] 14:24, 21 May 2011 (MST)<br />
<br />
== 0x18 - Where does the 'Index' come from? + Metadata String ==<br />
<br />
Can somebody tell me where the index come from? Is this a byte in the metastream or what ?<br />
<br />
Additionally there is no information about the width of the string chars in a metastream.<br />
<br />
--[[User:Chrisliebaer|Chrisliebaer]] 11:39, 22 May 2011 (MST)<br />
<br />
== 0x47 - Weather? ==<br />
<br />
22 May 2011 - Just started writing a library to read and write packets. Tried to follow the spec for 0x47 on the page, and kept getting errors. Looked at a Wireshark capture, and I see the 0x47 packet as being 8 bytes long (9 with the header). The first four bytes look to be an int related to location? It was negative in my capture. The next three bytes were all 0's, then a 0x02. --[[User:Nyasara]]<br />
<br />
== Map data (0x83) ==<br />
<br />
It seems like there is a new packet 0x83 which I can't figure out. Decompiling it reveals four possible forms: http://pastie.org/1975651<br />
--[[User:Sadimusi|Sadimusi]] 04:10, 26 May 2011 (MST)<br />
<br />
I wonder if it handles something related to Nether travel (probably reaching). <br />
<br />
I guess the respawn packet with the new field might be all that was added for handling this. <br />
<br />
Does the Nether have any use for a new world seed? If not, then I guess adding the Nether didn't require that a "change world seed" packet was created. If so, that is pretty disappointing. This would have been a perfect time to add a way to update the client's world seed.<br />
<br />
I am going to run a test tonight to see if the client can handle a second login packet after the update.<br />
<br />
--[[User:Raphfrk|Raphfrk]] 05:12, 26 May 2011 (MST)<br />
<br />
== Block Action? (0x3D) ==<br />
<br />
This packet is<br />
<br />
Int<br />
Int<br />
Byte<br />
Int<br />
Int<br />
<br />
It seems to be related to opening doors<br />
<br />
Int: 1003 (constant)<br />
Int: X position of door<br />
Byte: Y position of door<br />
Int: Z position of door<br />
Int: 0 (constant)<br />
<br />
The packet is sent to all players except the player who opens the door.<br />
--[[User:Raphfrk|Raphfrk]] 11:56, 26 May 2011 (MST)<br />
<br />
It is also sent to all near players when a door is opened with a redstone current.<br />
--[[User:Sadimusi|Sadimusi]] 12:39, 26 May 2011 (MST)<br />
<br />
<br />
:When a player opens a door with right click, the server receives Packet 0xF (block placement, but opens door)<br />
: When a player opens a door with left click, the server receives Packet 0xE+start digging<br />
: 1.7.3<br />
: [[User:Ishinay|Ishinay]] 05:31, 27 August 2011 (MST)<br />
<br />
== Unknown fields in 0x17 may be trajectory. ==<br />
<br />
Especially as there is no other packet to keep track of a ranged weapons trajectory, I deem it likely that the unknown fields encode the trajectory of the projectile.<br />
I haven't done any research into this yet, but I consider two methods of encoding likely:<br />
<br />
If X, Y and Z mark the original start point of the projectile, the last three fields may hold the initial X, Y and Z velocities of the projectile while the integer field encodes the time the projectile has already travelled on that path.<br />
<br />
If X, Y and Z mark the current position of the projectile, the unknown int could instead hold the velocity and the remaining shorts just encode the orientation of the projectile.<br />
<br />
Another, though unlikely option would be to encode the coordinates of the trajectories zenith.<br />
<br />
[[User:SlashLife|SlashLife]] 13:58, 28 May 2011 (MST)<br />
<br />
The fact that these fields were added with the same update the map item was introduced suggests a connection between those two things. Projectiles were added a long time ago and worked without these fields.<br />
--[[User:Sadimusi|Sadimusi]] 16:35, 28 May 2011 (MST)<br />
<br />
<br />
:The "Unknown flag int" actually seems to be the Shooter Entity Id, useful for differenciate the source of the damage. This code exemplifies:<br />
'''<br />
EntityFireball entityfireball = (EntityFireball) this.tracker;<br />
Packet23VehicleSpawn packet23vehiclespawn = new Packet23VehicleSpawn(this.tracker, 63, ((EntityFireball) this.tracker).shooter.id);<br />
'''<br />
:The other 3 int are taken from entity speed, so with much probability marks the initial trayectory tangent as a vector.<br />
'''<br />
double speedX = entity.speedX;<br />
double speedY = entity.speedY;<br />
double speedZ = entity.speedZ;<br />
...<br />
this.trayectoryX = (int) (speedX * 8000.0D);<br />
this.trayectoryY = (int) (speedY * 8000.0D);<br />
this.trayectoryZ = (int) (speedZ * 8000.0D);<br />
'''<br />
[[User:Ishinay|Ishinay]] 05:14, 27 August 2011 (MST)<br />
<br />
== 0x3D packet specs ==<br />
<br />
Packet 0x3D is used to make effects happen on the client.<br />
<br />
Parameters:<br />
int - identifier for effect (client chooses effect using a switch).<br />
int - X<br />
int - Y<br />
int - Z<br />
int - extra data value (used for 3 effects).<br />
<br />
Possible values:<br />
1000 - plays the dispenser fire sound.<br />
1001 - plays the empty dispenser fire sound.<br />
1002 - plays the projectile fire sound (snowball, egg, bow).<br />
1003 - plays the (trap)door open/close sound (50/50 chance of either).<br />
1004 - plays the fire extinguish sound.<br />
1005 - plays a record sound (using the extra data field as an item ID).<br />
2000 - spawns a dispenser fire particle (uses the extra data field for direction, possible 9? values).<br />
2001 - places dig effects on the block at the given location (uses the extra data field as a block ID).<br />
<br />
== 0x6A - Inventory Transaction ==<br />
<br />
The bool in packet 0x6A isn't as simple as 'True if accepted'. I've been playing with inventory logic a bit, and with Notchian client/server, the 'accepted' bool has no immediately discernible rhyme or reason from the server - simply, if a transaction has been accepted, there is a Transaction packet s->c, and if not, not. -- [[User:Coldelectrons|Coldelectrons]] 19:40, 11 June 2011 (MST)<br />
<br />
I tend to agree that its effect is non-obvious. I have noted that sending a "false" for that field results in the client replying with a transaction packet with "true". Beats me what it means :) --[[User:Huin|Huin]] 13:37, 17 June 2011 (MST)<br />
<br />
==== further observations ====<br />
<br />
* When a click leaves an inventory slot empty (picking up a whole stack or item), or when the click changes the amount of the stack in the inventory slot (depositing a single item into a stack), or swapping items, the S->C accepted==False. <br />
<br />
* When a click puts something into an empty slot (a single item or dropping one off of a stack with right-click), the S->C accepted==True<br />
<br />
These two could probably be simplified to "If the slot is empty when it is clicked, S->C accepted=True, else it is False". I haven't observed all conditions in all window types, so some collaboration would be helpful.<br />
<br />
* When the server sends accepted==False, the client will respond with a transaction packet with the same action number, but with accepted==True<br />
<br />
* When the server sends accepted==True, the client does not respond further.<br />
<br />
[[User:Coldelectrons|Coldelectrons]] 15:44, 17 June 2011 (MST)<br />
<br />
== Decimal packet numbers? ==<br />
<br />
Since the Packet classes in the minecraft source (as decompiled by mcp) are named with Decimal numbers it is kind of a hassle when trying to correlate those classes with this list of packets which only have the packet ID shown in hex. Any chance the decimal number could be included in here? In the section heading preferably so it can be seen in the index.<br />
<br />
== Entity Action ??? (0x13) ==<br />
<br />
Seem to be having trouble getting this to work this is sent when someone crouches but it causes a packet error in 1.7.2 was something added? --[[User:Faith2712|Faith2712]] 19:01, 6 July 2011 (MST)<br />
<br />
I believe you have to send the crouch in an entitymetadata packet rather than entityaction (apply the crouch flag to the metadata, then send the edited data).<br />
<br />
: Sneaking is definitely sent with 0x13 as you can see in this (unobscured) snippet from 1.7.3: http://pastie.org/2209271 --[[User:Sadimusi|Sadimusi]] 14:15, 13 July 2011 (MST)<br />
<br />
: : Faith2712 is definitely correct about it being sent from the server as entitymetadata (0x28). Packet 0x13 is client to server only. <br />
: : The byte array for crouching would be: "0x28, [player id(4 bytes)], 0x00, 0x02, 0x7F". 0x02 can be 0x00 (for no animations), 0x01 (for fire), 0x02 (for crouch), 0x03 (for crouch and fire a same time).<br />
: : --[[User:Jasonbay13|Jasonbay13]] 17:01, 11 August 2011 (MST)<br />
<br />
== Piston Direction ==<br />
<br />
Should piston direction 5 not be South? East is in there twice, and south is missed out. I am not certain that it is 5 though, so I have not edited it.<br />
<br />
== Entity Status (0x26) ==<br />
<br />
I've been looking into bukkit stuff today and I think I know what packet 0x26 is! It is sent any time an entity does some animation, especially I noticed with wolves:<br />
HURT (2),<br />
DEATH (3),<br />
SMOKE (6),<br />
HEARTS (7),<br />
WATER (8),<br />
<br />
This is what I've tested out so far. Smoke, Hearts, and water are mainly for wolfie animations. Note that I got these by testing and looking through the minecraft code. That's allowed, right? So far these are the only ones that are sent by the server.<br />
--[[User:Zonedabone|Zonedabone]] 18:08, 12 August 2011 (MST)<br />
<br />
== Yaw diagram needs correcting ==<br />
<br />
While I get the impression from Minecraft's code that ''some'' people *cough* can't tell up from down, left from right, or South from West, we here should be able to.<br />
<br />
The unit circle by the Player Look packet description needs to be changed to reflect what you actually encounter in the game and code.<br />
<br />
I have here a modest example: [[File:Notchian_Coordinate_System.png|200px|thumb|right|Back Arsewards]]<br />
<br />
[[User:Coldelectrons|Coldelectrons]] 14:45, 24 August 2011 (MST)<br />
<br />
== 1.8 Pre-release changes ==<br />
<br />
When refreshing the server list, packet 0xfe is sent. Its length is 1 byte.<br />
The server answers with a Kick(0xff) packet with the motd and player amount in the kick message with the format<br />
<br />
Motd§0§20<br />
<br />
for a server with 0 players, 20 slots, and motd set to Motd.<br />
<br />
--[[User:Zhuowei|Zhuowei]] 17:42, 9 September 2011 (MST)<br />
<br />
: Added, thanks :) [[User:Barneygale|Barneygale]] 23:32, 9 September 2011 (MST)<br />
<br />
== Creative inventory action (0x6B) ==<br />
<br />
Creative inventory action (0x6B) is sent by the client when the user clicks on a quickbar-slot<br />
<br />
== Mob ID for endermen? ==<br />
<br />
I'm pretty sure it's 58, can anyone confirm? [[User:Origamiguy|Origamiguy]] 08:57, 16 September 2011 (MST)<br />
<br />
: Yep, 58. The code:<br />
: addMapping(net.minecraft.src.EntityEnderman.class, "Enderman", 58);<br />
: (the number is the mob ID). --[[User:DuckDuckGo|DuckDuckGo]] 13:50, 29 December 2011 (MST)<br />
<br />
== Add Object/Vehicle correct? ==<br />
<br />
About a week ago, I tried to figure out the last four fields in the [[Protocol#Add_Object.2FVehicle_.280x17.29|Add Object/Vehicle (0x17) packet]]. Can someone check that I got it right? --[[User:Krenair|Krenair]] 08:28, 25 September 2011 (MST)<br />
<br />
== 0x02 (Server to Client), description misunderstunding ==<br />
<br />
The current description is:<br />
"This is the first packet sent when the client connects and is used for Authentication. If the hash is '-', then the client continues without doing name authentication. If the hash is a '+', there is currently no way to send a password in at least version 1.8.1. It should be treated similarly to '+'."<br />
<br />
But the meaning of the sentences is not clear.<br />
* The fact that '+' is used for password authentication is implied by the reader.<br />
* "It should be treated similarly to '+'." Meaning '+' similar to '+'? I guess it was supposed to be "...similarly to '-'."<br />
<br />
Am i correct on the above assumptions?<br />
<br />
== Server poll not working in 1.0? ==<br />
<br />
I've recently converted my software to match up with MC 1.0, but it doesn't seem to be working: it gives me a communication error, as if the packet's contents are incorrect. I'm currently using my 1.8 system, where the 254 packet is received and I immediately respond by sending the 255 Kick packet, with a string, such as MyServer§0§16. Any ideas? Has the protocol changed in this sense since 1.0 was released?<br />
<br />
Fixed: I forgot that my encoder was automatically generating the packet header for packet 254 in response rather than just sending packet 255. It was generating two headers, then the payload, haha. Fixed.<br />
<br />
== More explanations! ==<br />
<br />
I, for one, would be interested to know whether the animation packet is validated in any way by the server. For instance, could you send the eat animation to the server with something other than food in your hand?<br />
--[[User:DuckDuckGo|DuckDuckGo]] 13:47, 29 December 2011 (MST)<br />
:Try it and see --[[User:Barneygale|Barneygale]] 23:07, 29 December 2011 (MST)<br />
<br />
== World height and indexing problem ==<br />
<br />
I was working with [[Realcraft]] earlier tonight, rewriting it and all (I lost the source due to a HDD failure), and I got it working back to the point that it was at when I left it so long ago. I've seemed to have stumbled upon an issue. Only a world height of 128 (Size_Y=127) will work with the indexing (<code>index = y + (z * (Size_Y+1)) + (x * (Size_Y+1) * (Size_Z+1))</code>), any other height and the Minecraft client will show erroneous chunks. Perhaps a new indexing scheme is in order? -- [[User:Jailout2000|<span style="color: #0080C0; font-weight: bold;">Jailout2000</span>]] 04:52, 2 January 2012 (MST)<br />
:Support for different world heights is only partially implemented in the protocol, e.g. the Player Digging packet has Y as a byte, meaning you're constrained to 127. --[[User:Barneygale|Barneygale]] 12:49, 2 January 2012 (MST)<br />
<br />
== 1.1 changes ==<br />
<br />
The protocol version number for 1.1 is 23.<br />
<br />
Also a new string is inserted into the middle of the login packet after the Map Seed field. That increases the size of the packet to 25 plus length of strings.<br />
<br />
== Packet directon changes ==<br />
<br />
Recently there were a lot of packet direction changes from ''Client to Server'' into ''Two-way'' mainly with the Player* packets.<br />
<br />
As far as my proxy implementation goes it has never received those packages from the Notchian server so I will change it back.<br />
<br />
--[[User:Ceiru|Ceiru]] 13:30, 17 March 2012 (MST)<br />
<br />
== Removed the last two "this command is not fully understood" ==<br />
<br />
So if anyone needs to copy-paste it for new packets, here it is:<br />
<br />
<nowiki>[[File:Icon_exclaim.gif|:!:]] This command is not fully understood.</nowiki><br />
<br />
Probably should be a template, but given how advanced our tools are (like burger) and how easy it is to get official explanations from the devs, I doubt anyone will need this again. --[[User:Dx|Dx]] 00:58, 13 June 2012 (MST)<br />
<br />
:This is a relic of when I created this page. My own wiki uses DokuWiki, which provides handy icons like above. Looks like someone downloaded it and re-added it as a media upload when it was copied over. I'd advise not using it again, and instead mention it in the channel and someone will take the time to clarify before ever making a change. [[User:TkTech|TkTech]] 01:54, 13 June 2012 (MST)<br />
<br />
== Strange Packets ==<br />
<br />
At first, everything goes as it says in the documentation. As soon as I send the encrypted login request packet, though, I start getting random packets.<br />
<br />
[http://www.mediafire.com/?kafomz31s8bg1mc Strange Packets]<br />
<br />
Can someone please tell me what I'm doing wrong?<br />
<br />
<br />
:Minecraft uses AES-128-CFB8. Not AES-128-CFB128 (happened to me). Check if this happens<br />
:[[User:Shoghicp|Shoghicp]] ([[User talk:Shoghicp|talk]]) 12:36, 23 November 2012 (MST)<br />
<br />
<br />
OK, after some analysis, I have realized that the problem is in the specification, not my code. It is actually similar to your issue.<br />
<br />
The specs should say that you don't start over counting to 16 when you get a new packet, but rather have to accumulate 16-byte chunks to decrypt (regardless of logical or network packet boundaries).<br />
<br />
:CFB8 means that it has a block size (for encrypt/decrypt) of 1 byte, so you're able to encrypt/decrypt on the fly, and without having to wait for more data. The specifications allow variable block size for CFB, since you only have to xor the generated key with the plaintext.<br />
:[[User:Shoghicp|Shoghicp]] ([[User talk:Shoghicp|talk]]) 05:51, 24 November 2012 (MST)<br />
<br />
Join us on IRC, freenode #mcdevs if you need help<br />
[[User:Md 5|md_5]] ([[User talk:Md 5|talk]]) 05:02, 25 November 2012 (MST)<br />
<br />
== Packet 0x1E description ==<br />
<br />
The description of [[Protocol#Entity (0x1E)|packet 0x1E]] probably needs to be revised. The official server doesn't initialize this packet's class directly anymore, and it can therefore be assumed that this packet doesn't get sent by the official server anymore. The official client should theoretically handle this packet the same as either one of packets 0x1F, 0x20 or 0x21 with additional fields set to 0. [[User:14mRh4X0r|14mRh4X0r]] ([[User talk:14mRh4X0r|talk]]) 18:33, 17 January 2013 (MST)<br />
<br />
== Ambiguity and Typos? ==<br />
<br />
I feel that some of the information on the Protocol page is ambiguous and contains typos<br />
# [[Protocol#Player Digging (0x0E)|Player Digging (0x0E)]] - The field Y states the field type is "byte", which according to [[Data Types]] only ranges from -127 to 127. However, as of 1.4.7 (current version at time of writing) I am able to dig blocks up to 255. Should the field type for field Y be changed to "unsigned byte" similar to [[Protocol#Player Block Placement (0x0F)|Player Block Placement (0x0F)]]?<br />
#* [[Protocol#Use Bed (0x11)|Use Bed (0x11)]] has the same issue described above, and possible others too.<br />
# [[Protocol#Player Position and Look (0x0D)|Player Position and Look (0x0D)]] says that it is ''Two-Way''. However, Player Position (0x0B) and Player Look (0x0C) say only ''Client to Server''. Shouldn't this be changed to ''Client to Server'', or can the server actually send Player Position and Look (0x0D)?<br />
# [[Protocol#Player Look (0x0C)|Player Look (0x0C)]] is unclear. With Entity packets (server to client), there is Entity Look (0x20) and Entity Head Look (0x23), but only a single Look packet for the Player (client to server). How should a server implementing the protocol deal with sending Entity Look and Head Look of other players to clients?<br />
--[[User:Greenegg|Greenegg]] ([[User talk:Greenegg|talk]]) 09:02, 19 February 2013 (MST)<br />
:The server sends 0x0D packets (with reversed Y and Stance) when the player makes an invalid move; Player Look is C->S, Entity Look is S->C. [[User:ZioCrocifisso|ZioCrocifisso]] ([[User talk:ZioCrocifisso|talk]])<br />
<br />
== Why is "float" in 0x08 bold? ==<br />
<br />
Does it mean anything or may be safely removed?<br />
http://wiki.vg/Protocol#0x08<br />
<br />
== Rename category to state ==<br />
<br />
Should we rename the Category column to State? This would make it clearer that the packet type depends on both the packet ID and the current state. —[[User:Fenhl|Fenhl]] 03:32, 21 January 2015 (UTC)<br />
<br />
== String terminator ==<br />
<br />
For strings, I understand that there's a VarInt for the length of the string, and the string itself. This means a null terminator isn't needed to specify the end of the string. Should my code include a null terminator, or should it trim that final character? I'm trying to mirror the behavior of the Notchian client/server. [[User:NickNackGus|NickNackGus]] ([[User talk:NickNackGus|talk]]) 13:22, 25 May 2016 (UTC)<br />
<br />
== What happends if you don't send CPacketConfirmTeleport / what does it do and what are the effects of sending it? (serverbound-related) ==<br />
<br />
I'm just curious.<br />
<br />
== Click Window ==<br />
<br />
The documentation says "Slot" is a short.<br />
So I used PacketContainer#getShorts().read(0), but after some tests I realized that the index 0 was actually "ActionNumber".<br />
To fix it, I changed to PacketContainer#getIntegers().read(1). --RoinujNosde<br />
<br />
: The documentation is about what is delivered in the network stream and not how minecraft is saving the data in the Packet objects, which is what you get when using ProtocolLib. --[[User:Janmm14|Janmm14]] ([[User talk:Janmm14|talk]]) 17:32, 16 October 2019 (UTC)</div>Janmm14https://wiki.vg/index.php?title=Protocol&diff=13155Protocol2017-07-01T13:18:27Z<p>Janmm14: Remove phrase "At least one movement must be sent each tick for the server to correctly update things" since its not true anymore and not done by the vanilla client</p>
<hr />
<div>{{Box<br />
|BORDER = #9999FF<br />
|BACKGROUND = #99CCFF<br />
|WIDTH = 100%<br />
|ICON = <br />
|HEADING = Heads up!<br />
|CONTENT = This article is about the protocol for the latest '''stable''' release of Minecraft '''computer edition''' ([[Protocol version numbers|1.12, protocol 335]]). For the computer edition pre-releases, see [[Pre-release protocol]]. For Pocket Edition, see [[Pocket Edition Protocol Documentation]].<br />
}}<br />
<br />
This page presents a dissection of the current '''[https://minecraft.net/ Minecraft] protocol'''.<br />
<br />
If you're having trouble, check out the [[Protocol FAQ|FAQ]] or ask for help in the IRC channel ([irc://irc.freenode.net/mcdevs #mcdevs on chat.freenode.net]).<br />
<br />
'''Note:''' While you may use the contents of this page without restriction to create servers, clients, bots, etc… you still need to provide attribution to #mcdevs if you copy any of the contents of this page for publication elsewhere.<br />
<br />
The changes between versions may be viewed at [[Protocol History]].<br />
<br />
== Definitions ==<br />
<br />
The Minecraft server accepts connections from TCP clients and communicates with them using ''packets''. A packet is a sequence of bytes sent over the TCP connection. The meaning of a packet depends both on its packet ID and the current state of the connection. The initial state of each connection is [[#Handshaking|Handshaking]], and state is switched using the packets [[#Handshake|Handshake]] ([[#Handshaking|Handshaking]], 0x00, serverbound) and [[#Login Success|Login Success]] ([[#Login|Login]], 0x02, clientbound).<br />
<br />
=== Data types ===<br />
<br />
{{:Data types}} <!-- Transcluded contents of Data types article in here — go to that page if you want to edit it --><br />
<br />
=== Other definitions ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Term<br />
! Definition<br />
|-<br />
| Player<br />
| When used in the singular, Player always refers to the client connected to the server.<br />
|-<br />
| Entity<br />
| Entity refers to any item, player, mob, minecart or boat etc. See {{Minecraft Wiki|Entity|the Minecraft Wiki article}} for a full list.<br />
|-<br />
| EID<br />
| An EID — or Entity ID — is a 4-byte sequence used to identify a specific entity. An entity's EID is unique on the entire server.<br />
|-<br />
| XYZ<br />
| In this document, the axis names are the same as those shown in the debug screen (F3). Y points upwards, X points east, and Z points south.<br />
|-<br />
| Meter<br />
| The meter is Minecraft's base unit of length, equal to the length of a vertex of a solid block. The term “block” may be used to mean “meter” or “cubic meter”.<br />
|-<br />
| Global palette<br />
| A table/dictionary/palette mapping nonnegative integers to block states. The block state IDs can be constructed from {{Minecraft Wiki|Data values|this table}} by multiplying what the Minecraft Wiki calls “block IDs” by 16 and adding the metadata/damage value (or in most programming languages <code>block_id &lt;&lt; 4 <nowiki>|</nowiki> metadata</code>).<br />
|-<br />
| Notchian<br />
| The official implementation of vanilla Minecraft as developed and released by Mojang.<br />
|}<br />
<br />
== Packet format ==<br />
<br />
=== Without compression ===<br />
<br />
{| class="wikitable"<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
| Length<br />
| VarInt<br />
| Length of packet data + length of the packet ID<br />
|-<br />
| Packet ID<br />
| VarInt<br />
| <br />
|-<br />
| Data<br />
| Byte Array<br />
| Depends on the connection state and packet ID, see the sections below<br />
|}<br />
<br />
=== With compression ===<br />
<br />
Once a [[#Set Compression|Set Compression]] packet (with a non-negative threshold) is sent, [[wikipedia:Zlib|zlib]] compression is enabled for all following packets. The format of a packet changes slighty to include the size of the uncompressed packet.<br />
<br />
{| class=wikitable<br />
! Compressed?<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
| No<br />
| Packet Length<br />
| VarInt<br />
| Length of Data Length + compressed length of (Packet ID + Data)<br />
|-<br />
| No<br />
| Data Length<br />
| VarInt<br />
| Length of uncompressed (Packet ID + Data) or 0<br />
|-<br />
|rowspan="2"| Yes<br />
| Packet ID<br />
| Varint<br />
| zlib compressed packet ID (see the sections below)<br />
|-<br />
| Data<br />
| Byte Array<br />
| zlib compressed packet data (see the sections below)<br />
|}<br />
<br />
The length given by the Packet Length field is the number of bytes that remain in that packet, including the Data Length field.<br />
<br />
If Data Length is set to zero, then the packet is uncompressed; otherwise it is the size of the uncompressed packet.<br />
<br />
If compressed, the uncompressed length of (Packet ID + Data) must be equal to or over the threshold set in the packet [[#Set Compression 2|Set Compression]] ([[#Login|Login]], 0x03, clientbound), otherwise the receiving party will disconnect.<br />
<br />
Compression can be disabled by sending the packet [[#Set Compression|Set Compression]] ([[#Login|Login]], 0x03, clientbound) with a negative Threshold, or not sending the Set Compression packet at all.<br />
<br />
== Handshaking ==<br />
<br />
=== Clientbound ===<br />
<br />
There are no clientbound packets in the Handshaking state, since the protocol immediately switches to a different state after the client sends the first packet.<br />
<br />
=== Serverbound ===<br />
<br />
==== Handshake ====<br />
<br />
This causes the server to switch into the target state.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="4"| 0x00<br />
|rowspan="4"| Handshaking<br />
|rowspan="4"| Server<br />
| Protocol Version<br />
| VarInt<br />
| See [[protocol version numbers]] (currently 335 in Minecraft 1.12)<br />
|-<br />
| Server Address<br />
| String (255)<br />
| Hostname or IP, e.g. localhost or 127.0.0.1, that was used to connect. The Notchian server does not use this information.<br />
|- <br />
| Server Port<br />
| Unsigned Short<br />
| Default is 25565. The Notchian server does not use this information.<br />
|-<br />
| Next State<br />
| VarInt Enum<br />
| 1 for [[#Status|status]], 2 for [[#Login|login]]<br />
|}<br />
<br />
==== Legacy Server List Ping ====<br />
<br />
{{Warning|This packet uses a nonstandard format. It is never length-prefixed, and the packet ID is an Unsigned Byte instead of a VarInt.}}<br />
<br />
While not technically part of the current protocol, legacy clients may send this packet to initiate [[Server List Ping]], and modern servers should handle it correctly.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
| 0xFE<br />
| Handshaking<br />
| Server<br />
| Payload<br />
| Unsigned Byte<br />
| always 1 (<code>0x01</code>)<br />
|}<br />
<br />
See [[Server List Ping#1.6]] for the details of the protocol that follows this packet.<br />
<br />
== Play ==<br />
<br />
=== Clientbound ===<br />
<br />
==== Spawn Object ====<br />
<br />
Sent by the server when a vehicle or other object is created.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="12"| 0x00<br />
|rowspan="12"| Play<br />
|rowspan="12"| Client<br />
| Entity ID<br />
| VarInt<br />
| EID of the object<br />
|-<br />
| Object UUID<br />
| UUID<br />
| <br />
|-<br />
| Type<br />
| Byte<br />
| The type of object (see [[Entities#Objects]])<br />
|-<br />
| X<br />
| Double<br />
| <br />
|-<br />
| Y<br />
| Double<br />
| <br />
|-<br />
| Z<br />
| Double<br />
| <br />
|-<br />
| Pitch<br />
| Angle<br />
| <br />
|-<br />
| Yaw<br />
| Angle<br />
| <br />
|-<br />
| Data<br />
| Int<br />
| Meaning dependent on the value of the Type field, see [[Object Data]] for details.<br />
|-<br />
| Velocity X<br />
| Short<br />
|rowspan="3"| Same units as [[#Entity Velocity|Entity Velocity]]. Always sent, but only used when Data is greater than 0 (except for some entities which always ignore it; see [[Object Data]] for details).<br />
|-<br />
| Velocity Y<br />
| Short<br />
|-<br />
| Velocity Z<br />
| Short<br />
|}<br />
<br />
==== Spawn Experience Orb ====<br />
<br />
Spawns one or more experience orbs.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="5"| 0x01<br />
|rowspan="5"| Play<br />
|rowspan="5"| Client<br />
| Entity ID<br />
| VarInt<br />
| <br />
|-<br />
| X<br />
| Double<br />
| <br />
|-<br />
| Y<br />
| Double<br />
| <br />
|-<br />
| Z<br />
| Double<br />
| <br />
|-<br />
| Count<br />
| Short<br />
| The amount of experience this orb will reward once collected<br />
|}<br />
<br />
==== Spawn Global Entity ====<br />
<br />
With this packet, the server notifies the client of thunderbolts striking within a 512 block radius around the player. The coordinates specify where exactly the thunderbolt strikes.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="5"| 0x02<br />
|rowspan="5"| Play<br />
|rowspan="5"| Client<br />
| Entity ID<br />
| VarInt<br />
| The EID of the thunderbolt<br />
|-<br />
| Type<br />
| Byte Enum<br />
| The global entity type, currently always 1 for thunderbolt<br />
|-<br />
| X<br />
| Double<br />
| <br />
|-<br />
| Y<br />
| Double<br />
| <br />
|-<br />
| Z<br />
| Double<br />
| <br />
|}<br />
<br />
==== Spawn Mob ====<br />
<br />
Sent by the server when a mob entity is spawned.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="13"| 0x03<br />
|rowspan="13"| Play<br />
|rowspan="13"| Client<br />
| Entity ID<br />
| VarInt<br />
| <br />
|-<br />
| Entity UUID<br />
| UUID<br />
| <br />
|-<br />
| Type<br />
| VarInt<br />
| The type of mob. See [[Entities#Mobs]]<br />
|-<br />
| X<br />
| Double<br />
| <br />
|-<br />
| Y<br />
| Double<br />
| <br />
|-<br />
| Z<br />
| Double<br />
| <br />
|-<br />
| Yaw<br />
| Angle<br />
| <br />
|-<br />
| Pitch<br />
| Angle<br />
| <br />
|-<br />
| Head Pitch<br />
| Angle<br />
| <br />
|-<br />
| Velocity X<br />
| Short<br />
| Same units as [[#Entity Velocity|Entity Velocity]]<br />
|-<br />
| Velocity Y<br />
| Short<br />
| Same units as [[#Entity Velocity|Entity Velocity]]<br />
|-<br />
| Velocity Z<br />
| Short<br />
| Same units as [[#Entity Velocity|Entity Velocity]]<br />
|-<br />
| Metadata<br />
| [[Entities#Entity Metadata Format|Entity Metadata]]<br />
| <br />
|}<br />
<br />
==== Spawn Painting ====<br />
<br />
This packet shows location, name, and type of painting.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="5"| 0x04<br />
|rowspan="5"| Play<br />
|rowspan="5"| Client<br />
| Entity ID<br />
| VarInt<br />
| <br />
|-<br />
| Entity UUID<br />
| UUID<br />
| <br />
|-<br />
| Title<br />
| String (13)<br />
| Name of the painting. Max length 13<br />
|-<br />
| Location<br />
| Position<br />
| Center coordinates (see below)<br />
|-<br />
| Direction<br />
| Byte Enum<br />
| Direction the painting faces (North = 2, South = 0, West = 1, East = 3)<br />
|}<br />
<br />
Calculating the center of an image: given a (width × height) grid of cells, with <code>(0, 0)</code> being the top left corner, the center is <code>(max(0, width / 2 - 1), height / 2)</code>. E.g. <code>(1, 0)</code> for a 2×1 painting, or <code>(1, 2)</code> for a 4×4 painting.<br />
<br />
List of paintings by coordinates in <code>paintings_kristoffer_zetterstrand.png</code> (where x and y are in pixels from the top left and width and height are in pixels or 16ths of a block):<br />
<br />
{| class="wikitable"<br />
! Name<br />
! x<br />
! y<br />
! width<br />
! height<br />
|-<br />
| <code>Kebab</code><br />
| 0<br />
| 0<br />
| 16<br />
| 16<br />
|-<br />
| <code>Aztec</code><br />
| 16<br />
| 0<br />
| 16<br />
| 16<br />
|-<br />
| <code>Alban</code><br />
| 32<br />
| 0<br />
| 16<br />
| 16<br />
|-<br />
| <code>Aztec2</code><br />
| 48<br />
| 0<br />
| 16<br />
| 16<br />
|-<br />
| <code>Bomb</code><br />
| 64<br />
| 0<br />
| 16<br />
| 16<br />
|-<br />
| <code>Plant</code><br />
| 80<br />
| 0<br />
| 16<br />
| 16<br />
|-<br />
| <code>Wasteland</code><br />
| 96<br />
| 0<br />
| 16<br />
| 16<br />
|-<br />
| <code>Pool</code><br />
| 0<br />
| 32<br />
| 32<br />
| 16<br />
|-<br />
| <code>Courbet</code><br />
| 32<br />
| 32<br />
| 32<br />
| 16<br />
|-<br />
| <code>Sea</code><br />
| 64<br />
| 32<br />
| 32<br />
| 16<br />
|-<br />
| <code>Sunset</code><br />
| 96<br />
| 32<br />
| 32<br />
| 16<br />
|-<br />
| <code>Creebet</code><br />
| 128<br />
| 32<br />
| 32<br />
| 16<br />
|-<br />
| <code>Wanderer</code><br />
| 0<br />
| 64<br />
| 16<br />
| 32<br />
|-<br />
| <code>Graham</code><br />
| 16<br />
| 64<br />
| 16<br />
| 32<br />
|-<br />
| <code>Match</code><br />
| 0<br />
| 128<br />
| 32<br />
| 32<br />
|-<br />
| <code>Bust</code><br />
| 32<br />
| 128<br />
| 32<br />
| 32<br />
|-<br />
| <code>Stage</code><br />
| 64<br />
| 128<br />
| 32<br />
| 32<br />
|-<br />
| <code>Void</code><br />
| 96<br />
| 128<br />
| 32<br />
| 32<br />
|-<br />
| <code>SkullAndRoses</code><br />
| 128<br />
| 128<br />
| 32<br />
| 32<br />
|-<br />
| <code>Wither</code><br />
| 160<br />
| 128<br />
| 32<br />
| 32<br />
|-<br />
| <code>Fighters</code><br />
| 0<br />
| 96<br />
| 64<br />
| 32<br />
|-<br />
| <code>Pointer</code><br />
| 0<br />
| 192<br />
| 64<br />
| 64<br />
|-<br />
| <code>Pigscene</code><br />
| 64<br />
| 192<br />
| 64<br />
| 64<br />
|-<br />
| <code>BurningSkull</code><br />
| 128<br />
| 192<br />
| 64<br />
| 64<br />
|-<br />
| <code>Skeleton</code><br />
| 192<br />
| 64<br />
| 64<br />
| 48<br />
|-<br />
| <code>DonkeyKong</code><br />
| 192<br />
| 112<br />
| 64<br />
| 48<br />
|}<br />
<br />
The {{Minecraft Wiki|Painting#Canvases|Minecraft Wiki article on paintings}} also provides a list of painting names to the actual images.<br />
<br />
==== Spawn Player ====<br />
<br />
This packet is sent by the server when a player comes into visible range, ''not'' when a player joins.<br />
<br />
This packet must be sent after the [[#Player List Item|Player List Item]] ([[#Play|Play]], 0x38, clientbound) packet that adds the player data for the client to use when spawning a player. If the Player List Item for the player spawned by this packet is not present when this packet arrives, Notchian clients will not spawn the player entity. The Player List Item packet includes skin/cape data.<br />
<br />
Servers can, however, safely spawn player entities for players not in visible range. The client appears to handle it correctly.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="8"| 0x05<br />
|rowspan="8"| Play<br />
|rowspan="8"| Client<br />
| Entity ID<br />
| VarInt<br />
| Player's EID<br />
|-<br />
| Player UUID<br />
| UUID<br />
| See below for notes on {{Minecraft Wiki|Server.properties#online-mode|offline mode}} and NPCs<br />
|-<br />
| X<br />
| Double<br />
| <br />
|-<br />
| Y<br />
| Double<br />
| <br />
|-<br />
| Z<br />
| Double<br />
| <br />
|-<br />
| Yaw<br />
| Angle<br />
| <br />
|-<br />
| Pitch<br />
| Angle<br />
| <br />
|-<br />
| Metadata<br />
| [[Entities#Entity Metadata Format|Entity Metadata]]<br />
| <br />
|}<br />
<br />
When in {{Minecraft Wiki|Server.properties#online-mode|online mode}}, the UUIDs must be valid and have valid skin blobs.<br />
<br />
In offline mode, [[Wikipedia:Universally unique identifier#Versions 3 and 5 (namespace name-based)|UUID v3]] is used with the String <code>OfflinePlayer:&lt;player name&gt;</code>, encoded in UTF-8 (and case-sensitive).<br />
<br />
For NPCs UUID v2 should be used. Note:<br />
<br />
<+Grum> i will never confirm this as a feature you know that :)<br />
<br />
In an example UUID, <code>xxxxxxxx-xxxx-Yxxx-xxxx-xxxxxxxxxxxx</code>, the UUID version is specified by <code>Y</code>. So, for UUID v3, <code>Y</code> will always be <code>3</code>, and for UUID v2, <code>Y</code> will always be <code>2</code>.<br />
<br />
==== Animation (clientbound) ====<br />
<br />
Sent whenever an entity should change animation.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x06<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Entity ID<br />
| VarInt<br />
| Player ID<br />
|-<br />
| Animation<br />
| Unsigned Byte<br />
| Animation ID (see below)<br />
|}<br />
<br />
Animation can be one of the following values:<br />
<br />
{| class="wikitable"<br />
! ID<br />
! Animation<br />
|-<br />
| 0<br />
| Swing main arm<br />
|-<br />
| 1<br />
| Take damage<br />
|-<br />
| 2<br />
| Leave bed<br />
|-<br />
| 3<br />
| Swing offhand<br />
|-<br />
| 4<br />
| Critical effect<br />
|-<br />
| 5<br />
| Magic critical effect<br />
|}<br />
<br />
==== Statistics ====<br />
<br />
Sent as a response to [[#Client_Status|Client Status 0x04]] (id 1).<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To <br />
!colspan="2"| Field Name<br />
!colspan="2"| Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x07<br />
|rowspan="3"| Play<br />
|rowspan="3"| Client<br />
|colspan="2"| Count<br />
|colspan="2"| VarInt<br />
| Number of elements in the following array<br />
|-<br />
|rowspan="2"| Statistic<br />
| Name<br />
|rowspan="2"| Array<br />
| String (32767)<br />
| [https://gist.github.com/Alvin-LB/8d0d13db00b3c00fd0e822a562025eff https://gist.github.com/Alvin-LB/8d0d13db00b3c00fd0e822a562025eff]<br />
|-<br />
| Value<br />
| VarInt<br />
| The amount to set it to<br />
|}<br />
<br />
==== Block Break Animation ====<br />
<br />
0–9 are the displayable destroy stages and each other number means that there is no animation on this coordinate.<br />
<br />
Block break animations can still be applied on air; the animation will remain visible although there is no block being broken. However, if this is applied to a transparent block, odd graphical effects may happen, including water losing its transparency. (An effect similar to this can be seen in normal gameplay when breaking ice blocks)<br />
<br />
If you need to display several break animations at the same time you have to give each of them a unique Entity ID.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x08<br />
|rowspan="3"| Play<br />
|rowspan="3"| Client<br />
| Entity ID<br />
| VarInt<br />
| Entity ID of the entity breaking the block<br />
|-<br />
| Location<br />
| Position<br />
| Block Position<br />
|-<br />
| Destroy Stage<br />
| Byte<br />
| 0–9 to set it, any other value to remove it<br />
|}<br />
<br />
==== Update Block Entity ====<br />
<br />
Sets tile entity associated with the block at the given location.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x09<br />
|rowspan="3"| Play<br />
|rowspan="3"| Client<br />
| Location<br />
| Position<br />
| <br />
|-<br />
| Action<br />
| Unsigned Byte<br />
| The type of update to perform, see below<br />
|-<br />
| NBT Data<br />
| [[NBT|NBT Tag]]<br />
| Data to set. May be a TAG_END (0), in which case the block entity at the given location is removed (though this is not required since the client will remove the block entity automatically on chunk unload or block removal)<br />
|}<br />
<br />
''Action'' field:<br />
<br />
* '''1''': Set data of a mob spawner (everything except for SpawnPotentials: current delay, min/max delay, mob to be spawned, spawn count, spawn range, etc.)<br />
* '''2''': Set command block text (command and last execution status)<br />
* '''3''': Set the level, primary, and secondary powers of a beacon<br />
* '''4''': Set rotation and skin of mob head<br />
* '''5''': Set type of flower in flower pot<br />
* '''6''': Set base color and patterns on a banner<br />
* '''7''': Set the data for a Structure tile entity<br />
* '''8''': Set the destination for a end gateway<br />
* '''9''': Set the text on a sign<br />
* '''10''': Declare a shulker box, no data appears to be sent and the client seems to do fine without this packet. Perhaps it is a leftover from earlier versions?<br />
* '''11''': Set the color of a bed<br />
<br />
==== Block Action ====<br />
<br />
This packet is used for a number of actions and animations performed by blocks, usually non-persistent.<br />
<br />
See [[Block Actions]] for a list of values.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="4"| 0x0A<br />
|rowspan="4"| Play<br />
|rowspan="4"| Client<br />
| Location<br />
| Position<br />
| Block coordinates<br />
|-<br />
| Action ID (Byte 1)<br />
| Unsigned Byte<br />
| Varies depending on block — see [[Block Actions]]<br />
|-<br />
| Action Param (Byte 2)<br />
| Unsigned Byte<br />
| Varies depending on block — see [[Block Actions]]<br />
|-<br />
| Block Type<br />
| VarInt<br />
| The block type ID for the block, not including metadata/damage value. This must match the block at the given coordinates.<br />
|}<br />
<br />
==== Block Change ====<br />
<br />
Fired whenever a block is changed within the render distance.<br />
<br />
{{Warning2|Changing a block in a chunk that is not loaded is not a stable action. The Notchian client currently uses a ''shared'' empty chunk which is modified for all block changes in unloaded chunks; while in 1.9 this chunk never renders in older versions the changed block will appear in all copies of the empty chunk. Servers should avoid sending block changes in unloaded chunks and clients should ignore such packets.}}<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x0B<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Location<br />
| Position<br />
| Block Coordinates<br />
|-<br />
| Block ID<br />
| VarInt<br />
| The new block state ID for the block as given in the {{Minecraft Wiki|Data values#Block IDs|global palette}} (When reading data: <code>type = id &gt;&gt; 4</code>, <code>meta = id & 15</code>, when writing data: <code>id = type &lt;&lt; 4 &#124; (meta &amp; 15)</code>)<br />
|}<br />
<br />
==== Boss Bar ==== <br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
!colspan="2"| Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="15"| 0x0C<br />
|rowspan="15"| Play<br />
|rowspan="15"| Client<br />
|colspan="2"| UUID<br />
| UUID<br />
| Unique ID for this bar<br />
|-<br />
|colspan="2"| Action<br />
| VarInt Enum<br />
| Determines the layout of the remaining packet<br />
|-<br />
! Action<br />
! Field Name<br />
! <br />
! <br />
|-<br />
|rowspan="5"| 0: add<br />
| Title<br />
| [[Chat]]<br />
| <br />
|-<br />
| Health<br />
| Float<br />
| From 0 to 1. Values greater than 1 do not crash a Notchian client, and start [https://i.johni0702.de/nA.png rendering part of a second health bar] at around 1.5.<br />
|-<br />
| Color<br />
| VarInt Enum<br />
| Color ID (see below)<br />
|-<br />
| Division<br />
| VarInt Enum<br />
| Type of division (see below)<br />
|-<br />
| Flags<br />
| Unsigned Byte<br />
| Bit mask. 0x1: should darken sky, 0x2: is dragon bar (used to play end music)<br />
|-<br />
| 1: remove<br />
| ''no fields''<br />
| ''no fields''<br />
| Removes this boss bar<br />
|-<br />
| 2: update health<br />
| Health<br />
| Float<br />
| as above<br />
|-<br />
| 3: update title<br />
| Title<br />
| [[Chat]]<br />
| <br />
|-<br />
|rowspan="2"| 4: update style<br />
| Color<br />
| VarInt Enum<br />
| Color ID (see below)<br />
|-<br />
| Dividers<br />
| VarInt Enum<br />
| as above<br />
|-<br />
| 5: update flags<br />
| Flags<br />
| Unsigned Byte<br />
| as above<br />
|-<br />
|}<br />
<br />
{| class="wikitable"<br />
! ID<br />
! Color<br />
|-<br />
| 0<br />
| Pink<br />
|-<br />
| 1<br />
| Blue<br />
|-<br />
| 2<br />
| Red<br />
|-<br />
| 3<br />
| Green<br />
|-<br />
| 4<br />
| Yellow<br />
|-<br />
| 5<br />
| Purple<br />
|-<br />
| 6<br />
| White<br />
|}<br />
<br />
{| class="wikitable"<br />
! ID<br />
! Type of division<br />
|-<br />
| 0<br />
| No division<br />
|-<br />
| 1<br />
| 6 notches<br />
|-<br />
| 2<br />
| 10 notches<br />
|-<br />
| 3<br />
| 12 notches<br />
|-<br />
| 4<br />
| 20 notches<br />
|}<br />
<br />
==== Server Difficulty ====<br />
<br />
Changes the difficulty setting in the client's option menu<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x0D<br />
|rowspan="1"| Play<br />
|rowspan="1"| Client<br />
| Difficulty<br />
| Unsigned Byte<br />
| 0: peaceful, 1: easy, 2: normal, 3: hard<br />
|}<br />
<br />
==== Tab-Complete (clientbound) ====<br />
<br />
The server responds with a list of auto-completions of the last word sent to it. In the case of regular chat, this is a player username. Command names and parameters are also supported. The client sorts these alphabetically before listing them.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x0E<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Count<br />
| VarInt<br />
| Number of elements in the following array<br />
|-<br />
| Matches<br />
| Array of String (32767)<br />
| One eligible command, note that each command is sent separately instead of in a single string, hence the need for Count<br />
|}<br />
<br />
==== Chat Message (clientbound) ==== <br />
<br />
Identifying the difference between Chat/System Message is important as it helps respect the user's chat visibility options. While game info accepts json formatting it will not display, old style §-based formatting works. See [[Chat#Processing chat|processing chat]] for more info about these positions.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x0F<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| JSON Data<br />
| [[Chat]]<br />
| Limited to 32767 bytes<br />
|-<br />
| Position<br />
| Byte<br />
| 0: chat (chat box), 1: system message (chat box), 2: game info (above hotbar).<br />
|}<br />
<br />
==== Multi Block Change ====<br />
<br />
Fired whenever 2 or more blocks are changed within the same chunk on the same tick.<br />
<br />
{{Warning|Changing blocks in chunks not loaded by the client is unsafe (see note on [[#Block Change|Block Change]]).}}<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
!colspan="2"| Field Name<br />
!colspan="2"| Field Type<br />
! Notes<br />
|-<br />
|rowspan="6"| 0x10<br />
|rowspan="6"| Play<br />
|rowspan="6"| Client<br />
|colspan="2"| Chunk X<br />
|colspan="2"| Int<br />
| Chunk X coordinate<br />
|-<br />
|colspan="2"| Chunk Z<br />
|colspan="2"| Int<br />
| Chunk Z coordinate<br />
|-<br />
|colspan="2"| Record Count<br />
|colspan="2"| VarInt<br />
| Number of elements in the following array, i.e. the number of blocks affected<br />
|-<br />
|rowspan="3"| Record<br />
| Horizontal Position<br />
|rowspan="3"| Array<br />
| Unsigned Byte<br />
| The 4 most significant bits (<code>0xF0</code>) encode the X coordinate, relative to the chunk. The 4 least significant bits (<code>0x0F</code>) encode the Z coordinate, relative to the chunk.<br />
|-<br />
| Y Coordinate<br />
| Unsigned Byte<br />
| Y coordinate of the block<br />
|-<br />
| Block ID<br />
| VarInt<br />
| The new block state ID for the block as given in the {{Minecraft Wiki|Data values#Block IDs|global palette}} (When reading data: <code>type = id &gt;&gt; 4</code>, <code>meta = id & 15</code>, when writing data: <code>id = type &lt;&lt; 4 &#124; (meta &amp; 15)</code>)<br />
|}<br />
<br />
To decode the position into a world position:<br />
<br />
<syntaxhighlight lang="java"><br />
worldX = (horizPos >> 4 & 15) + (chunkX * 16);<br />
worldY = vertPos;<br />
worldZ = (horizPos & 15) + (chunkZ * 16);<br />
</syntaxhighlight><br />
<br />
==== Confirm Transaction (clientbound) ====<br />
<br />
A packet from the server indicating whether a request from the client was accepted, or whether there was a conflict (due to lag). If the packet was not accepted, the client must respond with a [[#Confirm Transaction (serverbound)|serverbound confirm transaction]] packet.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x11<br />
|rowspan="3"| Play<br />
|rowspan="3"| Client<br />
| Window ID<br />
| Byte<br />
| The ID of the window that the action occurred in<br />
|-<br />
| Action Number<br />
| Short<br />
| Every action that is to be accepted has a unique number. This number is an incrementing integer (starting at 0) with separate counts for each window ID.<br />
|-<br />
| Accepted<br />
| Boolean<br />
| Whether the action was accepted<br />
|}<br />
<br />
==== Close Window (clientbound) ====<br />
<br />
This packet is sent from the server to the client when a window is forcibly closed, such as when a chest is destroyed while it's open.<br />
<br />
Note, notchian clients send a close window packet with Window ID 0 to close their inventory even though there is never an [[#Open Window|Open Window]] packet for inventory. <br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
| 0x12<br />
| Play<br />
| Client<br />
| Window ID<br />
| Unsigned Byte<br />
| This is the ID of the window that was closed. 0 for inventory.<br />
|}<br />
<br />
==== Open Window ====<br />
<br />
This is sent to the client when it should open an inventory, such as a chest, workbench, or furnace. This message is not sent anywhere for clients opening their own inventory.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="5"| 0x13<br />
|rowspan="5"| Play<br />
|rowspan="5"| Client<br />
| Window ID<br />
| Unsigned Byte<br />
| A unique id number for the window to be displayed. Notchian server implementation is a counter, starting at 1.<br />
|-<br />
| Window Type<br />
| String (32)<br />
| The window type to use for display. See [[Inventory]] for a list.<br />
|-<br />
| Window Title<br />
| [[Chat]]<br />
| The title of the window<br />
|-<br />
| Number Of Slots<br />
| Unsigned Byte<br />
| Number of slots in the window (excluding the number of slots in the player inventory)<br />
|-<br />
| Entity ID<br />
| Optional Int<br />
| EntityHorse's EID. Only sent when Window Type is “EntityHorse”<br />
|}<br />
<br />
See [[Inventory]] for further information.<br />
<br />
==== Window Items ====<br />
[[File:Inventory-slots.png|thumb|The inventory slots]]<br />
<br />
Sent by the server when items in multiple slots (in a window) are added/removed. This includes the main inventory, equipped armour and crafting slots.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x14<br />
|rowspan="3"| Play<br />
|rowspan="3"| Client<br />
| Window ID<br />
| Unsigned Byte<br />
| The ID of window which items are being sent for. 0 for player inventory.<br />
|-<br />
| Count<br />
| Short<br />
| Number of elements in the following array<br />
|-<br />
| Slot Data<br />
| Array of [[Slot Data|Slot]]<br />
| <br />
|}<br />
<br />
See [[Inventory#Windows|inventory windows]] for further information about how slots are indexed.<br />
<br />
==== Window Property ====<br />
<br />
This packet is used to inform the client that part of a GUI window should be updated.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x15<br />
|rowspan="3"| Play<br />
|rowspan="3"| Client<br />
| Window ID<br />
| Unsigned Byte<br />
| <br />
|-<br />
| Property<br />
| Short<br />
| The property to be updated, see below<br />
|-<br />
| Value<br />
| Short<br />
| The new value for the property, see below<br />
|}<br />
<br />
The meaning of the Property field depends on the type of the window. The following table shows the known combinations of window type and property, and how the value is to be interpreted.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Window type<br />
! Property<br />
! Value<br />
|-<br />
|rowspan="4"| Furnace<br />
| 0: Fire icon (fuel left)<br />
| counting from fuel burn time down to 0 (in-game ticks)<br />
|-<br />
| 1: Maximum fuel burn time<br />
| fuel burn time or 0 (in-game ticks)<br />
|-<br />
| 2: Progress arrow<br />
| counting from 0 to maximum progress (in-game ticks)<br />
|-<br />
| 3: Maximum progress<br />
| always 200 on the notchian server<br />
|-<br />
|rowspan="10"| Enchantment Table<br />
| 0: Level requirement for top enchantment slot<br />
|rowspan="3"| The enchantment's xp level requirement<br />
|-<br />
| 1: Level requirement for middle enchantment slot<br />
|-<br />
| 2: Level requirement for bottom enchantment slot<br />
|-<br />
| 3: The enchantment seed<br />
| Used for drawing the enchantment names (in [[Wikipedia:Standard Galactic Alphabet|SGA]]) clientside. The same seed ''is'' used to calculate enchantments, but some of the data isn't sent to the client to prevent easily guessing the entire list (the seed value here is the regular seed bitwise and <code>0xFFFFFFF0</code>).<br />
|-<br />
| 4: Enchantment ID shown on mouse hover over top enchantment slot<br />
|rowspan="3"| The enchantment id (set to -1 to hide it)<br />
|-<br />
| 5: Enchantment ID shown on mouse hover over middle enchantment slot<br />
|-<br />
| 6: Enchantment ID shown on mouse hover over bottom enchantment slot<br />
|-<br />
| 7: Enchantment level shown on mouse hover over the top slot<br />
|rowspan="3"| The enchantment level (1 = I, 2 = II, 6 = VI, etc.), or -1 if no enchant<br />
|-<br />
| 8: Enchantment level shown on mouse hover over the middle slot<br />
|-<br />
| 9: Enchantment level shown on mouse hover over the bottom slot<br />
|-<br />
|rowspan="3"| Beacon<br />
| 0: Power level<br />
| 0-4, controls what effect buttons are enabled<br />
|-<br />
| 1: First potion effect<br />
| {{Minecraft Wiki|Data values#Status effects|Potion effect ID}} for the first effect, or -1 if no effect<br />
|-<br />
| 2: Second potion effect<br />
| {{Minecraft Wiki|Data values#Status effects|Potion effect ID}} for the second effect, or -1 if no effect<br />
|-<br />
| Anvil<br />
| 0: Repair cost<br />
| The repair's cost in xp levels<br />
|-<br />
| Brewing Stand<br />
| 0: Brew time<br />
| 0–400, with 400 making the arrow empty, and 0 making the arrow full<br />
|}<br />
<br />
==== Set Slot ====<br />
<br />
Sent by the server when an item in a slot (in a window) is added/removed.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x16<br />
|rowspan="3"| Play<br />
|rowspan="3"| Client<br />
| Window ID<br />
| Byte<br />
| The window which is being updated. 0 for player inventory. Note that all known window types include the player inventory. This packet will only be sent for the currently opened window while the player is performing actions, even if it affects the player inventory. After the window is closed, a number of these packets are sent to update the player's inventory window (0).<br />
|-<br />
| Slot<br />
| Short<br />
| The slot that should be updated<br />
|-<br />
| Slot Data<br />
| [[Slot Data|Slot]]<br />
| <br />
|}<br />
<br />
To set the cursor (the item currently dragged with the mouse), use -1 as Window ID and as Slot.<br />
<br />
This packet can only be used to edit the hotbar of the player's inventory if window ID is set to 0 (slots 36 through 44). If the window ID is set to -2, then any slot in the inventory can be used but no add item animation will be played.<br />
<br />
==== Set Cooldown ====<br />
<br />
Applies a cooldown period to all items with the given type. Used by the Notchian server with enderpearls. This packet should be sent when the cooldown starts and also when the cooldown ends (to compensate for lag), although the client will end the cooldown automatically.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x17<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Item ID<br />
| VarInt<br />
| Numeric ID of the item to apply a cooldown to.<br />
|-<br />
| Cooldown Ticks<br />
| VarInt<br />
| Number of ticks to apply a cooldown for, or 0 to clear the cooldown.<br />
|}<br />
<br />
==== Plugin Message (clientbound) ====<br />
<br />
{{Main|Plugin channels}}<br />
<br />
Mods and plugins can use this to send their data. Minecraft itself uses a number of [[plugin channel]]s. These internal channels are prefixed with <code>MC|</code>.<br />
<br />
More documentation on this: [http://dinnerbone.com/blog/2012/01/13/minecraft-plugin-channels-messaging/ http://dinnerbone.com/blog/2012/01/13/minecraft-plugin-channels-messaging/]<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x18<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Channel<br />
| String (20)<br />
| Name of the [[plugin channel]] used to send the data<br />
|-<br />
| Data<br />
| Byte Array<br />
| Any data, depending on the channel. <code><nowiki>MC|</nowiki></code> channels are documented [[plugin channel|here]]. The length of this array must be inferred from the packet length.<br />
|}<br />
<br />
==== Named Sound Effect ====<br />
{{See also|#Sound Effect}}<br />
<br />
Used to play a sound effect on the client. Custom sounds may be added by resource packs.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="7"| 0x19<br />
|rowspan="7"| Play<br />
|rowspan="7"| Client<br />
| Sound Name<br />
| String (256)<br />
| All sound effect names as of 1.11.0 can be seen [http://pokechu22.github.io/Burger/1.11.html#sounds here].<br />
|-<br />
| Sound Category<br />
| VarInt Enum<br />
| The category that this sound will be played from ([https://gist.github.com/konwboj/7c0c380d3923443e9d55 current categories])<br />
|-<br />
| Effect Position X<br />
| Int<br />
| Effect X multiplied by 8 ([[Data types#Fixed-point numbers|fixed-point number]] with only 3 bits dedicated to the fractional part)<br />
|-<br />
| Effect Position Y<br />
| Int<br />
| Effect Y multiplied by 8 ([[Data types#Fixed-point numbers|fixed-point number]] with only 3 bits dedicated to the fractional part)<br />
|-<br />
| Effect Position Z<br />
| Int<br />
| Effect Z multiplied by 8 ([[Data types#Fixed-point numbers|fixed-point number]] with only 3 bits dedicated to the fractional part)<br />
|-<br />
| Volume<br />
| Float<br />
| 1 is 100%, can be more<br />
|-<br />
| Pitch<br />
| Float<br />
| Float between 0.5 and 2.0 by Notchian clients<br />
|}<br />
<br />
==== Disconnect (play) ====<br />
<br />
Sent by the server before it disconnects a client. The client assumes that the server has already closed the connection by the time the packet arrives.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
| 0x1A<br />
| Play<br />
| Client<br />
| Reason<br />
| [[Chat]]<br />
| Displayed to the client when the connection terminates.<br />
|}<br />
<br />
==== Entity Status ====<br />
<br />
Entity statuses generally trigger an animation for an entity. The available statuses vary by the entity's type (and are available to subclasses of that type as well).<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x1B<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Entity ID<br />
| Int<br />
| <br />
|-<br />
| Entity Status<br />
| Byte Enum<br />
| See below<br />
|}<br />
<br />
See [[entities]] for a list of which statuses are valid for each type of entity.<br />
<br />
==== Explosion ====<br />
<br />
Sent when an explosion occurs (creepers, TNT, and ghast fireballs).<br />
<br />
Each block in Records is set to air. Coordinates for each axis in record is int(X) + record.x<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="9"| 0x1C<br />
|rowspan="9"| Play<br />
|rowspan="9"| Client<br />
| X<br />
| Float<br />
| <br />
|-<br />
| Y<br />
| Float<br />
| <br />
|-<br />
| Z<br />
| Float<br />
| <br />
|-<br />
| Radius<br />
| Float<br />
| Currently unused in the client<br />
|-<br />
| Record Count<br />
| Int<br />
| Number of elements in the following array<br />
|-<br />
| Records<br />
| Array of (Byte, Byte, Byte)<br />
| Each record is 3 signed bytes long, each bytes are the XYZ (respectively) offsets of affected blocks.<br />
|-<br />
| Player Motion X<br />
| Float<br />
| X velocity of the player being pushed by the explosion<br />
|-<br />
| Player Motion Y<br />
| Float<br />
| Y velocity of the player being pushed by the explosion<br />
|-<br />
| Player Motion Z<br />
| Float<br />
| Z velocity of the player being pushed by the explosion<br />
|}<br />
<br />
==== Unload Chunk ====<br />
<br />
Tells the client to unload a chunk column.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x1D<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Chunk X<br />
| Int<br />
| Block coordinate divided by 16, rounded down<br />
|-<br />
| Chunk Z<br />
| Int<br />
| Block coordinate divided by 16, rounded down<br />
|}<br />
<br />
It is legal to send this packet even if the given chunk is not currently loaded.<br />
<br />
==== Change Game State ====<br />
<br />
Used for a wide variety of game state things, from whether to bed use to gamemode to demo messages.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x1E<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Reason<br />
| Unsigned Byte<br />
| See below<br />
|-<br />
| Value<br />
| Float<br />
| Depends on Reason<br />
|}<br />
<br />
''Reason codes'':<br />
<br />
{| class="wikitable"<br />
! Reason<br />
! Effect<br />
! Value<br />
|-<br />
| 0<br />
| Invalid Bed<br />
| Would be used to switch between messages, but the only used message is 0 for invalid bed<br />
|-<br />
| 1<br />
| End raining<br />
| <br />
|-<br />
| 2<br />
| Begin raining<br />
| <br />
|-<br />
| 3<br />
| Change gamemode<br />
| 0: Survival, 1: Creative, 2: Adventure, 3: Spectator<br />
|-<br />
| 4<br />
| Exit end<br />
| 0: Immediately send Client Status of respawn without showing end credits; 1: Show end credits and respawn at the end (or when esc is pressed). 1 is sent if the player has not yet received the "The end?" achievement, while if they do have it 0 is used.<br />
|-<br />
| 5<br />
| Demo message<br />
| 0: Show welcome to demo screen, 101: Tell movement controls, 102: Tell jump control, 103: Tell inventory control<br />
|- <br />
| 6<br />
| Arrow hitting player<br />
| Appears to be played when an arrow strikes another player in Multiplayer<br />
|-<br />
| 7<br />
| Fade value<br />
| The current darkness value. 1 = Dark, 0 = Bright, Setting the value higher causes the game to change color and freeze<br />
|-<br />
| 8<br />
| Fade time<br />
| Time in ticks for the sky to fade<br />
|-<br />
| 10<br />
| Play elder guardian mob appearance (effect and sound)<br />
| <br />
|}<br />
<br />
==== Keep Alive (clientbound) ====<br />
<br />
The server will frequently send out a keep-alive, each containing a random ID. The client must respond with the same packet. If the client does not respond to them for over 30 seconds, the server kicks the client. Vice versa, if the server does not send any keep-alives for 20 seconds, the client will disconnect and yields a "Timed out" exception.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x1F<br />
|rowspan="1"| Play<br />
|rowspan="1"| Client<br />
| Keep Alive ID<br />
| VarInt<br />
| <br />
|}<br />
<br />
==== Chunk Data ====<br />
{{Main|Chunk Format}}<br />
{{See also|#Unload Chunk}}<br />
<br />
The server only sends skylight information for chunk pillars in the {{Minecraft Wiki|Overworld}}, it's up to the client to know in which dimenison the player is currently located. You can also infer this information from the primary bitmask and the amount of uncompressed bytes sent. This packet also sends all block entities in the chunk (though sending them is not required; it is still legal to send them with [[#Update Block Entity|Update Block Entity]] later).<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="9"| 0x20<br />
|rowspan="9"| Play<br />
|rowspan="9"| Client<br />
| Chunk X<br />
| Int<br />
| Chunk coordinate (block coordinate divided by 16, rounded down)<br />
|-<br />
| Chunk Z<br />
| Int<br />
| Chunk coordinate (block coordinate divided by 16, rounded down)<br />
|-<br />
| Ground-Up Continuous<br />
| Boolean<br />
| See [[Chunk Format#Ground-up continuous|Chunk Format]]<br />
|-<br />
| Primary Bit Mask<br />
| VarInt<br />
| Bitmask with bits set to 1 for every 16×16×16 chunk section whose data is included in Data. The least significant bit represents the chunk section at the bottom of the chunk column (from y=0 to y=15).<br />
|- <br />
| Size<br />
| VarInt<br />
| Size of Data in bytes<br />
|-<br />
| Data<br />
| Byte array<br />
| See [[Chunk Format#Data structure|data structure]] in Chunk Format<br />
|-<br />
| Number of block entities<br />
| VarInt<br />
| Length of the following array<br />
|-<br />
| Block entities<br />
| Array of [[NBT|NBT Tag]]<br />
| All block entities in the chunk. Use the x, y, and z tags in the NBT to determine their positions.<br />
|}<br />
<br />
==== Effect ====<br />
<br />
Sent when a client is to play a sound or particle effect.<br />
<br />
By default, the Minecraft client adjusts the volume of sound effects based on distance. The final boolean field is used to disable this, and instead the effect is played from 2 blocks away in the correct direction. Currently this is only used for effect 1023 (wither spawn) and effect 1028 (enderdragon death); it is ignored on other effects.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="4"| 0x21<br />
|rowspan="4"| Play<br />
|rowspan="4"| Client<br />
| Effect ID<br />
| Int<br />
| The ID of the effect, see below<br />
|-<br />
| Location<br />
| Position<br />
| The location of the effect<br />
|-<br />
| Data<br />
| Int<br />
| Extra data for certain effects, see below<br />
|-<br />
| Disable Relative Volume<br />
| Boolean<br />
| See above<br />
|}<br />
<br />
Effect IDs:<br />
<br />
{| class="wikitable"<br />
! ID<br />
! Name<br />
! Data<br />
|-<br />
!colspan="3"| Sound<br />
|-<br />
| 1000<br />
| Dispenser dispenses<br />
| <br />
|-<br />
| 1001<br />
| Dispenser fails to dispense<br />
| <br />
|-<br />
| 1002<br />
| Dispenser shoots<br />
| <br />
|-<br />
| 1003<br />
| Ender eye launched<br />
| <br />
|-<br />
| 1004<br />
| Firework shot<br />
| <br />
|-<br />
| 1005<br />
| Iron door opened<br />
| <br />
|-<br />
| 1006<br />
| Wooden door opened<br />
| <br />
|-<br />
| 1007<br />
| Wooden trapdoor opened<br />
| <br />
|-<br />
| 1008<br />
| Fence gate opened<br />
| <br />
|-<br />
| 1009<br />
| Fire extinguished<br />
| <br />
|-<br />
| 1010<br />
| Play record<br />
| {{Minecraft Wiki|Music Discs|Record ID}}<br />
|-<br />
| 1011<br />
| Iron door closed<br />
| <br />
|-<br />
| 1012<br />
| Wooden door closed<br />
| <br />
|-<br />
| 1013<br />
| Wooden trapdoor closed<br />
| <br />
|-<br />
| 1014<br />
| Fence gate closed<br />
| <br />
|-<br />
| 1015<br />
| Ghast warns<br />
| <br />
|-<br />
| 1016<br />
| Ghast shoots<br />
| <br />
|-<br />
| 1017<br />
| Enderdragon shoots<br />
| <br />
|-<br />
| 1018<br />
| Blaze shoots<br />
| <br />
|-<br />
| 1019<br />
| Zombie attacks wood door<br />
| <br />
|-<br />
| 1020<br />
| Zombie attacks iron door<br />
| <br />
|-<br />
| 1021<br />
| Zombie breaks wood door<br />
|<br />
|-<br />
| 1022<br />
| Wither breaks block<br />
|<br />
|-<br />
| 1023<br />
| Wither spawned<br />
| <br />
|-<br />
| 1024<br />
| Wither shoots<br />
|<br />
|-<br />
| 1025<br />
| Bat takes off<br />
|<br />
|-<br />
| 1026<br />
| Zombie infects<br />
|<br />
|-<br />
| 1027<br />
| Zombie villager converted<br />
|<br />
|-<br />
| 1028<br />
| Ender dragon death<br />
|<br />
|-<br />
| 1029<br />
| Anvil destroyed<br />
| <br />
|-<br />
| 1030<br />
| Anvil used<br />
| <br />
|-<br />
| 1031<br />
| Anvil landed<br />
|<br />
|-<br />
| 1032<br />
| Portal travel<br />
| <br />
|-<br />
| 1033<br />
| Chorus flower grown<br />
|<br />
|-<br />
| 1034<br />
| Chorus flower died<br />
| <br />
|-<br />
| 1035<br />
| Brewing stand brewed<br />
|<br />
|-<br />
| 1036<br />
| Iron trapdoor opened<br />
| <br />
|-<br />
| 1037<br />
| Iron trapdoor closed<br />
|<br />
|-<br />
!colspan="3"| Particle<br />
|-<br />
| 2000<br />
| Spawns 10 smoke particles, e.g. from a fire<br />
| Direction, see below<br />
|-<br />
| 2001<br />
| Block break + block break sound<br />
| {{Minecraft Wiki|Data values|Block ID}}<br />
|-<br />
| 2002/2007<br />
| Splash potion. Particle effect + glass break sound.<br />
| [http://minecraft.gamepedia.com/Data_values#Potions Potion ID]<br />
|-<br />
| 2003<br />
| Eye of Ender entity break animation — particles and sound<br />
| <br />
|-<br />
| 2004<br />
| Mob spawn particle effect: smoke + flames<br />
| <br />
|-<br />
| 2005<br />
| Bonemeal particles<br />
| How many particles to spawn (if set to 0, 15 are spawned)<br />
|-<br />
| 2006<br />
| Dragon breath<br />
|<br />
|-<br />
| 3000<br />
| End gateway spawn<br />
| <br />
|-<br />
| 3001<br />
| Enderdragon growl<br />
|<br />
|}<br />
<br />
Smoke directions:<br />
<br />
{| class="wikitable"<br />
! ID<br />
! Direction<br />
|-<br />
| 0<br />
| South-East<br />
|-<br />
| 1<br />
| South<br />
|-<br />
| 2<br />
| South-West<br />
|-<br />
| 3<br />
| East<br />
|-<br />
| 4<br />
| (Up or middle ?)<br />
|-<br />
| 5<br />
| West<br />
|-<br />
| 6<br />
| North-East<br />
|-<br />
| 7<br />
| North<br />
|-<br />
| 8<br />
| North-West<br />
|}<br />
<br />
==== Particle ====<br />
<br />
Displays the named particle<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="11"| 0x22<br />
|rowspan="11"| Play<br />
|rowspan="11"| Client<br />
| Particle ID<br />
| Int<br />
| See below<br />
|-<br />
| Long Distance<br />
| Boolean<br />
| If true, particle distance increases from 256 to 65536<br />
|-<br />
| X<br />
| Float<br />
| X position of the particle<br />
|-<br />
| Y<br />
| Float<br />
| Y position of the particle<br />
|-<br />
| Z<br />
| Float<br />
| Z position of the particle<br />
|-<br />
| Offset X<br />
| Float<br />
| This is added to the X position after being multiplied by random.nextGaussian()<br />
|-<br />
| Offset Y<br />
| Float<br />
| This is added to the Y position after being multiplied by random.nextGaussian()<br />
|-<br />
| Offset Z<br />
| Float<br />
| This is added to the Z position after being multiplied by random.nextGaussian()<br />
|-<br />
| Particle Data<br />
| Float<br />
| The data of each particle<br />
|-<br />
| Particle Count<br />
| Int<br />
| The number of particles to create<br />
|-<br />
| Data<br />
| Array of VarInt<br />
| Length depends on particle. "iconcrack" has length of 2, "blockcrack", and "blockdust" have lengths of 1, the rest have 0.<br />
|}<br />
<br />
Particle IDs:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Particle Name<br />
! Particle ID<br />
|-<br />
| explode<br />
| 0<br />
|-<br />
| largeexplosion<br />
| 1<br />
|-<br />
| hugeexplosion<br />
| 2<br />
|-<br />
| fireworksSpark<br />
| 3<br />
|-<br />
| bubble<br />
| 4<br />
|-<br />
| splash<br />
| 5<br />
|-<br />
| wake<br />
| 6<br />
|-<br />
| suspended<br />
| 7<br />
|-<br />
| depthsuspend<br />
| 8<br />
|-<br />
| crit<br />
| 9<br />
|-<br />
| magicCrit<br />
| 10<br />
|-<br />
| smoke<br />
| 11<br />
|-<br />
| largesmoke<br />
| 12<br />
|-<br />
| spell<br />
| 13<br />
|-<br />
| instantSpell<br />
| 14<br />
|-<br />
| mobSpell<br />
| 15<br />
|-<br />
| mobSpellAmbient<br />
| 16<br />
|-<br />
| witchMagic<br />
| 17<br />
|-<br />
| dripWater<br />
| 18<br />
|-<br />
| dripLava<br />
| 19<br />
|-<br />
| angryVillager<br />
| 20<br />
|-<br />
| happyVillager<br />
| 21<br />
|-<br />
| townaura<br />
| 22<br />
|-<br />
| note<br />
| 23<br />
|-<br />
| portal<br />
| 24<br />
|-<br />
| enchantmenttable<br />
| 25<br />
|-<br />
| flame<br />
| 26<br />
|-<br />
| lava<br />
| 27<br />
|-<br />
| footstep<br />
| 28<br />
|-<br />
| cloud<br />
| 29<br />
|-<br />
| reddust<br />
| 30<br />
|-<br />
| snowballpoof<br />
| 31<br />
|-<br />
| snowshovel<br />
| 32<br />
|-<br />
| slime<br />
| 33<br />
|-<br />
| heart<br />
| 34<br />
|-<br />
| barrier<br />
| 35<br />
|-<br />
| iconcrack_(id)_(data)<br />
| 36<br />
|-<br />
| blockcrack_(id+(data<<12))<br />
| 37<br />
|-<br />
| blockdust_(id)<br />
| 38<br />
|-<br />
| droplet<br />
| 39<br />
|-<br />
| take<br />
| 40<br />
|-<br />
| mobappearance<br />
| 41<br />
|-<br />
| dragonbreath<br />
| 42<br />
|-<br />
| endrod<br />
| 43<br />
|-<br />
| damageindicator<br />
| 44<br />
|-<br />
| sweepattack<br />
| 45<br />
|-<br />
| fallingdust<br />
| 46<br />
|}<br />
<br />
==== Join Game ====<br />
<br />
See [[Protocol Encryption]] for information on logging in.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="7"| 0x23<br />
|rowspan="7"| Play<br />
|rowspan="7"| Client<br />
| Entity ID<br />
| Int<br />
| The player's Entity ID (EID)<br />
|-<br />
| Gamemode<br />
| Unsigned Byte<br />
| 0: Survival, 1: Creative, 2: Adventure, 3: Spectator. Bit 3 (0x8) is the hardcore flag.<br />
|-<br />
| Dimension<br />
| Int Enum<br />
| -1: Nether, 0: Overworld, 1: End; also, note that this is not a VarInt but instead a regular int.<br />
|-<br />
| Difficulty<br />
| Unsigned Byte<br />
| 0: peaceful, 1: easy, 2: normal, 3: hard<br />
|-<br />
| Max Players<br />
| Unsigned Byte<br />
| Was once used by the client to draw the player list, but now is ignored<br />
|-<br />
| Level Type<br />
| String Enum (16)<br />
| default, flat, largeBiomes, amplified, default_1_1<br />
|-<br />
| Reduced Debug Info<br />
| Boolean<br />
| If true, a Notchian client shows reduced information on the {{Minecraft Wiki|debug screen}}. For servers in development, this should almost always be false.<br />
|}<br />
<br />
==== Map ====<br />
<br />
Updates a rectangular area on a {{Minecraft Wiki|map}} item.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
!colspan="2"| Field Name<br />
!colspan="2"| Field Type<br />
! Notes<br />
|-<br />
|rowspan="13"| 0x24<br />
|rowspan="13"| Play<br />
|rowspan="13"| Client<br />
|colspan="2"| Item Damage<br />
|colspan="2"| VarInt<br />
| The damage value (map ID) of the map being modified<br />
|-<br />
|colspan="2"| Scale<br />
|colspan="2"| Byte<br />
| From 0 for a fully zoomed-in map (1 block per pixel) to 4 for a fully zoomed-out map (16 blocks per pixel)<br />
|- <br />
|colspan="2"| Tracking Position<br />
|colspan="2"| Boolean<br />
| Specifies whether the icons are shown<br />
|- <br />
|colspan="2"| Icon Count<br />
|colspan="2"| VarInt<br />
| Number of elements in the following array<br />
|-<br />
|rowspan="3"| Icon<br />
| Direction And Type<br />
|rowspan="3"| Array<br />
| Byte<br />
| 0xF0 = Direction, 0x0F = Type<br />
|-<br />
| X<br />
| Byte<br />
| <br />
|-<br />
| Z<br />
| Byte<br />
| <br />
|- <br />
|colspan="2"| Columns<br />
|colspan="2"| Byte<br />
| Number of columns updated<br />
|-<br />
|colspan="2"| Rows<br />
|colspan="2"| Optional Byte<br />
| Only if Columns is more than 0; number of rows updated<br />
|-<br />
|colspan="2"| X<br />
|colspan="2"| Optional Byte<br />
| Only if Columns is more than 0; x offset of the westernmost column<br />
|-<br />
|colspan="2"| Z<br />
|colspan="2"| Optional Byte<br />
| Only if Columns is more than 0; z offset of the northernmost row<br />
|-<br />
|colspan="2"| Length<br />
|colspan="2"| Optional VarInt<br />
| Only if Columns is more than 0; length of the following array<br />
|-<br />
|colspan="2"| Data<br />
|colspan="2"| Optional Array of Unsigned Byte<br />
| Only if Columns is more than 0; see {{Minecraft Wiki|Map item format}}<br />
|}<br />
<br />
For icons, a direction of 0 is a vertical icon and increments by 22.5&deg; (360/16).<br />
<br />
Types are based off of rows and columns in <code>map_icons.png</code>:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Icon type<br />
! Result<br />
|-<br />
| 0<br />
| White arrow (players)<br />
|-<br />
| 1<br />
| Green arrow (item frames)<br />
|-<br />
| 2<br />
| Red arrow<br />
|-<br />
| 3<br />
| Blue arrow<br />
|-<br />
| 4<br />
| White cross<br />
|-<br />
| 5<br />
| Red pointer<br />
|-<br />
| 6<br />
| White circle (off-map players)<br />
|-<br />
| 7<br />
| Small white circle (far-off-map players)<br />
|-<br />
| 8<br />
| Mansion<br />
|-<br />
| 9<br />
| Temple<br />
|-<br />
| 10-15<br />
| Unused (blue square)<br />
|}<br />
<br />
==== Entity ====<br />
<br />
This packet may be used to initialize an entity.<br />
<br />
For player entities, either this packet or any move/look packet is sent every game tick. So the meaning of this packet is basically that the entity did not move/look since the last such packet.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x25<br />
|rowspan="1"| Play<br />
|rowspan="1"| Client<br />
| Entity ID<br />
| VarInt<br />
| <br />
|}<br />
<br />
==== Entity Relative Move ====<br />
<br />
This packet is sent by the server when an entity moves less then 8 blocks; if an entity moves more than 8 blocks [[#Entity Teleport|Entity Teleport]] ([[#Play|Play]], 0x4A, clientbound) should be sent instead.<br />
<br />
This packet allows at most 8 blocks movement in any direction, because short range is from -32768 to 32767. And <code>32768 / (128 * 32)</code> = 8.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="5"| 0x26<br />
|rowspan="5"| Play<br />
|rowspan="5"| Client<br />
| Entity ID<br />
| VarInt<br />
| <br />
|-<br />
| Delta X<br />
| Short<br />
| Change in X position as <code>(currentX * 32 - prevX * 32) * 128</code><br />
|-<br />
| Delta Y<br />
| Short<br />
| Change in Y position as <code>(currentY * 32 - prevY * 32) * 128</code><br />
|-<br />
| Delta Z<br />
| Short<br />
| Change in Z position as <code>(currentZ * 32 - prevZ * 32) * 128</code><br />
|-<br />
| On Ground<br />
| Boolean<br />
| <br />
|}<br />
<br />
==== Entity Look And Relative Move ====<br />
<br />
This packet is sent by the server when an entity rotates and moves. Since a short range is limited from -32768 to 32767, and movement is offset of fixed-point numbers, this packet allows at most 8 blocks movement in any direction. (<code>-32768 / (32 * 128) == -8</code>)<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="7"| 0x27<br />
|rowspan="7"| Play<br />
|rowspan="7"| Client<br />
| Entity ID<br />
| VarInt<br />
| <br />
|-<br />
| Delta X<br />
| Short<br />
| Change in X position as <code>(currentX * 32 - prevX * 32) * 128</code><br />
|-<br />
| Delta Y<br />
| Short<br />
| Change in Y position as <code>(currentY * 32 - prevY * 32) * 128</code><br />
|-<br />
| Delta Z<br />
| Short<br />
| Change in Z position as <code>(currentZ * 32 - prevZ * 32) * 128</code><br />
|-<br />
| Yaw<br />
| Angle<br />
| New angle, not a delta<br />
|-<br />
| Pitch<br />
| Angle<br />
| New angle, not a delta<br />
|-<br />
| On Ground<br />
| Boolean<br />
| <br />
|}<br />
<br />
==== Entity Look ====<br />
<br />
This packet is sent by the server when an entity rotates.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="4"| 0x28<br />
|rowspan="4"| Play<br />
|rowspan="4"| Client<br />
| Entity ID<br />
| VarInt<br />
| <br />
|-<br />
| Yaw<br />
| Angle<br />
| New angle, not a delta<br />
|-<br />
| Pitch<br />
| Angle<br />
| New angle, not a delta<br />
|-<br />
| On Ground<br />
| Boolean<br />
| <br />
|}<br />
<br />
==== Vehicle Move (clientbound) ====<br />
<br />
Note that all fields use absolute positioning and do not allow for relative positioning.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="7"| 0x29<br />
|rowspan="7"| Play<br />
|rowspan="7"| Client<br />
| X<br />
| Double<br />
| Absolute position (X coordinate)<br />
|-<br />
| Y<br />
| Double<br />
| Absolute position (Y coordinate)<br />
|-<br />
| Z<br />
| Double<br />
| Absolute position (Z coordinate)<br />
|-<br />
| Yaw<br />
| Float<br />
| Absolute rotation on the vertical axis, in degrees<br />
|-<br />
| Pitch<br />
| Float<br />
| Absolute rotation on the horizontal axis, in degrees<br />
|}<br />
<br />
==== Open Sign Editor ====<br />
<br />
Sent when the client has placed a sign and is allowed to send [[#Update Sign|Update Sign]].<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x2A<br />
|rowspan="1"| Play<br />
|rowspan="1"| Client<br />
| Location<br />
| Position<br />
| <br />
|}<br />
<br />
==== Player Abilities (clientbound) ====<br />
<br />
The latter 2 floats are used to indicate the field of view and flying speed respectively, while the first byte is used to determine the value of 4 booleans.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x2B<br />
|rowspan="3"| Play<br />
|rowspan="3"| Client<br />
| Flags<br />
| Byte<br />
| Bit field, see below<br />
|-<br />
| Flying Speed<br />
| Float<br />
| <br />
|-<br />
| Field of View Modifier<br />
| Float<br />
| Modifies the field of view, like a speed potion. A Notchian server will use the same value as the movement speed (send in the [[Protocol#Entity_Properties|Entity Properties]] packet).<br />
|}<br />
<br />
About the flags:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Field<br />
! Bit<br />
|-<br />
| Invulnerable<br />
| 0x01<br />
|-<br />
| Flying<br />
| 0x02<br />
|-<br />
| Allow Flying<br />
| 0x04<br />
|-<br />
| Creative Mode<br />
| 0x08<br />
|}<br />
<br />
==== Combat Event ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
!colspan="2"| Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="8"| 0x2C<br />
|rowspan="8"| Play<br />
|rowspan="8"| Client<br />
|colspan="2"| Event<br />
| VarInt Enum<br />
| Determines the layout of the remaining packet<br />
|-<br />
! Event<br />
! Field Name<br />
! <br />
! <br />
|-<br />
| 0: enter combat<br />
| ''no fields''<br />
| ''no fields''<br />
| <br />
|-<br />
|rowspan="2"| 1: end combat<br />
| Duration<br />
| VarInt<br />
| <br />
|-<br />
| Entity ID<br />
| Int<br />
| <br />
|-<br />
|rowspan="3"| 2: entity dead<br />
| Player ID<br />
| VarInt<br />
| <br />
|-<br />
| Entity ID<br />
| Int<br />
| <br />
|-<br />
| Message<br />
| [[Chat]]<br />
| <br />
|}<br />
<br />
==== Player List Item ====<br />
<br />
Sent by the server to update the user list (<tab> in the client).<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
!colspan="4"| Field Name<br />
!colspan="3"| Field Type<br />
! Notes<br />
|-<br />
|rowspan="19"| 0x2D<br />
|rowspan="19"| Play<br />
|rowspan="19"| Client<br />
|colspan="4"| Action<br />
|colspan="3"| VarInt<br />
| Determines the rest of the Player format after the UUID<br />
|-<br />
|colspan="4"| Number Of Players<br />
|colspan="3"| VarInt<br />
| Number of elements in the following array<br />
|-<br />
|rowspan="17"| Player<br />
|colspan="3"| UUID<br />
|rowspan="17"| Array<br />
|colspan="2"| UUID<br />
| <br />
|-<br />
! Action<br />
!colspan="2"| Field Name<br />
!colspan="2"| <br />
! <br />
|-<br />
|rowspan="10"| 0: add player<br />
|colspan="2"| Name<br />
|colspan="2"| String (16)<br />
| <br />
|-<br />
|colspan="2"| Number Of Properties<br />
|colspan="2"| VarInt<br />
| Number of elements in the following array<br />
|-<br />
|rowspan="4"| Property<br />
| Name<br />
|rowspan="4"| Array<br />
| String (32767)<br />
| <br />
|-<br />
| Value<br />
| String (32767)<br />
| <br />
|- <br />
| Is Signed<br />
| Boolean<br />
| <br />
|-<br />
| Signature<br />
| Optional String (32767)<br />
| Only if Is Signed is true<br />
|-<br />
|colspan="2"| Gamemode<br />
|colspan="2"| VarInt<br />
| <br />
|-<br />
|colspan="2"| Ping<br />
|colspan="2"| VarInt<br />
| <br />
|-<br />
|colspan="2"| Has Display Name<br />
|colspan="2"| Boolean<br />
| <br />
|-<br />
|colspan="2"| Display Name<br />
|colspan="2"| Optional [[Chat]]<br />
| Only if Has Display Name is true<br />
|-<br />
| 1: update gamemode<br />
|colspan="2"| Gamemode<br />
|colspan="2"| VarInt<br />
| <br />
|- <br />
| 2: update latency<br />
|colspan="2"| Ping<br />
|colspan="2"| VarInt<br />
| <br />
|-<br />
|rowspan="2"| 3: update display name<br />
|colspan="2"| Has Display Name<br />
|colspan="2"| Boolean<br />
| <br />
|-<br />
|colspan="2"| Display Name<br />
|colspan="2"| Optional [[Chat]]<br />
| Only send if Has Display Name is true<br />
|-<br />
| 4: remove player<br />
|colspan="2"| ''no fields''<br />
|colspan="2"| ''no fields''<br />
| <br />
|}<br />
<br />
The Property field looks as in the response of [[Mojang API#UUID -> Profile + Skin/Cape]], except of course using the protocol format instead of JSON. That is, each player will usually have one property with Name “textures” and Value being a base64-encoded JSON string as documented at [[Mojang API#UUID -> Profile + Skin/Cape]]. An empty properties array is also acceptable, and will cause clients to display the player with one of the two default skins depending on UUID.<br />
<br />
==== Player Position And Look (clientbound) ==== <br />
<br />
Updates the player's position on the server. This packet will also close the “Downloading Terrain” screen when joining/respawning.<br />
<br />
If the distance between the last known position of the player on the server and the new position set by this packet is greater than 100 meters, the client will be kicked for “You moved too quickly :( (Hacking?)”.<br />
<br />
Also if the fixed-point number of X or Z is set greater than <code>3.2E7D</code> the client will be kicked for “Illegal position”.<br />
<br />
Yaw is measured in degrees, and does not follow classical trigonometry rules. The unit circle of yaw on the XZ-plane starts at (0, 1) and turns counterclockwise, with 90 at (-1, 0), 180 at (0, -1) and 270 at (1, 0). Additionally, yaw is not clamped to between 0 and 360 degrees; any number is valid, including negative numbers and numbers greater than 360.<br />
<br />
Pitch is measured in degrees, where 0 is looking straight ahead, -90 is looking straight up, and 90 is looking straight down.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="7"| 0x2E<br />
|rowspan="7"| Play<br />
|rowspan="7"| Client<br />
| X<br />
| Double<br />
| Absolute or relative position, depending on Flags<br />
|-<br />
| Y<br />
| Double<br />
| Absolute or relative position, depending on Flags<br />
|-<br />
| Z<br />
| Double<br />
| Absolute or relative position, depending on Flags<br />
|-<br />
| Yaw<br />
| Float<br />
| Absolute or relative rotation on the X axis, in degrees<br />
|-<br />
| Pitch<br />
| Float<br />
| Absolute or relative rotation on the Y axis, in degrees<br />
|-<br />
| Flags<br />
| Byte<br />
| Bit field, see below<br />
|-<br />
| Teleport ID<br />
| VarInt<br />
| Client should confirm this packet with [[#Teleport Confirm|Teleport Confirm]] containing the same Teleport ID<br />
|}<br />
<br />
About the Flags field:<br />
<br />
<Dinnerbone> It's a bitfield, X/Y/Z/Y_ROT/X_ROT. If X is set, the x value is relative and not absolute.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Field<br />
! Bit<br />
|-<br />
| X<br />
| 0x01<br />
|-<br />
| Y<br />
| 0x02<br />
|-<br />
| Z<br />
| 0x04<br />
|-<br />
| Y_ROT<br />
| 0x08<br />
|-<br />
| X_ROT<br />
| 0x10<br />
|}<br />
<br />
==== Use Bed ==== <br />
<br />
This packet tells that a player goes to bed.<br />
<br />
The client with the matching Entity ID will go into bed mode.<br />
<br />
This Packet is sent to all nearby players including the one sent to bed.<br />
<br />
Any packets sent with a location not currently occupied by a bed will be ignored by clients.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x2F<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Entity ID<br />
| VarInt<br />
| Sleeping player's EID<br />
|-<br />
| Location<br />
| Position<br />
| Block location of the head part of the bed<br />
|}<br />
<br />
==== Unlock Recipes ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="8"| 0x30<br />
|rowspan="8"| Play<br />
|rowspan="8"| Client<br />
|-<br />
| Action<br />
| VarInt<br />
| 0: init, 1: add, 2: remove<br />
|-<br />
| Crafting Book Open<br />
| Boolean<br />
| If true, then the crafting book will be open when the player opens its inventory.<br />
|-<br />
| Filtering Craftable<br />
| Boolean<br />
| If true, then the filtering option is active when the players opens its inventory.<br />
|-<br />
| Array size 1<br />
| VarInt<br />
| Number of elements in the following array<br />
|-<br />
| Recipe IDs<br />
| Array of VarInt<br />
|<br />
|-<br />
| Array size 2<br />
| Optional VarInt<br />
| Number of elements in the following array, only present if mode is 0 (init)<br />
|-<br />
| Recipe IDs<br />
| Optional Array of VarInt, only present if mode is 0 (init)<br />
|<br />
|}<br />
Action:<br />
* 0 (init) = All the recipes in the list 2 will added to the recipe book. All the recipes in list 1 will be tagged as displayed, recipes that aren't tagged will be shown in the notification. VERIFY LIST ORDER?<br />
* 1 (add) = All the recipes in the list are added and their icon will be shown in the notification.<br />
* 2 (remove) = Remove all the recipes in the list. This allows them to re-displayed when they are readded.<br />
<br />
Recipe ID:<br />
These are hardcoded values in the client and server, all the recipe json files will be loaded in a specific order (alphabetical, like sounds) and internal ids will be assigned in that order. There are also inbuilt recipes like fireworks, banners, etc., these are the first recipes to have their id assigned. Due the fact that the recipes are loaded in a specific order will the ids very likely change when recipes get added. [https://twitter.com/dinnerbone/status/856505341479145472 Custom recipes are scheduled for Minecraft 1.13], so most likely will things change a bit in that version.<br />
<br />
==== Destroy Entities ====<br />
<br />
Sent by the server when a list of entities is to be destroyed on the client.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x31<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Count<br />
| VarInt<br />
| Number of elements in the following array<br />
|-<br />
| Entity IDs<br />
| Array of VarInt<br />
| The list of entities of destroy<br />
|}<br />
<br />
==== Remove Entity Effect ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x32<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Entity ID<br />
| VarInt<br />
| <br />
|-<br />
| Effect ID<br />
| Byte<br />
| See {{Minecraft Wiki|Status effect#List of effects|this table}}<br />
|}<br />
<br />
==== Resource Pack Send ==== <br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x33<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| URL<br />
| String (32767)<br />
| The URL to the resource pack.<br />
|-<br />
| Hash<br />
| String (40)<br />
| A 40 character hexadecimal and lowercase [[wikipedia:SHA-1|SHA-1]] hash of the resource pack file. (must be lower case in order to work)<br />If it's not a 40 character hexadecimal string, the client will not use it for hash verification and likely waste bandwidth — but it will still treat it as a unique id<br />
|}<br />
<br />
==== Respawn ====<br />
<br />
To change the player's dimension (overworld/nether/end), send them a respawn packet with the appropriate dimension, followed by prechunks/chunks for the new dimension, and finally a position and look packet. You do not need to unload chunks, the client will do it automatically.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="4"| 0x34<br />
|rowspan="4"| Play<br />
|rowspan="4"| Client<br />
| Dimension<br />
| Int Enum<br />
| -1: The Nether, 0: The Overworld, 1: The End<br />
|-<br />
| Difficulty<br />
| Unsigned Byte<br />
| 0: Peaceful, 1: Easy, 2: Normal, 3: Hard<br />
|-<br />
| Gamemode<br />
| Unsigned Byte<br />
| 0: survival, 1: creative, 2: adventure, 3: spectator. The hardcore flag is not included<br />
|-<br />
| Level Type<br />
| String (16)<br />
| Same as [[#Join Game|Join Game]]<br />
|}<br />
<br />
{{Warning2|Avoid changing player's dimension to same dimension they were already in unless they are dead. If you change the dimension to one they are already in, weird bugs can occur, such as the player being unable to attack other players in new world (until they die and respawn).<br />
<br />
If you must respawn a player in the same dimension without killing them, send two respawn packets, one to a different world and then another to the world you want. You do not need to complete the first respawn; it only matters that you send two packets.}}<br />
<br />
==== Entity Head Look ====<br />
<br />
Changes the direction an entity's head is facing.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x35<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Entity ID<br />
| VarInt<br />
| <br />
|-<br />
| Head Yaw<br />
| Angle<br />
| New angle, not a delta<br />
|}<br />
<br />
==== Select Advancement Tab ====<br />
<br />
Sent by the server to indicate that the client should switch advancement tab. Sent either when the client switches tab in the GUI or when an advancement in another tab is made.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x36<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Has id<br />
| Boolean<br />
| Indicates if the next field is present<br />
|-<br />
| Optional Identifier<br />
| String (32767)<br />
| See below<br />
|}<br />
<br />
The Identifier can be one of the following:<br />
<br />
{| class="wikitable"<br />
! Optional Identifier<br />
|-<br />
| minecraft:story/root<br />
|-<br />
| minecraft:nether/root<br />
|-<br />
| minecraft:end/root<br />
|-<br />
| minecraft:adventure/root<br />
|-<br />
| minecraft:husbandry/root<br />
|}<br />
<br />
If no or an invalid identifier is sent, the client will switch to the first tab in the GUI.<br />
<br />
==== World Border ==== <br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
!colspan="2"| Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="18"| 0x37<br />
|rowspan="18"| Play<br />
|rowspan="18"| Client<br />
|colspan="2"| Action<br />
| VarInt Enum<br />
| Determines the format of the rest of the packet<br />
|-<br />
! Action<br />
! Field Name<br />
! <br />
! <br />
|-<br />
| 0: set size<br />
| Diameter<br />
| Double<br />
| Length of a single side of the world border, in meters<br />
|-<br />
|rowspan="3"| 1: lerp size<br />
| Old Diameter<br />
| Double<br />
| Current length of a single side of the world border, in meters<br />
|-<br />
| New Diameter<br />
| Double<br />
| Target length of a single side of the world border, in meters<br />
|-<br />
| Speed<br />
| VarLong<br />
| Number of real-time ''milli''seconds until New Diameter is reached. It appears that Notchian server does not sync world border speed to game ticks, so it gets out of sync with server lag. If the world border is not moving, this is set to 0.<br />
|-<br />
|rowspan="2"| 2: set center<br />
| X<br />
| Double<br />
| <br />
|-<br />
| Z<br />
| Double<br />
| <br />
|-<br />
|rowspan="8"| 3: initialize<br />
| X<br />
| Double<br />
| <br />
|-<br />
| Z<br />
| Double<br />
| <br />
|-<br />
| Old Diameter<br />
| Double<br />
| Current length of a single side of the world border, in meters<br />
|-<br />
| New Diameter<br />
| Double<br />
| Target length of a single side of the world border, in meters<br />
|-<br />
| Speed<br />
| VarLong<br />
| Number of real-time ''milli''seconds until New Diameter is reached. It appears that Notchian server does not sync world border speed to game ticks, so it gets out of sync with server lag. If the world border is not moving, this is set to 0.<br />
|-<br />
| Portal Teleport Boundary<br />
| VarInt<br />
| Resulting coordinates from a portal teleport are limited to ±value. Usually 29999984.<br />
|-<br />
| Warning Time<br />
| VarInt<br />
| In seconds as set by <code>/worldborder warning time</code><br />
|-<br />
| Warning Blocks<br />
| VarInt<br />
| In meters<br />
|-<br />
|rowspan="1"| 4: set warning time<br />
| Warning Time<br />
| VarInt<br />
| In seconds as set by <code>/worldborder warning time</code><br />
|-<br />
|rowspan="1"| 5: set warning blocks<br />
| Warning Blocks<br />
| VarInt<br />
| In meters<br />
|}<br />
<br />
The Notchian client determines how solid to display the warning by comparing to whichever is higher, the warning distance or whichever is lower, the distance from the current diameter to the target diameter or the place the border will be after warningTime seconds. In pseudocode:<br />
<br />
<syntaxhighlight lang="java"><br />
distance = max(min(resizeSpeed * 1000 * warningTime, abs(targetDiameter - currentDiameter)), warningDistance);<br />
if (playerDistance < distance) {<br />
warning = 1.0 - playerDistance / distance;<br />
} else {<br />
warning = 0.0;<br />
}<br />
</syntaxhighlight><br />
<br />
==== Camera ====<br />
<br />
Sets the entity that the player renders from. This is normally used when the player left-clicks an entity while in spectator mode.<br />
<br />
The player's camera will move with the entity and look where it is looking. The entity is often another player, but can be any type of entity. The player is unable to move this entity (move packets will act as if they are coming from the other entity).<br />
<br />
If the given entity is not loaded by the player, this packet is ignored. To return control to the player, send this packet with their entity ID.<br />
<br />
The Notchian server resets this (sends it back to the default entity) whenever the spectated entity is killed or the player sneaks, but only if they were spectating an entity. It also sends this packet whenever the player switches out of spectator mode (even if they weren't spectating an entity).<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x38<br />
|rowspan="1"| Play<br />
|rowspan="1"| Client<br />
| Camera ID<br />
| VarInt<br />
| ID of the entity to set the client's camera to<br />
|}<br />
<br />
The notchian also loads certain shaders for given entities:<br />
<br />
* Creeper &rarr; <code>shaders/post/creeper.json</code><br />
* Spider (and cave spider) &rarr; <code>shaders/post/spider.json</code><br />
* Enderman &rarr; <code>shaders/post/invert.json</code><br />
* Anything else &rarr; the current shader is unloaded<br />
<br />
==== Held Item Change (clientbound) ====<br />
<br />
Sent to change the player's slot selection.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x39<br />
|rowspan="1"| Play<br />
|rowspan="1"| Client<br />
| Slot<br />
| Byte<br />
| The slot which the player has selected (0–8)<br />
|}<br />
<br />
==== Display Scoreboard ====<br />
<br />
This is sent to the client when it should display a scoreboard.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x3A<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Position<br />
| Byte<br />
| The position of the scoreboard. 0: list, 1: sidebar, 2: below name.<br />
|-<br />
| Score Name<br />
| String (16)<br />
| The unique name for the scoreboard to be displayed.<br />
|}<br />
<br />
==== Entity Metadata ====<br />
<br />
Updates one or more [[Entities#Entity Metadata Format|metadata]] properties for an existing entity. Any properties not included in the Metadata field are left unchanged.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x3B<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Entity ID<br />
| VarInt<br />
| <br />
|-<br />
| Metadata<br />
| [[Entities#Entity Metadata Format|Entity Metadata]]<br />
| <br />
|}<br />
<br />
==== Attach Entity ====<br />
<br />
This packet is sent when an entity has been {{Minecraft Wiki|Lead|leashed}} to another entity.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x3C<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Attached Entity ID<br />
| Int<br />
| Attached entity's EID<br />
|-<br />
| Holding Entity ID<br />
| Int<br />
| ID of the entity holding the lead. Set to -1 to detach.<br />
|}<br />
<br />
==== Entity Velocity ====<br />
<br />
Velocity is believed to be in units of 1/8000 of a block per server tick (50ms); for example, -1343 would move (-1343 / 8000) = −0.167875 blocks per tick (or −3,3575 blocks per second).<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="4"| 0x3D<br />
|rowspan="4"| Play<br />
|rowspan="4"| Client<br />
| Entity ID<br />
| VarInt<br />
| <br />
|-<br />
| Velocity X<br />
| Short<br />
| Velocity on the X axis<br />
|-<br />
| Velocity Y<br />
| Short<br />
| Velocity on the Y axis<br />
|-<br />
| Velocity Z<br />
| Short<br />
| Velocity on the Z axis<br />
|}<br />
<br />
==== Entity Equipment ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x3E<br />
|rowspan="3"| Play<br />
|rowspan="3"| Client<br />
| Entity ID<br />
| VarInt<br />
| Entity's EID<br />
|-<br />
| Slot<br />
| VarInt Enum<br />
| Equipment slot. 0: main hand, 1: off hand, 2–5: armor slot (2: boots, 3: leggings, 4: chestplate, 5: helmet)<br />
|-<br />
| Item<br />
| [[Slot Data|Slot]]<br />
| <br />
|}<br />
<br />
==== Set Experience ====<br />
<br />
Sent by the server when the client should change experience levels.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x3F<br />
|rowspan="3"| Play<br />
|rowspan="3"| Client<br />
| Experience bar<br />
| Float<br />
| Between 0 and 1<br />
|-<br />
| Level<br />
| VarInt<br />
| <br />
|-<br />
| Total Experience<br />
| VarInt<br />
| See {{Minecraft Wiki|Experience#Leveling up}} on the Minecraft Wiki for Total Experience to Level conversion<br />
|}<br />
<br />
==== Update Health ====<br />
<br />
Sent by the server to update/set the health of the player it is sent to.<br />
<br />
Food {{Minecraft Wiki|Food#Hunger vs. Saturation|saturation}} acts as a food “overcharge”. Food values will not decrease while the saturation is over zero. Players logging in automatically get a saturation of 5.0. Eating food increases the saturation as well as the food bar.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x40<br />
|rowspan="3"| Play<br />
|rowspan="3"| Client<br />
| Health<br />
| Float<br />
| 0 or less = dead, 20 = full HP<br />
|-<br />
| Food<br />
| VarInt<br />
| 0–20<br />
|- <br />
| Food Saturation<br />
| Float<br />
| Seems to vary from 0.0 to 5.0 in integer increments<br />
|}<br />
<br />
==== Scoreboard Objective ====<br />
<br />
This is sent to the client when it should create a new {{Minecraft Wiki|scoreboard}} objective or remove one.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="4"| 0x41<br />
|rowspan="4"| Play<br />
|rowspan="4"| Client<br />
| Objective Name<br />
| String (16)<br />
| An unique name for the objective<br />
|-<br />
| Mode<br />
| Byte<br />
| 0 to create the scoreboard. 1 to remove the scoreboard. 2 to update the display text. <br />
|-<br />
| Objective Value<br />
| Optional String (32)<br />
| Only if mode is 0 or 2. The text to be displayed for the score<br />
|-<br />
| Type<br />
| Optional String (16)<br />
| Only if mode is 0 or 2. “integer” or “hearts”<br />
|}<br />
<br />
==== Set Passengers ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x42<br />
|rowspan="3"| Play<br />
|rowspan="3"| Client<br />
| Entity ID<br />
| VarInt<br />
| Vehicle's EID<br />
|-<br />
| Passenger Count<br />
| VarInt<br />
| Number of elements in the following array<br />
|-<br />
| Passengers<br />
| Array of VarInt<br />
| EIDs of entity's passengers<br />
|}<br />
<br />
==== Teams ====<br />
<br />
Creates and updates teams.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
!colspan="2"| Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="23"| 0x43<br />
|rowspan="23"| Play<br />
|rowspan="23"| Client<br />
|colspan="2"| Team Name<br />
| String (16)<br />
| A unique name for the team. (Shared with scoreboard).<br />
|-<br />
|colspan="2"| Mode<br />
| Byte<br />
| Determines the layout of the remaining packet<br />
|-<br />
|rowspan="9"| 0: create team<br />
| Team Display Name<br />
| String (32)<br />
| <br />
|-<br />
| Team Prefix<br />
| String (16)<br />
| Displayed before the names of players that are part of this team<br />
|-<br />
| Team Suffix<br />
| String (16)<br />
| Displayed after the names of players that are part of this team<br />
|-<br />
| Friendly Flags<br />
| Byte<br />
| Bit mask. 0x01: Allow friendly fire, 0x02: can see invisible players on same team<br />
|-<br />
| Name Tag Visibility<br />
| String Enum (32)<br />
| <code>always</code>, <code>hideForOtherTeams</code>, <code>hideForOwnTeam</code>, <code>never</code><br />
|-<br />
| Collision Rule<br />
| String Enum (32)<br />
| <code>always</code>, <code>pushOtherTeams</code>, <code>pushOwnTeam</code>, <code>never</code><br />
|-<br />
| Color<br />
| Byte<br />
| For colors, the same [[Chat]] colors (0-15). -1 indicates RESET/no color.<br />
|-<br />
| Entity Count<br />
| VarInt<br />
| Number of elements in the following array<br />
|-<br />
| Entities<br />
| Array of String (40)<br />
| Identifiers for the entities in this team. For players, this is their username; for other entities, it is their UUID.<br />
|-<br />
| 1: remove team<br />
| ''no fields''<br />
| ''no fields''<br />
| <br />
|-<br />
|rowspan="7"| 2: update team info<br />
| Team Display Name<br />
| String (32)<br />
| <br />
|-<br />
| Team Prefix<br />
| String (16)<br />
| Displayed before the names of entities that are part of this team<br />
|-<br />
| Team Suffix<br />
| String (16)<br />
| Displayed after the names of entities that are part of this team<br />
|-<br />
| Friendly Flags<br />
| Byte<br />
| Bit mask. 0x01: Allow friendly fire, 0x02: can see invisible entities on same team<br />
|-<br />
| Name Tag Visibility<br />
| String Enum (32)<br />
| <code>always</code>, <code>hideForOtherTeams</code>, <code>hideForOwnTeam</code>, <code>never</code><br />
|-<br />
| Collision Rule<br />
| String Enum (32)<br />
| <code>always</code>, <code>pushOtherTeams</code>, <code>pushOwnTeam</code>, <code>never</code><br />
|-<br />
| Color<br />
| Byte<br />
| For colors, the same [[Chat]] colors (0-15). -1 indicates RESET/no color.<br />
|-<br />
|rowspan="2"| 3: add players to team<br />
| Entity Count<br />
| VarInt<br />
| Number of elements in the following array<br />
|-<br />
| Entities<br />
| Array of String (40)<br />
| Identifiers for the entities added. For players, this is their username; for other entities, it is their UUID.<br />
|-<br />
|rowspan="2"| 4: remove players from team<br />
| Entity Count<br />
| VarInt<br />
| Number of elements in the following array<br />
|-<br />
| Entities<br />
| Array of String (40)<br />
| Identifiers for the entities removed. For players, this is their username; for other entities, it is their UUID.<br />
|}<br />
<br />
==== Update Score ====<br />
<br />
This is sent to the client when it should update a scoreboard item. <br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="4"| 0x44<br />
|rowspan="4"| Play<br />
|rowspan="4"| Client<br />
| Entity Name<br />
| String (40)<br />
| The entity whose score this is. For players, this is their username; for other entities, it is their UUID.<br />
|-<br />
| Action<br />
| Byte<br />
| 0 to create/update an item. 1 to remove an item.<br />
|-<br />
| Objective Name<br />
| String (16)<br />
| The name of the objective the score belongs to<br />
|-<br />
| Value<br />
| Optional VarInt<br />
| The score to be displayed next to the entry. Only sent when Action does not equal 1.<br />
|}<br />
<br />
==== Spawn Position ====<br />
<br />
Sent by the server after login to specify the coordinates of the spawn point (the point at which players spawn at, and which the compass points to). It can be sent at any time to update the point compasses point at.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x45<br />
|rowspan="1"| Play<br />
|rowspan="1"| Client<br />
| Location<br />
| Position<br />
| Spawn location<br />
|}<br />
<br />
==== Time Update ====<br />
<br />
Time is based on ticks, where 20 ticks happen every second. There are 24000 ticks in a day, making Minecraft days exactly 20 minutes long.<br />
<br />
The time of day is based on the timestamp modulo 24000. 0 is sunrise, 6000 is noon, 12000 is sunset, and 18000 is midnight.<br />
<br />
The default SMP server increments the time by <code>20</code> every second.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x46<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| World Age<br />
| Long<br />
| In ticks; not changed by server commands<br />
|-<br />
| Time of day<br />
| Long<br />
| The world (or region) time, in ticks. If negative the sun will stop moving at the Math.abs of the time<br />
|}<br />
<br />
==== Title ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
!colspan="2"| Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="10"| 0x47<br />
|rowspan="10"| Play<br />
|rowspan="10"| Client<br />
|colspan="2"| Action<br />
| VarInt Enum<br />
| <br />
|-<br />
! Action<br />
! Field Name<br />
! <br />
! <br />
|-<br />
| 0: set title<br />
| Title Text<br />
| [[Chat]]<br />
| <br />
|-<br />
| 1: set subtitle<br />
| Subtitle Text<br />
| [[Chat]]<br />
| <br />
|- <br />
| 2: set action bar<br />
| Action bar text<br />
| [[Chat]]<br />
| Behaves the same as with position 2 in [[#Chat Message (clientbound)|Chat Message (clientbound)]]<br />
|-<br />
|rowspan="3"| 3: set times and display<br />
| Fade In<br />
| Int<br />
| Ticks to spend fading in<br />
|-<br />
| Stay<br />
| Int<br />
| Ticks to keep the title displayed<br />
|-<br />
| Fade Out<br />
| Int<br />
| Ticks to spend out, not when to start fading out<br />
|-<br />
| 4: hide<br />
| ''no fields''<br />
| ''no fields''<br />
| <br />
|-<br />
| 5: reset<br />
| ''no fields''<br />
| ''no fields''<br />
| <br />
|}<br />
<br />
“Hide” makes the title disappear, but if you run times again the same title will appear. “Reset” erases the text.<br />
<br />
The title is visible on screen for Fade In + Stay + Fade Out ticks.<br />
<br />
==== Sound Effect ====<br />
<br />
This packet is used to play a number of hardcoded sound events. For custom sounds, use [[#Named Sound Effect|Named Sound Effect]] ([[#Play|Play]], 0x19, clientbound).<br />
<br />
{{Warning|Numeric sound effect IDs are liable to change between versions}}<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="7"| 0x48<br />
|rowspan="7"| Play<br />
|rowspan="7"| Client<br />
| Sound ID<br />
| VarInt<br />
| ID of hardcoded sound event ([http://pokechu22.github.io/Burger/1.11.html#sounds events] as of 1.11.0)<br />
|-<br />
| Sound Category<br />
| VarInt Enum<br />
| The category that this sound will be played from ([https://gist.github.com/konwboj/7c0c380d3923443e9d55 current categories])<br />
|-<br />
| Effect Position X<br />
| Int<br />
| Effect X multiplied by 8 ([[Data types#Fixed-point numbers|fixed-point number]] with only 3 bits dedicated to the fractional part)<br />
|-<br />
| Effect Position Y<br />
| Int<br />
| Effect Y multiplied by 8 ([[Data types#Fixed-point numbers|fixed-point number]] with only 3 bits dedicated to the fractional part)<br />
|-<br />
| Effect Position Z<br />
| Int<br />
| Effect Z multiplied by 8 ([[Data types#Fixed-point numbers|fixed-point number]] with only 3 bits dedicated to the fractional part)<br />
|-<br />
| Volume<br />
| Float<br />
| 1.0 is 100%, capped between 0.0 and 1.0 by Notchian clients<br />
|-<br />
| Pitch<br />
| Float<br />
| Float between 0.5 and 2.0 by Notchian clients<br />
<br />
|}<br />
<br />
==== Player List Header And Footer ====<br />
<br />
This packet may be used by custom servers to display additional information above/below the player list. It is never sent by the Notchian server.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x49<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Header<br />
| [[Chat]]<br />
| To remove the header, send a empty translatable component: {"translate":""}<br />
|-<br />
| Footer<br />
| [[Chat]]<br />
| To remove the footer, send a empty translatable component: {"translate":""}<br />
|}<br />
<br />
==== Collect Item ====<br />
<br />
Sent by the server when someone picks up an item lying on the ground — its sole purpose appears to be the animation of the item flying towards you. It doesn't destroy the entity in the client memory, and it doesn't add it to your inventory. The server only checks for items to be picked up after each [[#Player Position|Player Position]] (and [[#Player Position And Look|Player Position And Look]]) packet sent by the client.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x4A<br />
|rowspan="3"| Play<br />
|rowspan="3"| Client<br />
| Collected Entity ID<br />
| VarInt<br />
| <br />
|- <br />
| Collector Entity ID<br />
| VarInt<br />
| <br />
|- <br />
| Pickup Item Count<br />
| VarInt<br />
| Seems to be 1 for XP orbs, otherwise the number of items in the stack.<br />
|}<br />
<br />
==== Entity Teleport ====<br />
<br />
This packet is sent by the server when an entity moves more than 4 blocks.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="7"| 0x4B<br />
|rowspan="7"| Play<br />
|rowspan="7"| Client<br />
| Entity ID<br />
| VarInt<br />
| <br />
|-<br />
| X<br />
| Double<br />
| <br />
|-<br />
| Y<br />
| Double<br />
| <br />
|-<br />
| Z<br />
| Double<br />
| <br />
|-<br />
| Yaw<br />
| Angle<br />
| New angle, not a delta<br />
|-<br />
| Pitch<br />
| Angle<br />
| New angle, not a delta<br />
|-<br />
| On Ground<br />
| Boolean<br />
| <br />
|}<br />
<br />
==== Advancements ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
!colspan="2"| Field Name<br />
!colspan="2"| Field Type<br />
! Notes<br />
|-<br />
|rowspan="9"| 0x4C<br />
|rowspan="9"| Play<br />
|rowspan="9"| Client<br />
|colspan="2"| Reset/Clear<br />
|colspan="2"| Boolean<br />
| Whether to reset/clear the current advancements<br />
|-<br />
|colspan="2"| Mapping size<br />
|colspan="2"| VarInt<br />
| Size of the following array<br />
|-<br />
|rowspan="2"| Advancement mapping<br />
| Key<br />
|rowspan="2"| Array<br />
| Identifier<br />
| The identifier of the advancement<br />
|-<br />
| Value<br />
| Advancement<br />
| See below<br />
|-<br />
|colspan="2"| List size<br />
|colspan="2"| VarInt<br />
| Size of the following array<br />
|-<br />
|colspan="2"| Identifiers<br />
|colspan="2"| Array of Identifier<br />
| The identifiers of the advancements that should be removed<br />
|-<br />
|colspan="2"| Progress size<br />
|colspan="2"| VarInt<br />
| Size of the following array<br />
|-<br />
|rowspan="2"| Progress mapping<br />
| Key<br />
|rowspan="2"| Array<br />
| Identifier<br />
| The identifier of the advancement<br />
|-<br />
| Value<br />
| Advancement progress<br />
| See below<br />
|}<br />
<br />
Advancement structure:<br />
<br />
{| class="wikitable"<br />
!colspan="2"| Field Name<br />
!colspan="2"| Field Type<br />
! Notes<br />
|-<br />
|colspan="2"| Has parent<br />
|colspan="2"| Boolean<br />
| Indicates whether the next field exists.<br />
|-<br />
|colspan="2"| Parent id<br />
|colspan="2"| Optional Identifier<br />
| The identifier of the parent advancement.<br />
|-<br />
|colspan="2"| Has display<br />
|colspan="2"| Boolean<br />
| Indicates whether the next field exists<br />
|-<br />
|colspan="2"| Display data<br />
|colspan="2"| Optional advancement display<br />
| See below.<br />
|-<br />
|colspan="2"| Number of criteria<br />
|colspan="2"| VarInt<br />
| Size of the following array<br />
|-<br />
|rowspan="2"| Criteria<br />
| Key<br />
|rowspan="2"| Array<br />
| Identifier<br />
| The identifier of the criterion<br />
|-<br />
| Value<br />
| '''Void'''<br />
| There is ''no'' content written here. Perhaps this will be expanded in the future?<br />
|-<br />
|colspan="2"| Array length<br />
|colspan="2"| VarInt<br />
| Number of arrays in the following array<br />
|-<br />
|rowspan="2"| Requirements<br />
| Array length 2<br />
|rowspan="2"| Array<br />
| VarInt<br />
| Number of elements in the following array<br />
|-<br />
| Requirement<br />
| Array of String<br />
| Array of required criteria<br />
|}<br />
<br />
Advancement display:<br />
<br />
{| class="wikitable"<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
| Title<br />
| Chat<br />
|<br />
|-<br />
| Description<br />
| Chat<br />
|<br />
|-<br />
| Icon<br />
| [[Slot]]<br />
|<br />
|-<br />
| Frame type<br />
| VarInt enum<br />
| 0 = <code>task</code>, 1 = <code>challenge</code>, 2 = <code>goal</code><br />
|-<br />
| Flags<br />
| Integer<br />
| 0x1: has background texture; 0x2: <code>show_toast</code>; 0x4: <code>hidden</code><br />
|-<br />
| Background texture<br />
| Optional Identifier<br />
| Background texture location. Only if flags indicates it.<br />
|-<br />
| X coord<br />
| Float<br />
| <br />
|-<br />
| Y coord<br />
| Float<br />
| <br />
|}<br />
<br />
Advancement progress:<br />
<br />
{| class="wikitable"<br />
!colspan="2"| Field Name<br />
!colspan="2"| Field Type<br />
! Notes<br />
|-<br />
|colspan="2"| Size<br />
|colspan="2"| VarInt<br />
| Size of the following array<br />
|-<br />
|rowspan="2"| Criteria<br />
| Criterion identifier<br />
|rowspan="2"| Array<br />
| Identifier<br />
| The identifier of the criterion.<br />
|-<br />
| Criterion progress<br />
| Criterion progress<br />
|<br />
|}<br />
<br />
Criterion progress:<br />
<br />
{| class="wikitable"<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
| Achieved<br />
| Boolean<br />
| If true, next field is present<br />
|-<br />
| Date of achieving<br />
| Optional Long<br />
| As returned by [https://docs.oracle.com/javase/6/docs/api/java/util/Date.html#getTime() <code>Date.getTime</code>]<br />
|}<br />
<br />
==== Entity Properties ====<br />
<br />
Sets {{Minecraft Wiki|Attribute|attributes}} on the given entity.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
!colspan="2"| Field Name<br />
!colspan="2"| Field Type<br />
! Notes<br />
|-<br />
|rowspan="6"| 0x4D<br />
|rowspan="6"| Play<br />
|rowspan="6"| Client<br />
|colspan="2"| Entity ID<br />
|colspan="2"| VarInt<br />
| <br />
|-<br />
|colspan="2"| Number Of Properties<br />
|colspan="2"| Int<br />
| Number of elements in the following array<br />
|-<br />
|rowspan="4"| Property<br />
| Key<br />
|rowspan="4"| Array<br />
| String (64)<br />
| See below<br />
|-<br />
| Value<br />
| Double<br />
| See below<br />
|-<br />
| Number Of Modifiers<br />
| VarInt<br />
| Number of elements in the following array<br />
|-<br />
| Modifiers<br />
| Array of Modifier Data<br />
| See {{Minecraft Wiki|Attribute#Modifiers}}. Modifier Data defined below.<br />
|}<br />
<br />
Known Key values (see also {{Minecraft Wiki|Attribute#Modifiers}}):<br />
<br />
{| class="wikitable"<br />
|-<br />
! Key<br />
! Default<br />
! Min<br />
! Max<br />
! Label<br />
|-<br />
| generic.maxHealth<br />
| 20.0<br />
| 0.0<br />
| 1024.0<br />
| Max Health<br />
|-<br />
| generic.followRange<br />
| 32.0<br />
| 0.0<br />
| 2048.0<br />
| Follow Range<br />
|-<br />
| generic.knockbackResistance<br />
| 0.0 <br />
| 0.0<br />
| 1.0<br />
| Knockback Resistance<br />
|-<br />
| generic.movementSpeed<br />
| 0.699999988079071<br />
| 0.0<br />
| 1024.0<br />
| Movement Speed<br />
|-<br />
| generic.attackDamage<br />
| 2.0<br />
| 0.0<br />
| 2048.0<br />
| Attack Damage<br />
|-<br />
| generic.attackSpeed<br />
| 4.0<br />
| 0.0<br />
| 1024.0<br />
| Attack Speed<br />
|-<br />
| generic.flyingSpeed<br />
| 0.4000000059604645<br />
| 0.0<br />
| 1024.0<br />
| Flying Speed<br />
|-<br />
| horse.jumpStrength<br />
| 0.7<br />
| 0.0<br />
| 2.0<br />
| Jump Strength<br />
|-<br />
| zombie.spawnReinforcements<br />
| 0.0<br />
| 0.0<br />
| 1.0<br />
| Spawn Reinforcements Chance<br />
|}<br />
<br />
''Modifier Data'' structure:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
| UUID<br />
| UUID<br />
| <br />
|-<br />
| Amount<br />
| Double<br />
| May be positive or negative<br />
|-<br />
| Operation<br />
| Byte<br />
| See below<br />
|}<br />
<br />
The operation controls how the base value of the modifier is changed.<br />
<br />
* 0: Add/subtract amount<br />
* 1: Add/subtract amount percent of the current value<br />
* 2: Multiply by amount percent<br />
<br />
All of the 0's are applied first, and then the 1's, and then the 2's.<br />
<br />
==== Entity Effect ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="5"| 0x4E<br />
|rowspan="5"| Play<br />
|rowspan="5"| Client<br />
| Entity ID<br />
| VarInt<br />
| <br />
|-<br />
| Effect ID<br />
| Byte<br />
| See {{Minecraft Wiki|Status effect#List of effects|this table}}<br />
|-<br />
| Amplifier<br />
| Byte<br />
| Notchian client displays effect level as Amplifier + 1<br />
|-<br />
| Duration<br />
| VarInt<br />
| Seconds<br />
|-<br />
| Flags<br />
| Byte<br />
| Bit field, see below.<br />
|}<br />
<br />
Within flags:<br />
<br />
* 0x01: Is ambient - was the effect spawned from a beacon? All beacon-generated effects are ambient. Ambient effects use a different icon in the HUD (blue border rather than gray). If all effects on an entity are ambient, the [[Entities#Living|"Is potion effect ambient" living metadata field]] should be set to true. Usually should not be enabled.<br />
* 0x02: Show particles - should all particles from this effect be hidden? Effects with particles hidden are not included in the calculation of the effect color, and are not rendered on the HUD (but are still rendered within the inventory). Usually should be enabled.<br />
<br />
=== Serverbound ===<br />
<br />
==== Teleport Confirm ====<br />
<br />
Sent by client as confirmation of [[#Player Position And Look (clientbound)|Player Position And Look]] ([[#Play|Play]], 0x2E, clientbound).<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
| 0x00<br />
| Play<br />
| Server<br />
| Teleport ID<br />
| VarInt<br />
| The ID given by the [[#Player Position And Look (clientbound)|Player Position And Look]] packet<br />
|}<br />
<br />
==== Prepare Crafting Grid ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
!colspan="2"| Field Name<br />
!colspan="2"| Field Type<br />
! Notes<br />
|-<br />
|rowspan="12"| 0x01<br />
|rowspan="12"| Play<br />
|rowspan="12"| Server<br />
|colspan="2"| Window ID<br />
|colspan="2"| Byte<br />
| The window id.<br />
|-<br />
|colspan="2"| Action number<br />
|colspan="2"| Short<br />
| The transaction number. Will be send to the client in a Confirm Transaction packet.<br />
|-<br />
|colspan="2"| Array size<br />
|colspan="2"| Short<br />
| Number of elements in the following array<br />
|-<br />
|rowspan="3"| Return Entry<br />
| Item<br />
|rowspan="3"| Array<br />
| Slot<br />
| The item stack that will be put in the inventory slot<br />
|-<br />
| Crafting Slot<br />
| Byte<br />
| The crafting slot index in the active container<br />
|-<br />
| Player Slot<br />
| Byte<br />
| The player slot index in the player inventory<br />
|-<br />
|colspan="2"| Array Size<br />
|colspan="2"| Short<br />
| Number of elements in the following array<br />
|-<br />
|rowspan="3"| Prepare Entry<br />
| Item<br />
|rowspan="3"| Array<br />
| Slot<br />
| The item stack that will be put in the crafting slot<br />
|-<br />
| Crafting Slot<br />
| Byte<br />
| The crafting slot index in the active container<br />
|-<br />
| Player Slot<br />
| Byte<br />
| The player slot index in the player inventory<br />
|}<br />
<br />
This packet is send when a player clicks a recipe in the crafting book that is craftable (white border).<br />
<br />
1. Return Entries:<br />
* All the items on the crafting slot are set to null/empty.<br />
* Every entry item stack will be added to the player inventory, to the specific player slot.<br />
<br />
2. Prepare Entries:<br />
* All the items on the player inventory slots their quantity is decreased by 1.<br />
* Every entry item stack will be put in the proper crafting grid slot.<br />
<br />
The server will send a Confirm Transaction packet back to the client with the provided transaction id.<br />
<br />
<br />
==== Tab-Complete (serverbound) ====<br />
<br />
Sent when the user presses ''tab'' while writing text.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="4"| 0x02<br />
|rowspan="4"| Play<br />
|rowspan="4"| Server<br />
| Text<br />
| String (32767)<br />
| All text behind the cursor (e.g. to the left of the cursor in left-to-right languages like English)<br />
|-<br />
| Assume Command<br />
| Boolean<br />
| If true, the server will parse Text as a command even if it doesn't start with a <code>/</code>. Used in the command block GUI.<br />
|-<br />
| Has Position<br />
| Boolean<br />
| <br />
|-<br />
| Looked At Block<br />
| Optional Position<br />
| The position of the block being looked at. Only sent if Has Position is true.<br />
|}<br />
<br />
==== Chat Message (serverbound) ====<br />
<br />
Used to send a chat message to the server. The message may not be longer than 256 characters or else the server will kick the client.<br />
<br />
If the message starts with a <code>/</code>, the server will attempt to interpret it as a command. Otherwise, the server will broadcast the same chat message to all players on the server (including the player that sent the message), prepended with player's name. Specifically, it will respond with a translate [[chat]] component, "<code>chat.type.text</code>" with the first parameter set to the display name of the player (including some chat component logic to support clicking the name to send a PM) and the second parameter set to the message. See [[Chat#Processing chat|processing chat]] for more information.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x03<br />
|rowspan="1"| Play<br />
|rowspan="1"| Server<br />
| Message<br />
| String (256)<br />
| The client sends the raw input, not a [[Chat]] component<br />
|}<br />
<br />
==== Client Status ====<br />
<br />
Sent when the client is ready to complete login and when the client is ready to respawn after death.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x04<br />
|rowspan="1"| Play<br />
|rowspan="1"| Server<br />
| Action ID<br />
| VarInt Enum<br />
| See below<br />
|}<br />
<br />
''Action ID'' values:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Action ID<br />
! Action<br />
|-<br />
| 0<br />
| Perform respawn<br />
|-<br />
| 1<br />
| Request stats<br />
|}<br />
<br />
==== Client Settings ====<br />
<br />
Sent when the player connects, or when settings are changed.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="6"| 0x05<br />
|rowspan="6"| Play<br />
|rowspan="6"| Server<br />
| Locale<br />
| String (16)<br />
| e.g. en_GB<br />
|-<br />
| View Distance<br />
| Byte<br />
| Client-side render distance, in chunks<br />
|-<br />
| Chat Mode<br />
| VarInt Enum<br />
| 0: enabled, 1: commands only, 2: hidden. See [[Chat#Processing chat|processing chat]] for more information.<br />
|-<br />
| Chat Colors<br />
| Boolean<br />
| “Colors” multiplayer setting<br />
|-<br />
| Displayed Skin Parts<br />
| Unsigned Byte<br />
| Bit mask, see below<br />
|-<br />
| Main Hand<br />
| VarInt Enum<br />
| 0: Left, 1: Right<br />
|}<br />
<br />
''Displayed Skin Parts'' flags:<br />
<br />
* Bit 0 (0x01): Cape enabled<br />
* Bit 1 (0x02): Jacket enabled<br />
* Bit 2 (0x04): Left Sleeve enabled<br />
* Bit 3 (0x08): Right Sleeve enabled<br />
* Bit 4 (0x10): Left Pants Leg enabled<br />
* Bit 5 (0x20): Right Pants Leg enabled<br />
* Bit 6 (0x40): Hat enabled<br />
<br />
The most significant bit (bit 7, 0x80) appears to be unused.<br />
<br />
==== Confirm Transaction (serverbound) ====<br />
<br />
If a transaction sent by the client was not accepted, the server will reply with a [[#Confirm Transaction (clientbound)|Confirm Transaction (clientbound)]] packet with the Accepted field set to false. When this happens, the client must send this packet to apologize (as with movement), otherwise the server ignores any successive transactions.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x06<br />
|rowspan="3"| Play<br />
|rowspan="3"| Server<br />
| Window ID<br />
| Byte<br />
| The ID of the window that the action occurred in<br />
|-<br />
| Action Number<br />
| Short<br />
| Every action that is to be accepted has a unique number. This number is an incrementing integer (starting at 1) with separate counts for each window ID.<br />
|-<br />
| Accepted<br />
| Boolean<br />
| Whether the action was accepted<br />
|}<br />
<br />
==== Enchant Item ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x07<br />
|rowspan="2"| Play<br />
|rowspan="2"| Server<br />
| Window ID<br />
| Byte<br />
| The ID of the enchantment table window sent by [[#Open Window|Open Window]]<br />
|-<br />
| Enchantment<br />
| Byte<br />
| The position of the enchantment on the enchantment table window, starting with 0 as the topmost one<br />
|}<br />
<br />
==== Click Window ====<br />
<br />
This packet is sent by the player when it clicks on a slot in a window.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="6"| 0x08<br />
|rowspan="6"| Play<br />
|rowspan="6"| Server<br />
| Window ID<br />
| Unsigned Byte<br />
| The ID of the window which was clicked. 0 for player inventory.<br />
|-<br />
| Slot<br />
| Short<br />
| The clicked slot number, see below<br />
|-<br />
| Button<br />
| Byte<br />
| The button used in the click, see below<br />
|-<br />
| Action Number<br />
| Short<br />
| A unique number for the action, implemented by Notchian as a counter, starting at 1 (different counter for every window ID). Used by the server to send back a [[#Confirm Transaction (clientbound)|Confirm Transaction (clientbound)]].<br />
|-<br />
| Mode<br />
| VarInt Enum<br />
| Inventory operation mode, see below<br />
|-<br />
| Clicked item<br />
| [[Slot Data|Slot]]<br />
| The clicked slot. Has to be empty (item ID = -1) for drop mode.<br />
|}<br />
<br />
See [[Inventory]] for further information about how slots are indexed.<br />
<br />
When right-clicking on a stack of items, half the stack will be picked up and half left in the slot. If the stack is an odd number, the half left in the slot will be smaller of the amounts.<br />
<br />
The distinct type of click performed by the client is determined by the combination of the Mode and Button fields.<br />
<br />
{| class="wikitable"<br />
! Mode<br />
! Button<br />
! Slot<br />
! Trigger<br />
|-<br />
!rowspan="2"| 0<br />
| 0<br />
| Normal<br />
| Left mouse click<br />
|-<br />
| 1<br />
| Normal<br />
| Right mouse click<br />
|-<br />
!rowspan="2"| 1<br />
| 0<br />
| Normal<br />
| Shift + left mouse click<br />
|-<br />
| 1<br />
| Normal<br />
| Shift + right mouse click ''(identical behavior)''<br />
|-<br />
!rowspan="5"| 2<br />
| 0<br />
| Normal<br />
| Number key 1<br />
|-<br />
| 1<br />
| Normal<br />
| Number key 2<br />
|-<br />
| 2<br />
| Normal<br />
| Number key 3<br />
|-<br />
| ⋮<br />
| ⋮<br />
| ⋮<br />
|-<br />
| 8<br />
| Normal<br />
| Number key 9<br />
|-<br />
!rowspan="1"| 3<br />
| 2<br />
| Normal<br />
| Middle click, only defined for creative players in non-player inventories.<br />
|-<br />
!rowspan="4"| 4<br />
| 0<br />
| Normal*<br />
| Drop key (Q) (* Clicked item is different, see above)<br />
|-<br />
| 1<br />
| Normal*<br />
| Ctrl + Drop key (Ctrl-Q) ''(drops full stack)''<br />
|-<br />
| 0<br />
| -999<br />
| Left click outside inventory holding nothing ''(no-op)''<br />
|-<br />
| 1<br />
| -999<br />
| Right click outside inventory holding nothing ''(no-op)''<br />
|-<br />
!rowspan="9"| 5<br />
| 0<br />
| -999<br />
| Starting left mouse drag<br />
|-<br />
| 4<br />
| -999<br />
| Starting right mouse drag<br />
|-<br />
| 8<br />
| -999<br />
| Starting middle mouse drag, only defined for creative players in non-player inventories. (Note: the vanilla client will still incorrectly send this for non-creative players - see [https://bugs.mojang.com/browse/MC-46584 MC-46584])<br />
|-<br />
| 1<br />
| Normal<br />
| Add slot for left-mouse drag<br />
|-<br />
| 5<br />
| Normal<br />
| Add slot for right-mouse drag<br />
|-<br />
| 9<br />
| Normal<br />
| Add slot for middle-mouse drag, only defined for creative players in non-player inventories. (Note: the vanilla client will still incorrectly send this for non-creative players - see [https://bugs.mojang.com/browse/MC-46584 MC-46584])<br />
|-<br />
| 2<br />
| -999<br />
| Ending left mouse drag<br />
|-<br />
| 6<br />
| -999<br />
| Ending right mouse drag<br />
|-<br />
| 10<br />
| -999<br />
| Ending middle mouse drag, only defined for creative players in non-player inventories. (Note: the vanilla client will still incorrectly send this for non-creative players - see [https://bugs.mojang.com/browse/MC-46584 MC-46584])<br />
|-<br />
! 6<br />
| 0<br />
| Normal<br />
| Double click<br />
|}<br />
<br />
Starting from version 1.5, “painting mode” is available for use in inventory windows. It is done by picking up stack of something (more than 1 item), then holding mouse button (left, right or middle) and dragging held stack over empty (or same type in case of right button) slots. In that case client sends the following to server after mouse button release (omitting first pickup packet which is sent as usual):<br />
<br />
# packet with mode 5, slot -999, button (0 for left | 4 for right);<br />
# packet for every slot painted on, mode is still 5, button (1 | 5);<br />
# packet with mode 5, slot -999, button (2 | 6);<br />
<br />
If any of the painting packets other than the “progress” ones are sent out of order (for example, a start, some slots, then another start; or a left-click in the middle) the painting status will be reset.<br />
<br />
The server will send back a [[#Confirm Transaction (clientbound)|Confirm Transaction]] packet. If the click was not accepted, the client must send a matching [[#Confirm Transaction (serverbound)|serverbound confirm transaction]] packet before sending more [[#Click Window|Click Window]] packets, otherwise the server will reject them silently. The Notchian server also sends a [[#Window Items|Window Items]] packet for the open window and [[#Set Slot|Set Slot]] packets for the clicked and cursor slot, but only when the click was not accepted, probably to resynchronize client and server.<br />
<br />
==== Close Window (serverbound) ====<br />
<br />
This packet is sent by the client when closing a window.<br />
<br />
Notchian clients send a Close Window packet with Window ID 0 to close their inventory even though there is never an [[#Open Window|Open Window]] packet for the inventory.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
| 0x09<br />
| Play<br />
| Server<br />
| Window ID<br />
| Unsigned Byte<br />
| This is the ID of the window that was closed. 0 for player inventory.<br />
|}<br />
<br />
==== Plugin Message (serverbound) ====<br />
<br />
{{Main|Plugin channels}}<br />
<br />
Mods and plugins can use this to send their data. Minecraft itself uses a number of [[plugin channel]]s. These internal channels are prefixed with <code>MC|</code>.<br />
<br />
More documentation on this: [http://dinnerbone.com/blog/2012/01/13/minecraft-plugin-channels-messaging/ http://dinnerbone.com/blog/2012/01/13/minecraft-plugin-channels-messaging/]<br />
<br />
Note that the length of Data is known only from the packet length, since the packet has no length field of any kind.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x0A<br />
|rowspan="2"| Play<br />
|rowspan="2"| Server<br />
| Channel<br />
| String (20)<br />
| Name of the [[plugin channel]] used to send the data<br />
|-<br />
| Data<br />
| Byte Array<br />
| Any data, depending on the channel. <code><nowiki>MC|</nowiki></code> channels are documented [[plugin channel|here]]. The length of this array must be inferred from the packet length.<br />
|}<br />
<br />
==== Use Entity ====<br />
<br />
This packet is sent from the client to the server when the client attacks or right-clicks another entity (a player, minecart, etc).<br />
<br />
A Notchian server only accepts this packet if the entity being attacked/used is visible without obstruction and within a 4-unit radius of the player's position.<br />
<br />
Note that middle-click in creative mode is interpreted by the client and sent as a [[#Creative Inventory Action|Creative Inventory Action]] packet instead.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="6"| 0x0B<br />
|rowspan="6"| Play<br />
|rowspan="6"| Server<br />
| Target<br />
| VarInt<br />
| <br />
|-<br />
| Type<br />
| VarInt Enum<br />
| 0: interact, 1: attack, 2: interact at<br />
|-<br />
| Target X<br />
| Optional Float<br />
| Only if Type is interact at<br />
|-<br />
| Target Y<br />
| Optional Float<br />
| Only if Type is interact at<br />
|-<br />
| Target Z<br />
| Optional Float<br />
| Only if Type is interact at<br />
|-<br />
| Hand<br />
| Optional VarInt Enum<br />
| Only if Type is interact or interact at; 0: main hand, 1: off hand<br />
|}<br />
<br />
==== Keep Alive (serverbound) ====<br />
<br />
The server will frequently send out a keep-alive, each containing a random ID. The client must respond with the same packet.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
| 0x0C<br />
| Play<br />
| Server<br />
| Keep Alive ID<br />
| VarInt<br />
| <br />
|}<br />
<br />
==== Player ====<br />
<br />
This packet as well as [[#Player Position|Player Position]] ([[#Play|Play]], 0x04, serverbound), [[#Player Look|Player Look]] ([[#Play|Play]], 0x05, serverbound), and [[#Player Position And Look 2|Player Position And Look]] ([[#Play|Play]], 0x06, serverbound) are called the “serverbound movement packets”. Vanilla clients will send Player Position once every 20 ticks even for a stationary player.<br />
<br />
This packet is used to indicate whether the player is on ground (walking/swimming), or airborne (jumping/falling).<br />
<br />
When dropping from sufficient height, fall damage is applied when this state goes from false to true. The amount of damage applied is based on the point where it last changed from true to false. Note that there are several movement related packets containing this state.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x0D<br />
|rowspan="1"| Play<br />
|rowspan="1"| Server<br />
| On Ground<br />
| Boolean<br />
| True if the client is on the ground, false otherwise<br />
|}<br />
<br />
==== Player Position ====<br />
<br />
Updates the player's XYZ position on the server.<br />
<br />
Checking for moving too fast is achieved like this:<br />
<br />
* Each server tick, the player's current position is stored<br />
* When a player moves, the changes in x, y, and z coordinates are compared with the positions from the previous tick (&Delta;x, &Delta;y, &Delta;z)<br />
* Total movement distance squared is computed as &Delta;x&sup2; + &Delta;y&sup2; + &Delta;z&sup2;<br />
* The expected movement distance squared is computed as velocityX&sup2; + veloctyY&sup2; + velocityZ&sup2;<br />
* If the total movement distance squared value minus the expected movement distance squared value is more than 100 (300 if the player is using an elytra), they are moving too fast.<br />
<br />
If the player is moving too fast, it will be logged that "<player> moved too quickly! " followed by the change in x, y, and z, and the player will be teleported back to their current (before this packet) serverside position.<br />
<br />
Also, if the absolute value of X or the absolute value of Z is a value greater than 3.2×10<sup>7</sup>, or X, Y, or Z are not finite (either positive infinity, negative infinity, or NaN), the client will be kicked for “Invalid move player packet received”.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="4"| 0x0E<br />
|rowspan="4"| Play<br />
|rowspan="4"| Server<br />
| X<br />
| Double<br />
| Absolute position<br />
|-<br />
| Feet Y<br />
| Double<br />
| Absolute feet position, normally Head Y - 1.62 <br />
|-<br />
| Z<br />
| Double<br />
| Absolute position<br />
|-<br />
| On Ground<br />
| Boolean<br />
| True if the client is on the ground, false otherwise<br />
|}<br />
<br />
==== Player Position And Look (serverbound) ====<br />
<br />
A combination of [[#Player Look|Player Look]] and [[#Player Position|Player Position]].<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="6"| 0x0F<br />
|rowspan="6"| Play<br />
|rowspan="6"| Server<br />
| X<br />
| Double<br />
| Absolute position<br />
|-<br />
| Feet Y<br />
| Double<br />
| Absolute feet position, normally Head Y - 1.62<br />
|-<br />
| Z<br />
| Double<br />
| Absolute position<br />
|-<br />
| Yaw<br />
| Float<br />
| Absolute rotation on the X Axis, in degrees<br />
|-<br />
| Pitch<br />
| Float<br />
| Absolute rotation on the Y Axis, in degrees<br />
|-<br />
| On Ground<br />
| Boolean<br />
| True if the client is on the ground, false otherwise<br />
|}<br />
<br />
==== Player Look ====<br />
[[File:Minecraft-trig-yaw.png|thumb|The unit circle for yaw]]<br />
[[File:Yaw.png|thumb|The unit circle of yaw, redrawn]]<br />
<br />
Updates the direction the player is looking in.<br />
<br />
Yaw is measured in degrees, and does not follow classical trigonometry rules. The unit circle of yaw on the XZ-plane starts at (0, 1) and turns counterclockwise, with 90 at (-1, 0), 180 at (0,-1) and 270 at (1, 0). Additionally, yaw is not clamped to between 0 and 360 degrees; any number is valid, including negative numbers and numbers greater than 360.<br />
<br />
Pitch is measured in degrees, where 0 is looking straight ahead, -90 is looking straight up, and 90 is looking straight down.<br />
<br />
The yaw and pitch of player (in degrees), standing at point (x0, y0, z0) and looking towards point (x, y, z) can be calculated with:<br />
<br />
dx = x-x0<br />
dy = y-y0<br />
dz = z-z0<br />
r = sqrt( dx*dx + dy*dy + dz*dz )<br />
yaw = -atan2(dx,dz)/PI*180<br />
if yaw < 0 then<br />
yaw = 360 - yaw<br />
pitch = -arcsin(dy/r)/PI*180<br />
<br />
You can get a unit vector from a given yaw/pitch via:<br />
<br />
x = -cos(pitch) * sin(yaw)<br />
y = -sin(pitch)<br />
z = cos(pitch) * cos(yaw)<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x10<br />
|rowspan="3"| Play<br />
|rowspan="3"| Server<br />
| Yaw<br />
| Float<br />
| Absolute rotation on the X Axis, in degrees<br />
|-<br />
| Pitch<br />
| Float<br />
| Absolute rotation on the Y Axis, in degrees<br />
|-<br />
| On Ground<br />
| Boolean<br />
| True if the client is on the ground, False otherwise<br />
|}<br />
<br />
==== Vehicle Move (serverbound) ====<br />
<br />
Sent when a player moves in a vehicle. Fields are the same as in [[#Player Position And Look (serverbound)|Player Position And Look]] ([[#Play|Play]], 0x2E, serverbound). Note that all fields use absolute positioning and do not allow for relative positioning.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="7"| 0x11<br />
|rowspan="7"| Play<br />
|rowspan="7"| Server<br />
| X<br />
| Double<br />
| Absolute position (X coordinate)<br />
|-<br />
| Y<br />
| Double<br />
| Absolute position (Y coordinate)<br />
|-<br />
| Z<br />
| Double<br />
| Absolute position (Z coordinate)<br />
|-<br />
| Yaw<br />
| Float<br />
| Absolute rotation on the vertical axis, in degrees<br />
|-<br />
| Pitch<br />
| Float<br />
| Absolute rotation on the horizontal axis, in degrees<br />
|}<br />
<br />
==== Steer Boat ====<br />
<br />
Used to ''visually'' update whether boat paddles are turning. The server will update the [[Entities#Boat|Boat entity metadata]] to match the values here.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x12<br />
|rowspan="2"| Play<br />
|rowspan="2"| Server<br />
| Right paddle turning<br />
| Boolean<br />
|<br />
|-<br />
| Left paddle turning<br />
| Boolean<br />
|<br />
|}<br />
<br />
Right paddle turning is set to true when the left button or forward button is held; left paddle turning is set to true when the right button or forward button is set to true.<br />
<br />
==== Player Abilities (serverbound) ====<br />
<br />
The latter 2 bytes are used to indicate the walking and flying speeds respectively, while the first byte is used to determine the value of 4 booleans.<br />
<br />
The vanilla client sends this packet when the player starts/stops flying with the Flags parameter changed accordingly. All other parameters are ignored by the vanilla server.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x13<br />
|rowspan="3"| Play<br />
|rowspan="3"| Server<br />
| Flags<br />
| Byte<br />
| Bit mask. 0x08: damage disabled (god mode), 0x04: can fly, 0x02: is flying, 0x01: is Creative<br />
|-<br />
| Flying Speed<br />
| Float<br />
| <br />
|-<br />
| Walking Speed<br />
| Float<br />
| <br />
|}<br />
<br />
==== Player Digging ====<br />
<br />
Sent when the player mines a block. A Notchian server only accepts digging packets with coordinates within a 6-unit radius between the center of the block and 1.5 units from the player's feet (''not'' their eyes).<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x14<br />
|rowspan="3"| Play<br />
|rowspan="3"| Server<br />
| Status<br />
| VarInt Enum<br />
| The action the player is taking against the block (see below)<br />
|-<br />
| Location<br />
| Position<br />
| Block position<br />
|-<br />
| Face<br />
| Byte Enum<br />
| The face being hit (see below)<br />
|}<br />
<br />
Status can be one of seven values:<br />
<br />
{| class="wikitable"<br />
! Value<br />
! Meaning<br />
! Notes<br />
|-<br />
| 0<br />
| Started digging<br />
| <br />
|-<br />
| 1<br />
| Cancelled digging<br />
| Sent when the player lets go of the Mine Block key (default: left click)<br />
|-<br />
| 2<br />
| Finished digging<br />
| Sent when the client thinks it is finished<br />
|-<br />
| 3<br />
| Drop item stack<br />
| Triggered by using the Drop Item key (default: Q) with the modifier to drop the entire selected stack (default: depends on OS). Location is always set to 0/0/0, Face is always set to -Y.<br />
|-<br />
| 4<br />
| Drop item<br />
| Triggered by using the Drop Item key (default: Q). Location is always set to 0/0/0, Face is always set to -Y.<br />
|-<br />
| 5<br />
| Shoot arrow / finish eating<br />
| Location is always set to 0/0/0, Face is always set to Special.<br />
|-<br />
| 6<br />
| Swap item in hand<br />
| Used to swap or assign an item to the second hand. Location is always set to 0/0/0, Face is always set to -Y.<br />
|}<br />
<br />
The Face field can be one of the following values, representing the face being hit (or the Special value used for “shoot arrow / finish eating”):<br />
<br />
{| class="wikitable"<br />
|-<br />
! Value<br />
! Offset<br />
! Face<br />
|-<br />
| 0<br />
| -Y<br />
| Bottom<br />
|-<br />
| 1<br />
| +Y<br />
| Top<br />
|-<br />
| 2<br />
| -Z<br />
| North<br />
|-<br />
| 3<br />
| +Z<br />
| South<br />
|-<br />
| 4<br />
| -X<br />
| West<br />
|-<br />
| 5<br />
| +X<br />
| East<br />
|-<br />
| 255<br />
| —<br />
| Special<br />
|}<br />
<br />
==== Entity Action ====<br />
<br />
Sent by the client to indicate that it has performed certain actions: sneaking (crouching), sprinting, exiting a bed, jumping with a horse, and opening a horse's inventory while riding it.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x15<br />
|rowspan="3"| Play<br />
|rowspan="3"| Server<br />
| Entity ID<br />
| VarInt<br />
| Player ID<br />
|-<br />
| Action ID<br />
| VarInt Enum<br />
| The ID of the action, see below<br />
|-<br />
| Jump Boost<br />
| VarInt<br />
| Only used by the “start jump with horse” action, in which case it ranges from 0 to 100. In all other cases it is 0.<br />
|}<br />
<br />
Action ID can be one of the following values:<br />
<br />
{| class="wikitable"<br />
! ID<br />
! Action<br />
|-<br />
| 0<br />
| Start sneaking<br />
|-<br />
| 1<br />
| Stop sneaking<br />
|-<br />
| 2<br />
| Leave bed<br />
|-<br />
| 3<br />
| Start sprinting<br />
|-<br />
| 4<br />
| Stop sprinting<br />
|-<br />
| 5<br />
| Start jump with horse<br />
|-<br />
| 6<br />
| Stop jump with horse<br />
|-<br />
| 7<br />
| Open horse inventory<br />
|-<br />
| 8<br />
| Start flying with elytra<br />
|}<br />
<br />
Leave bed is only sent when the “Leave Bed” button is clicked on the sleep GUI, not when waking up due today time.<br />
<br />
Open horse inventory is only sent when pressing the inventory key (default: E) while on a horse — all other methods of opening a horse's inventory (involving right-clicking or shift-right-clicking it) do not use this packet.<br />
<br />
“Open inventory” is now sent via the [[#Client Status|Client Status]] ([[#Play|Play]], 0x03, serverbound) packet.<br />
<br />
==== Steer Vehicle ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x16<br />
|rowspan="3"| Play<br />
|rowspan="3"| Server<br />
| Sideways<br />
| Float<br />
| Positive to the left of the player<br />
|-<br />
| Forward<br />
| Float<br />
| Positive forward<br />
|-<br />
| Flags<br />
| Unsigned Byte<br />
| Bit mask. 0x1: jump, 0x2: unmount<br />
|}<br />
<br />
Also known as 'Input' packet.<br />
<br />
==== Crafting Book Data ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
!colspan="2"| Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="5"| 0x17<br />
|rowspan="5"| Play<br />
|rowspan="5"| Server<br />
|colspan="2"| Type<br />
| VarInt<br />
| Determines the format of the rest of the packet<br />
|-<br />
! Type<br />
! Field Name<br />
! <br />
! <br />
|-<br />
| 0: Displayed Recipe<br />
| Recipe ID<br />
| Int<br />
| The internal id of the displayed recipe.<br />
|-<br />
|rowspan="2"| 1: Crafting Book Status<br />
| Crafting Book Open<br />
| Boolean<br />
| Whether the player has the crafting book currently openened/active.<br />
|-<br />
| Crafting Filter<br />
| Boolean<br />
| Whether the player has the crafting filter option currently active.<br />
|}<br />
<br />
The Crafting Book Status type is send when the player closes its inventory.<br />
<br />
==== Resource Pack Status ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x18<br />
|rowspan="2"| Play<br />
|rowspan="2"| Server<br />
| Result<br />
| VarInt Enum<br />
| 0: successfully loaded, 1: declined, 2: failed download, 3: accepted<br />
|}<br />
<br />
==== Advancement Tab ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x19<br />
|rowspan="2"| Play<br />
|rowspan="2"| Server<br />
| Action<br />
| VarInt enum<br />
| 0: Opened tab, 1: Closed screen<br />
|-<br />
| Tab ID<br />
| Optional identifier<br />
| Only present if action is Opened tab<br />
|}<br />
<br />
==== Held Item Change (serverbound) ====<br />
<br />
Sent when the player changes the slot selection<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x1A<br />
|rowspan="1"| Play<br />
|rowspan="1"| Server<br />
| Slot<br />
| Short<br />
| The slot which the player has selected (0–8)<br />
|}<br />
<br />
==== Creative Inventory Action ====<br />
<br />
While the user is in the standard inventory (i.e., not a crafting bench) in Creative mode, the player will send this packet.<br />
<br />
Clicking in the creative inventory menu is quite different from non-creative inventory management. Picking up an item with the mouse actually deletes the item from the server, and placing an item into a slot or dropping it out of the inventory actually tells the server to create the item from scratch. (This can be verified by clicking an item that you don't mind deleting, then severing the connection to the server; the item will be nowhere to be found when you log back in.) As a result of this implementation strategy, the "Destroy Item" slot is just a client-side implementation detail that means "I don't intend to recreate this item.". Additionally, the long listings of items (by category, etc.) are a client-side interface for choosing which item to create. Picking up an item from such listings sends no packets to the server; only when you put it somewhere does it tell the server to create the item in that location.<br />
<br />
This action can be described as "set inventory slot". Picking up an item sets the slot to item ID -1. Placing an item into an inventory slot sets the slot to the specified item. Dropping an item (by clicking outside the window) effectively sets slot -1 to the specified item, which causes the server to spawn the item entity, etc.. All other inventory slots are numbered the same as the non-creative inventory (including slots for the 2x2 crafting menu, even though they aren't visible in the vanilla client).<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x1B<br />
|rowspan="2"| Play<br />
|rowspan="2"| Server<br />
| Slot<br />
| Short<br />
| Inventory slot<br />
|-<br />
| Clicked Item<br />
| [[Slot Data|Slot]]<br />
| <br />
|}<br />
<br />
==== Update Sign ====<br />
<br />
{{anchor|Update Sign (serverbound)}}This message is sent from the client to the server when the “Done” button is pushed after placing a sign.<br />
<br />
The server only accepts this packet after [[#Open Sign Editor|Open Sign Editor]] ([[#Play|Play]], 0x2A, clientbound), otherwise this packet is silently ignored.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="5"| 0x1C<br />
|rowspan="5"| Play<br />
|rowspan="5"| Server<br />
| Location<br />
| Position<br />
| Block Coordinates<br />
|-<br />
| Line 1<br />
| String (384)<br />
| First line of text in the sign<br />
|-<br />
| Line 2<br />
| String (384)<br />
| Second line of text in the sign<br />
|-<br />
| Line 3<br />
| String (384)<br />
| Third line of text in the sign<br />
|-<br />
| Line 4<br />
| String (384)<br />
| Fourth line of text in the sign<br />
|}<br />
<br />
==== Animation (serverbound) ====<br />
<br />
Sent when the player's arm swings.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
| 0x1D<br />
| Play<br />
| Server<br />
| Hand<br />
| VarInt Enum<br />
| Hand used for the animation. 0: main hand, 1: off hand.<br />
|}<br />
<br />
==== Spectate ====<br />
<br />
Teleports the player to the given entity. The player must be in spectator mode.<br />
<br />
The Notchian client only uses this to teleport to players, but it appears to accept any type of entity. The entity does not need to be in the same dimension as the player; if necessary, the player will be respawned in the right world. If the given entity cannot be found (or isn't loaded), this packet will be ignored. It will also be ignored if the player attempts to teleport to themselves.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x1E<br />
|rowspan="1"| Play<br />
|rowspan="1"| Server<br />
| Target Player<br />
| UUID<br />
| UUID of the player to teleport to (can also be an entity UUID)<br />
|}<br />
<br />
==== Player Block Placement ====<br />
<br />
{| class="wikitable"<br />
|-<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="6"| 0x1F<br />
|rowspan="6"| Play<br />
|rowspan="6"| Server<br />
| Location<br />
| Position<br />
| Block position<br />
|-<br />
| Face<br />
| VarInt Enum<br />
| The face on which the block is placed (as documented at [[#Player Digging|Player Digging]])<br />
|-<br />
| Hand<br />
| VarInt Enum<br />
| The hand from which the block is placed; 0: main hand, 1: off hand<br />
|-<br />
| Cursor Position X<br />
| Float<br />
| The position of the crosshair on the block, from 0 to 1 increasing from west to east<br />
|-<br />
| Cursor Position Y<br />
| Float<br />
| The position of the crosshair on the block, from 0 to 1 increasing from bottom to top<br />
|-<br />
| Cursor Position Z<br />
| Float<br />
| The position of the crosshair on the block, from 0 to 1 increasing from north to south<br />
|}<br />
<br />
In normal operation (i.e. placing a block), this packet is sent once, with the values set normally.<br />
<br />
The Cursor Position X/Y/Z fields (also known as in-block coordinates) are calculated using raytracing. The unit corresponds to sixteen pixel in the default resource pack. For example, let's say a slab is being placed against the south face of a full block. The Cursor Position X will be higher if the player was pointing near the right (east) edge of the face, lower if pointing near the left. The Cursor Position Y will be used to determine whether it will appear as a bottom slab (values 0.0–0.5) or as a top slab (values 0.5-1.0). The Cursor Position Z should be 1.0 since the player was looking at the southernmost part of the block.<br />
<br />
This packet has a special case where X, Y, Z, and Face are all -1. (Note that Y is unsigned so set to 255.) This special packet indicates that the currently held item for the player should have its state updated such as eating food, pulling back bows, using buckets, etc.<br />
<br />
Special note on using buckets: When using buckets, the Notchian client might send two packets: first a normal and then a special case. The first normal packet is sent when you're looking at a block (e.g. the water you want to scoop up). This normal packet does not appear to do anything with a Notchian server. The second, special case packet appears to perform the action — based on current position/orientation and with a distance check — it appears that buckets can only be used within a radius of 6 units.<br />
<br />
==== Use Item ====<br />
<br />
Sent when pressing the Use Item key (default: right click) with an item in hand.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
| 0x20<br />
| Play<br />
| Server<br />
| Hand<br />
| VarInt Enum<br />
| Hand used for the animation. 0: main hand, 1: off hand.<br />
|}<br />
<br />
== Status ==<br />
{{Main|Server List Ping}}<br />
<br />
=== Clientbound ===<br />
<br />
==== Response ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x00<br />
|rowspan="1"| Status<br />
|rowspan="1"| Client<br />
| JSON Response<br />
| String (32767)<br />
| See [[Server List Ping#Response]]<br />
|}<br />
<br />
==== Pong ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x01<br />
|rowspan="1"| Status<br />
|rowspan="1"| Client<br />
| Payload<br />
| Long<br />
| Should be the same as sent by the client<br />
|}<br />
<br />
=== Serverbound ===<br />
<br />
==== Request ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x00<br />
| Status<br />
| Server<br />
|colspan="3"| ''no fields''<br />
|}<br />
<br />
==== Ping ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x01<br />
|rowspan="1"| Status<br />
|rowspan="1"| Server<br />
| Payload<br />
| Long<br />
| May be any number. Notchian clients use a system-dependent time value which is counted in milliseconds.<br />
|}<br />
<br />
== Login ==<br />
<br />
The login process is as follows:<br />
<br />
# C→S: [[#Handshake|Handshake]] with Next State set to 2 (login)<br />
# C→S: [[#Login Start|Login Start]]<br />
# S→C: [[#Encryption Request|Encryption Request]]<br />
# Client auth<br />
# C→S: [[#Encryption Response|Encryption Response]]<br />
# Server auth, both enable encryption<br />
# S→C: [[#Set Compression|Set Compression]] (optional)<br />
# S→C: [[#Login Success|Login Success]]<br />
<br />
Set Compression, if present, must be sent before Login Success. Note that anything sent after Set Compression must use the [[#With_compression|Post Compression packet format]].<br />
<br />
For unauthenticated and localhost connections (either of the two conditions is enough for an unencrypted connection) there is no encryption. In that case [[#Login Start|Login Start]] is directly followed by [[#Login Success|Login Success]].<br />
<br />
See [[Protocol Encryption]] for details.<br />
<br />
=== Clientbound ===<br />
<br />
==== Disconnect (login) ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x00<br />
|rowspan="1"| Login<br />
|rowspan="1"| Client<br />
| Reason<br />
| [[Chat]]<br />
| <br />
|}<br />
<br />
==== Encryption Request ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="5"| 0x01<br />
|rowspan="5"| Login<br />
|rowspan="5"| Client<br />
| Server ID<br />
| String (20)<br />
| Appears to be empty<br />
|-<br />
| Public Key Length<br />
| VarInt<br />
| Length of Public Key<br />
|-<br />
| Public Key<br />
| Byte Array<br />
| <br />
|-<br />
| Verify Token Length<br />
| VarInt<br />
| Length of Verify Token. Always 4 for Notchian servers.<br />
|-<br />
| Verify Token<br />
| Byte Array<br />
| A sequence of random bytes generated by the server<br />
|}<br />
<br />
See [[Protocol Encryption]] for details.<br />
<br />
==== Login Success ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x02<br />
|rowspan="2"| Login<br />
|rowspan="2"| Client<br />
| UUID<br />
| String (36)<br />
| Unlike in other packets, this field contains the UUID as a string with hyphens.<br />
|-<br />
| Username<br />
| String (16)<br />
| <br />
|}<br />
<br />
This packet switches the connection state to [[#Play|play]].<br />
<br />
==== Set Compression ====<br />
<br />
Enables compression. If compression is enabled, all following packets are encoded in the [[#With compression|compressed packet format]]. Negative values will disable compression, meaning the packet format should remain in the [[#Without compression|uncompressed packet format]]. However, this packet is entirely optional, and if not sent, compression will also not be enabled (the notchian server does not send the packet when compression is disabled).<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x03<br />
|rowspan="1"| Login<br />
|rowspan="1"| Client<br />
| Threshold<br />
| VarInt<br />
| Maximum size of a packet before it is compressed<br />
|}<br />
<br />
=== Serverbound ===<br />
<br />
==== Login Start ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x00<br />
|rowspan="1"| Login<br />
|rowspan="1"| Server<br />
| Name<br />
| String (16)<br />
| Player's Username<br />
|}<br />
<br />
==== Encryption Response ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="4"| 0x01<br />
|rowspan="4"| Login<br />
|rowspan="4"| Server<br />
| Shared Secret Length<br />
| VarInt<br />
| Length of Shared Secret<br />
|-<br />
| Shared Secret<br />
| Byte Array<br />
| <br />
|-<br />
| Verify Token Length<br />
| VarInt<br />
| Length of Verify Token<br />
|-<br />
| Verify Token<br />
| Byte Array<br />
| <br />
|}<br />
<br />
See [[Protocol Encryption]] for details.<br />
<br />
[[Category:Protocol Details]]<br />
[[Category:Minecraft Modern]]</div>Janmm14https://wiki.vg/index.php?title=Protocol&diff=13153Protocol2017-07-01T13:01:52Z<p>Janmm14: "Player" (0x0D) is not sent every tick anymore if idle</p>
<hr />
<div>{{Box<br />
|BORDER = #9999FF<br />
|BACKGROUND = #99CCFF<br />
|WIDTH = 100%<br />
|ICON = <br />
|HEADING = Heads up!<br />
|CONTENT = This article is about the protocol for the latest '''stable''' release of Minecraft '''computer edition''' ([[Protocol version numbers|1.12, protocol 335]]). For the computer edition pre-releases, see [[Pre-release protocol]]. For Pocket Edition, see [[Pocket Edition Protocol Documentation]].<br />
}}<br />
<br />
This page presents a dissection of the current '''[https://minecraft.net/ Minecraft] protocol'''.<br />
<br />
If you're having trouble, check out the [[Protocol FAQ|FAQ]] or ask for help in the IRC channel ([irc://irc.freenode.net/mcdevs #mcdevs on chat.freenode.net]).<br />
<br />
'''Note:''' While you may use the contents of this page without restriction to create servers, clients, bots, etc… you still need to provide attribution to #mcdevs if you copy any of the contents of this page for publication elsewhere.<br />
<br />
The changes between versions may be viewed at [[Protocol History]].<br />
<br />
== Definitions ==<br />
<br />
The Minecraft server accepts connections from TCP clients and communicates with them using ''packets''. A packet is a sequence of bytes sent over the TCP connection. The meaning of a packet depends both on its packet ID and the current state of the connection. The initial state of each connection is [[#Handshaking|Handshaking]], and state is switched using the packets [[#Handshake|Handshake]] ([[#Handshaking|Handshaking]], 0x00, serverbound) and [[#Login Success|Login Success]] ([[#Login|Login]], 0x02, clientbound).<br />
<br />
=== Data types ===<br />
<br />
{{:Data types}} <!-- Transcluded contents of Data types article in here — go to that page if you want to edit it --><br />
<br />
=== Other definitions ===<br />
<br />
{| class="wikitable"<br />
|-<br />
! Term<br />
! Definition<br />
|-<br />
| Player<br />
| When used in the singular, Player always refers to the client connected to the server.<br />
|-<br />
| Entity<br />
| Entity refers to any item, player, mob, minecart or boat etc. See {{Minecraft Wiki|Entity|the Minecraft Wiki article}} for a full list.<br />
|-<br />
| EID<br />
| An EID — or Entity ID — is a 4-byte sequence used to identify a specific entity. An entity's EID is unique on the entire server.<br />
|-<br />
| XYZ<br />
| In this document, the axis names are the same as those shown in the debug screen (F3). Y points upwards, X points east, and Z points south.<br />
|-<br />
| Meter<br />
| The meter is Minecraft's base unit of length, equal to the length of a vertex of a solid block. The term “block” may be used to mean “meter” or “cubic meter”.<br />
|-<br />
| Global palette<br />
| A table/dictionary/palette mapping nonnegative integers to block states. The block state IDs can be constructed from {{Minecraft Wiki|Data values|this table}} by multiplying what the Minecraft Wiki calls “block IDs” by 16 and adding the metadata/damage value (or in most programming languages <code>block_id &lt;&lt; 4 <nowiki>|</nowiki> metadata</code>).<br />
|-<br />
| Notchian<br />
| The official implementation of vanilla Minecraft as developed and released by Mojang.<br />
|}<br />
<br />
== Packet format ==<br />
<br />
=== Without compression ===<br />
<br />
{| class="wikitable"<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
| Length<br />
| VarInt<br />
| Length of packet data + length of the packet ID<br />
|-<br />
| Packet ID<br />
| VarInt<br />
| <br />
|-<br />
| Data<br />
| Byte Array<br />
| Depends on the connection state and packet ID, see the sections below<br />
|}<br />
<br />
=== With compression ===<br />
<br />
Once a [[#Set Compression|Set Compression]] packet (with a non-negative threshold) is sent, [[wikipedia:Zlib|zlib]] compression is enabled for all following packets. The format of a packet changes slighty to include the size of the uncompressed packet.<br />
<br />
{| class=wikitable<br />
! Compressed?<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
| No<br />
| Packet Length<br />
| VarInt<br />
| Length of Data Length + compressed length of (Packet ID + Data)<br />
|-<br />
| No<br />
| Data Length<br />
| VarInt<br />
| Length of uncompressed (Packet ID + Data) or 0<br />
|-<br />
|rowspan="2"| Yes<br />
| Packet ID<br />
| Varint<br />
| zlib compressed packet ID (see the sections below)<br />
|-<br />
| Data<br />
| Byte Array<br />
| zlib compressed packet data (see the sections below)<br />
|}<br />
<br />
The length given by the Packet Length field is the number of bytes that remain in that packet, including the Data Length field.<br />
<br />
If Data Length is set to zero, then the packet is uncompressed; otherwise it is the size of the uncompressed packet.<br />
<br />
If compressed, the uncompressed length of (Packet ID + Data) must be equal to or over the threshold set in the packet [[#Set Compression 2|Set Compression]] ([[#Login|Login]], 0x03, clientbound), otherwise the receiving party will disconnect.<br />
<br />
Compression can be disabled by sending the packet [[#Set Compression|Set Compression]] ([[#Login|Login]], 0x03, clientbound) with a negative Threshold, or not sending the Set Compression packet at all.<br />
<br />
== Handshaking ==<br />
<br />
=== Clientbound ===<br />
<br />
There are no clientbound packets in the Handshaking state, since the protocol immediately switches to a different state after the client sends the first packet.<br />
<br />
=== Serverbound ===<br />
<br />
==== Handshake ====<br />
<br />
This causes the server to switch into the target state.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="4"| 0x00<br />
|rowspan="4"| Handshaking<br />
|rowspan="4"| Server<br />
| Protocol Version<br />
| VarInt<br />
| See [[protocol version numbers]] (currently 335 in Minecraft 1.12)<br />
|-<br />
| Server Address<br />
| String (255)<br />
| Hostname or IP, e.g. localhost or 127.0.0.1, that was used to connect. The Notchian server does not use this information.<br />
|- <br />
| Server Port<br />
| Unsigned Short<br />
| Default is 25565. The Notchian server does not use this information.<br />
|-<br />
| Next State<br />
| VarInt Enum<br />
| 1 for [[#Status|status]], 2 for [[#Login|login]]<br />
|}<br />
<br />
==== Legacy Server List Ping ====<br />
<br />
{{Warning|This packet uses a nonstandard format. It is never length-prefixed, and the packet ID is an Unsigned Byte instead of a VarInt.}}<br />
<br />
While not technically part of the current protocol, legacy clients may send this packet to initiate [[Server List Ping]], and modern servers should handle it correctly.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
| 0xFE<br />
| Handshaking<br />
| Server<br />
| Payload<br />
| Unsigned Byte<br />
| always 1 (<code>0x01</code>)<br />
|}<br />
<br />
See [[Server List Ping#1.6]] for the details of the protocol that follows this packet.<br />
<br />
== Play ==<br />
<br />
=== Clientbound ===<br />
<br />
==== Spawn Object ====<br />
<br />
Sent by the server when a vehicle or other object is created.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="12"| 0x00<br />
|rowspan="12"| Play<br />
|rowspan="12"| Client<br />
| Entity ID<br />
| VarInt<br />
| EID of the object<br />
|-<br />
| Object UUID<br />
| UUID<br />
| <br />
|-<br />
| Type<br />
| Byte<br />
| The type of object (see [[Entities#Objects]])<br />
|-<br />
| X<br />
| Double<br />
| <br />
|-<br />
| Y<br />
| Double<br />
| <br />
|-<br />
| Z<br />
| Double<br />
| <br />
|-<br />
| Pitch<br />
| Angle<br />
| <br />
|-<br />
| Yaw<br />
| Angle<br />
| <br />
|-<br />
| Data<br />
| Int<br />
| Meaning dependent on the value of the Type field, see [[Object Data]] for details.<br />
|-<br />
| Velocity X<br />
| Short<br />
|rowspan="3"| Same units as [[#Entity Velocity|Entity Velocity]]. Always sent, but only used when Data is greater than 0 (except for some entities which always ignore it; see [[Object Data]] for details).<br />
|-<br />
| Velocity Y<br />
| Short<br />
|-<br />
| Velocity Z<br />
| Short<br />
|}<br />
<br />
==== Spawn Experience Orb ====<br />
<br />
Spawns one or more experience orbs.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="5"| 0x01<br />
|rowspan="5"| Play<br />
|rowspan="5"| Client<br />
| Entity ID<br />
| VarInt<br />
| <br />
|-<br />
| X<br />
| Double<br />
| <br />
|-<br />
| Y<br />
| Double<br />
| <br />
|-<br />
| Z<br />
| Double<br />
| <br />
|-<br />
| Count<br />
| Short<br />
| The amount of experience this orb will reward once collected<br />
|}<br />
<br />
==== Spawn Global Entity ====<br />
<br />
With this packet, the server notifies the client of thunderbolts striking within a 512 block radius around the player. The coordinates specify where exactly the thunderbolt strikes.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="5"| 0x02<br />
|rowspan="5"| Play<br />
|rowspan="5"| Client<br />
| Entity ID<br />
| VarInt<br />
| The EID of the thunderbolt<br />
|-<br />
| Type<br />
| Byte Enum<br />
| The global entity type, currently always 1 for thunderbolt<br />
|-<br />
| X<br />
| Double<br />
| <br />
|-<br />
| Y<br />
| Double<br />
| <br />
|-<br />
| Z<br />
| Double<br />
| <br />
|}<br />
<br />
==== Spawn Mob ====<br />
<br />
Sent by the server when a mob entity is spawned.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="13"| 0x03<br />
|rowspan="13"| Play<br />
|rowspan="13"| Client<br />
| Entity ID<br />
| VarInt<br />
| <br />
|-<br />
| Entity UUID<br />
| UUID<br />
| <br />
|-<br />
| Type<br />
| VarInt<br />
| The type of mob. See [[Entities#Mobs]]<br />
|-<br />
| X<br />
| Double<br />
| <br />
|-<br />
| Y<br />
| Double<br />
| <br />
|-<br />
| Z<br />
| Double<br />
| <br />
|-<br />
| Yaw<br />
| Angle<br />
| <br />
|-<br />
| Pitch<br />
| Angle<br />
| <br />
|-<br />
| Head Pitch<br />
| Angle<br />
| <br />
|-<br />
| Velocity X<br />
| Short<br />
| Same units as [[#Entity Velocity|Entity Velocity]]<br />
|-<br />
| Velocity Y<br />
| Short<br />
| Same units as [[#Entity Velocity|Entity Velocity]]<br />
|-<br />
| Velocity Z<br />
| Short<br />
| Same units as [[#Entity Velocity|Entity Velocity]]<br />
|-<br />
| Metadata<br />
| [[Entities#Entity Metadata Format|Entity Metadata]]<br />
| <br />
|}<br />
<br />
==== Spawn Painting ====<br />
<br />
This packet shows location, name, and type of painting.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="5"| 0x04<br />
|rowspan="5"| Play<br />
|rowspan="5"| Client<br />
| Entity ID<br />
| VarInt<br />
| <br />
|-<br />
| Entity UUID<br />
| UUID<br />
| <br />
|-<br />
| Title<br />
| String (13)<br />
| Name of the painting. Max length 13<br />
|-<br />
| Location<br />
| Position<br />
| Center coordinates (see below)<br />
|-<br />
| Direction<br />
| Byte Enum<br />
| Direction the painting faces (North = 2, South = 0, West = 1, East = 3)<br />
|}<br />
<br />
Calculating the center of an image: given a (width × height) grid of cells, with <code>(0, 0)</code> being the top left corner, the center is <code>(max(0, width / 2 - 1), height / 2)</code>. E.g. <code>(1, 0)</code> for a 2×1 painting, or <code>(1, 2)</code> for a 4×4 painting.<br />
<br />
List of paintings by coordinates in <code>paintings_kristoffer_zetterstrand.png</code> (where x and y are in pixels from the top left and width and height are in pixels or 16ths of a block):<br />
<br />
{| class="wikitable"<br />
! Name<br />
! x<br />
! y<br />
! width<br />
! height<br />
|-<br />
| <code>Kebab</code><br />
| 0<br />
| 0<br />
| 16<br />
| 16<br />
|-<br />
| <code>Aztec</code><br />
| 16<br />
| 0<br />
| 16<br />
| 16<br />
|-<br />
| <code>Alban</code><br />
| 32<br />
| 0<br />
| 16<br />
| 16<br />
|-<br />
| <code>Aztec2</code><br />
| 48<br />
| 0<br />
| 16<br />
| 16<br />
|-<br />
| <code>Bomb</code><br />
| 64<br />
| 0<br />
| 16<br />
| 16<br />
|-<br />
| <code>Plant</code><br />
| 80<br />
| 0<br />
| 16<br />
| 16<br />
|-<br />
| <code>Wasteland</code><br />
| 96<br />
| 0<br />
| 16<br />
| 16<br />
|-<br />
| <code>Pool</code><br />
| 0<br />
| 32<br />
| 32<br />
| 16<br />
|-<br />
| <code>Courbet</code><br />
| 32<br />
| 32<br />
| 32<br />
| 16<br />
|-<br />
| <code>Sea</code><br />
| 64<br />
| 32<br />
| 32<br />
| 16<br />
|-<br />
| <code>Sunset</code><br />
| 96<br />
| 32<br />
| 32<br />
| 16<br />
|-<br />
| <code>Creebet</code><br />
| 128<br />
| 32<br />
| 32<br />
| 16<br />
|-<br />
| <code>Wanderer</code><br />
| 0<br />
| 64<br />
| 16<br />
| 32<br />
|-<br />
| <code>Graham</code><br />
| 16<br />
| 64<br />
| 16<br />
| 32<br />
|-<br />
| <code>Match</code><br />
| 0<br />
| 128<br />
| 32<br />
| 32<br />
|-<br />
| <code>Bust</code><br />
| 32<br />
| 128<br />
| 32<br />
| 32<br />
|-<br />
| <code>Stage</code><br />
| 64<br />
| 128<br />
| 32<br />
| 32<br />
|-<br />
| <code>Void</code><br />
| 96<br />
| 128<br />
| 32<br />
| 32<br />
|-<br />
| <code>SkullAndRoses</code><br />
| 128<br />
| 128<br />
| 32<br />
| 32<br />
|-<br />
| <code>Wither</code><br />
| 160<br />
| 128<br />
| 32<br />
| 32<br />
|-<br />
| <code>Fighters</code><br />
| 0<br />
| 96<br />
| 64<br />
| 32<br />
|-<br />
| <code>Pointer</code><br />
| 0<br />
| 192<br />
| 64<br />
| 64<br />
|-<br />
| <code>Pigscene</code><br />
| 64<br />
| 192<br />
| 64<br />
| 64<br />
|-<br />
| <code>BurningSkull</code><br />
| 128<br />
| 192<br />
| 64<br />
| 64<br />
|-<br />
| <code>Skeleton</code><br />
| 192<br />
| 64<br />
| 64<br />
| 48<br />
|-<br />
| <code>DonkeyKong</code><br />
| 192<br />
| 112<br />
| 64<br />
| 48<br />
|}<br />
<br />
The {{Minecraft Wiki|Painting#Canvases|Minecraft Wiki article on paintings}} also provides a list of painting names to the actual images.<br />
<br />
==== Spawn Player ====<br />
<br />
This packet is sent by the server when a player comes into visible range, ''not'' when a player joins.<br />
<br />
This packet must be sent after the [[#Player List Item|Player List Item]] ([[#Play|Play]], 0x38, clientbound) packet that adds the player data for the client to use when spawning a player. If the Player List Item for the player spawned by this packet is not present when this packet arrives, Notchian clients will not spawn the player entity. The Player List Item packet includes skin/cape data.<br />
<br />
Servers can, however, safely spawn player entities for players not in visible range. The client appears to handle it correctly.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="8"| 0x05<br />
|rowspan="8"| Play<br />
|rowspan="8"| Client<br />
| Entity ID<br />
| VarInt<br />
| Player's EID<br />
|-<br />
| Player UUID<br />
| UUID<br />
| See below for notes on {{Minecraft Wiki|Server.properties#online-mode|offline mode}} and NPCs<br />
|-<br />
| X<br />
| Double<br />
| <br />
|-<br />
| Y<br />
| Double<br />
| <br />
|-<br />
| Z<br />
| Double<br />
| <br />
|-<br />
| Yaw<br />
| Angle<br />
| <br />
|-<br />
| Pitch<br />
| Angle<br />
| <br />
|-<br />
| Metadata<br />
| [[Entities#Entity Metadata Format|Entity Metadata]]<br />
| <br />
|}<br />
<br />
When in {{Minecraft Wiki|Server.properties#online-mode|online mode}}, the UUIDs must be valid and have valid skin blobs.<br />
<br />
In offline mode, [[Wikipedia:Universally unique identifier#Versions 3 and 5 (namespace name-based)|UUID v3]] is used with the String <code>OfflinePlayer:&lt;player name&gt;</code>, encoded in UTF-8 (and case-sensitive).<br />
<br />
For NPCs UUID v2 should be used. Note:<br />
<br />
<+Grum> i will never confirm this as a feature you know that :)<br />
<br />
In an example UUID, <code>xxxxxxxx-xxxx-Yxxx-xxxx-xxxxxxxxxxxx</code>, the UUID version is specified by <code>Y</code>. So, for UUID v3, <code>Y</code> will always be <code>3</code>, and for UUID v2, <code>Y</code> will always be <code>2</code>.<br />
<br />
==== Animation (clientbound) ====<br />
<br />
Sent whenever an entity should change animation.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x06<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Entity ID<br />
| VarInt<br />
| Player ID<br />
|-<br />
| Animation<br />
| Unsigned Byte<br />
| Animation ID (see below)<br />
|}<br />
<br />
Animation can be one of the following values:<br />
<br />
{| class="wikitable"<br />
! ID<br />
! Animation<br />
|-<br />
| 0<br />
| Swing main arm<br />
|-<br />
| 1<br />
| Take damage<br />
|-<br />
| 2<br />
| Leave bed<br />
|-<br />
| 3<br />
| Swing offhand<br />
|-<br />
| 4<br />
| Critical effect<br />
|-<br />
| 5<br />
| Magic critical effect<br />
|}<br />
<br />
==== Statistics ====<br />
<br />
Sent as a response to [[#Client_Status|Client Status 0x04]] (id 1).<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To <br />
!colspan="2"| Field Name<br />
!colspan="2"| Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x07<br />
|rowspan="3"| Play<br />
|rowspan="3"| Client<br />
|colspan="2"| Count<br />
|colspan="2"| VarInt<br />
| Number of elements in the following array<br />
|-<br />
|rowspan="2"| Statistic<br />
| Name<br />
|rowspan="2"| Array<br />
| String (32767)<br />
| [https://gist.github.com/Alvin-LB/8d0d13db00b3c00fd0e822a562025eff https://gist.github.com/Alvin-LB/8d0d13db00b3c00fd0e822a562025eff]<br />
|-<br />
| Value<br />
| VarInt<br />
| The amount to set it to<br />
|}<br />
<br />
==== Block Break Animation ====<br />
<br />
0–9 are the displayable destroy stages and each other number means that there is no animation on this coordinate.<br />
<br />
Block break animations can still be applied on air; the animation will remain visible although there is no block being broken. However, if this is applied to a transparent block, odd graphical effects may happen, including water losing its transparency. (An effect similar to this can be seen in normal gameplay when breaking ice blocks)<br />
<br />
If you need to display several break animations at the same time you have to give each of them a unique Entity ID.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x08<br />
|rowspan="3"| Play<br />
|rowspan="3"| Client<br />
| Entity ID<br />
| VarInt<br />
| Entity ID of the entity breaking the block<br />
|-<br />
| Location<br />
| Position<br />
| Block Position<br />
|-<br />
| Destroy Stage<br />
| Byte<br />
| 0–9 to set it, any other value to remove it<br />
|}<br />
<br />
==== Update Block Entity ====<br />
<br />
Sets tile entity associated with the block at the given location.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x09<br />
|rowspan="3"| Play<br />
|rowspan="3"| Client<br />
| Location<br />
| Position<br />
| <br />
|-<br />
| Action<br />
| Unsigned Byte<br />
| The type of update to perform, see below<br />
|-<br />
| NBT Data<br />
| [[NBT|NBT Tag]]<br />
| Data to set. May be a TAG_END (0), in which case the block entity at the given location is removed (though this is not required since the client will remove the block entity automatically on chunk unload or block removal)<br />
|}<br />
<br />
''Action'' field:<br />
<br />
* '''1''': Set data of a mob spawner (everything except for SpawnPotentials: current delay, min/max delay, mob to be spawned, spawn count, spawn range, etc.)<br />
* '''2''': Set command block text (command and last execution status)<br />
* '''3''': Set the level, primary, and secondary powers of a beacon<br />
* '''4''': Set rotation and skin of mob head<br />
* '''5''': Set type of flower in flower pot<br />
* '''6''': Set base color and patterns on a banner<br />
* '''7''': Set the data for a Structure tile entity<br />
* '''8''': Set the destination for a end gateway<br />
* '''9''': Set the text on a sign<br />
* '''10''': Declare a shulker box, no data appears to be sent and the client seems to do fine without this packet. Perhaps it is a leftover from earlier versions?<br />
* '''11''': Set the color of a bed<br />
<br />
==== Block Action ====<br />
<br />
This packet is used for a number of actions and animations performed by blocks, usually non-persistent.<br />
<br />
See [[Block Actions]] for a list of values.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="4"| 0x0A<br />
|rowspan="4"| Play<br />
|rowspan="4"| Client<br />
| Location<br />
| Position<br />
| Block coordinates<br />
|-<br />
| Action ID (Byte 1)<br />
| Unsigned Byte<br />
| Varies depending on block — see [[Block Actions]]<br />
|-<br />
| Action Param (Byte 2)<br />
| Unsigned Byte<br />
| Varies depending on block — see [[Block Actions]]<br />
|-<br />
| Block Type<br />
| VarInt<br />
| The block type ID for the block, not including metadata/damage value. This must match the block at the given coordinates.<br />
|}<br />
<br />
==== Block Change ====<br />
<br />
Fired whenever a block is changed within the render distance.<br />
<br />
{{Warning2|Changing a block in a chunk that is not loaded is not a stable action. The Notchian client currently uses a ''shared'' empty chunk which is modified for all block changes in unloaded chunks; while in 1.9 this chunk never renders in older versions the changed block will appear in all copies of the empty chunk. Servers should avoid sending block changes in unloaded chunks and clients should ignore such packets.}}<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x0B<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Location<br />
| Position<br />
| Block Coordinates<br />
|-<br />
| Block ID<br />
| VarInt<br />
| The new block state ID for the block as given in the {{Minecraft Wiki|Data values#Block IDs|global palette}} (When reading data: <code>type = id &gt;&gt; 4</code>, <code>meta = id & 15</code>, when writing data: <code>id = type &lt;&lt; 4 &#124; (meta &amp; 15)</code>)<br />
|}<br />
<br />
==== Boss Bar ==== <br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
!colspan="2"| Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="15"| 0x0C<br />
|rowspan="15"| Play<br />
|rowspan="15"| Client<br />
|colspan="2"| UUID<br />
| UUID<br />
| Unique ID for this bar<br />
|-<br />
|colspan="2"| Action<br />
| VarInt Enum<br />
| Determines the layout of the remaining packet<br />
|-<br />
! Action<br />
! Field Name<br />
! <br />
! <br />
|-<br />
|rowspan="5"| 0: add<br />
| Title<br />
| [[Chat]]<br />
| <br />
|-<br />
| Health<br />
| Float<br />
| From 0 to 1. Values greater than 1 do not crash a Notchian client, and start [https://i.johni0702.de/nA.png rendering part of a second health bar] at around 1.5.<br />
|-<br />
| Color<br />
| VarInt Enum<br />
| Color ID (see below)<br />
|-<br />
| Division<br />
| VarInt Enum<br />
| Type of division (see below)<br />
|-<br />
| Flags<br />
| Unsigned Byte<br />
| Bit mask. 0x1: should darken sky, 0x2: is dragon bar (used to play end music)<br />
|-<br />
| 1: remove<br />
| ''no fields''<br />
| ''no fields''<br />
| Removes this boss bar<br />
|-<br />
| 2: update health<br />
| Health<br />
| Float<br />
| as above<br />
|-<br />
| 3: update title<br />
| Title<br />
| [[Chat]]<br />
| <br />
|-<br />
|rowspan="2"| 4: update style<br />
| Color<br />
| VarInt Enum<br />
| Color ID (see below)<br />
|-<br />
| Dividers<br />
| VarInt Enum<br />
| as above<br />
|-<br />
| 5: update flags<br />
| Flags<br />
| Unsigned Byte<br />
| as above<br />
|-<br />
|}<br />
<br />
{| class="wikitable"<br />
! ID<br />
! Color<br />
|-<br />
| 0<br />
| Pink<br />
|-<br />
| 1<br />
| Blue<br />
|-<br />
| 2<br />
| Red<br />
|-<br />
| 3<br />
| Green<br />
|-<br />
| 4<br />
| Yellow<br />
|-<br />
| 5<br />
| Purple<br />
|-<br />
| 6<br />
| White<br />
|}<br />
<br />
{| class="wikitable"<br />
! ID<br />
! Type of division<br />
|-<br />
| 0<br />
| No division<br />
|-<br />
| 1<br />
| 6 notches<br />
|-<br />
| 2<br />
| 10 notches<br />
|-<br />
| 3<br />
| 12 notches<br />
|-<br />
| 4<br />
| 20 notches<br />
|}<br />
<br />
==== Server Difficulty ====<br />
<br />
Changes the difficulty setting in the client's option menu<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x0D<br />
|rowspan="1"| Play<br />
|rowspan="1"| Client<br />
| Difficulty<br />
| Unsigned Byte<br />
| 0: peaceful, 1: easy, 2: normal, 3: hard<br />
|}<br />
<br />
==== Tab-Complete (clientbound) ====<br />
<br />
The server responds with a list of auto-completions of the last word sent to it. In the case of regular chat, this is a player username. Command names and parameters are also supported. The client sorts these alphabetically before listing them.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x0E<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Count<br />
| VarInt<br />
| Number of elements in the following array<br />
|-<br />
| Matches<br />
| Array of String (32767)<br />
| One eligible command, note that each command is sent separately instead of in a single string, hence the need for Count<br />
|}<br />
<br />
==== Chat Message (clientbound) ==== <br />
<br />
Identifying the difference between Chat/System Message is important as it helps respect the user's chat visibility options. While game info accepts json formatting it will not display, old style §-based formatting works. See [[Chat#Processing chat|processing chat]] for more info about these positions.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x0F<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| JSON Data<br />
| [[Chat]]<br />
| Limited to 32767 bytes<br />
|-<br />
| Position<br />
| Byte<br />
| 0: chat (chat box), 1: system message (chat box), 2: game info (above hotbar).<br />
|}<br />
<br />
==== Multi Block Change ====<br />
<br />
Fired whenever 2 or more blocks are changed within the same chunk on the same tick.<br />
<br />
{{Warning|Changing blocks in chunks not loaded by the client is unsafe (see note on [[#Block Change|Block Change]]).}}<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
!colspan="2"| Field Name<br />
!colspan="2"| Field Type<br />
! Notes<br />
|-<br />
|rowspan="6"| 0x10<br />
|rowspan="6"| Play<br />
|rowspan="6"| Client<br />
|colspan="2"| Chunk X<br />
|colspan="2"| Int<br />
| Chunk X coordinate<br />
|-<br />
|colspan="2"| Chunk Z<br />
|colspan="2"| Int<br />
| Chunk Z coordinate<br />
|-<br />
|colspan="2"| Record Count<br />
|colspan="2"| VarInt<br />
| Number of elements in the following array, i.e. the number of blocks affected<br />
|-<br />
|rowspan="3"| Record<br />
| Horizontal Position<br />
|rowspan="3"| Array<br />
| Unsigned Byte<br />
| The 4 most significant bits (<code>0xF0</code>) encode the X coordinate, relative to the chunk. The 4 least significant bits (<code>0x0F</code>) encode the Z coordinate, relative to the chunk.<br />
|-<br />
| Y Coordinate<br />
| Unsigned Byte<br />
| Y coordinate of the block<br />
|-<br />
| Block ID<br />
| VarInt<br />
| The new block state ID for the block as given in the {{Minecraft Wiki|Data values#Block IDs|global palette}} (When reading data: <code>type = id &gt;&gt; 4</code>, <code>meta = id & 15</code>, when writing data: <code>id = type &lt;&lt; 4 &#124; (meta &amp; 15)</code>)<br />
|}<br />
<br />
To decode the position into a world position:<br />
<br />
<syntaxhighlight lang="java"><br />
worldX = (horizPos >> 4 & 15) + (chunkX * 16);<br />
worldY = vertPos;<br />
worldZ = (horizPos & 15) + (chunkZ * 16);<br />
</syntaxhighlight><br />
<br />
==== Confirm Transaction (clientbound) ====<br />
<br />
A packet from the server indicating whether a request from the client was accepted, or whether there was a conflict (due to lag). If the packet was not accepted, the client must respond with a [[#Confirm Transaction (serverbound)|serverbound confirm transaction]] packet.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x11<br />
|rowspan="3"| Play<br />
|rowspan="3"| Client<br />
| Window ID<br />
| Byte<br />
| The ID of the window that the action occurred in<br />
|-<br />
| Action Number<br />
| Short<br />
| Every action that is to be accepted has a unique number. This number is an incrementing integer (starting at 0) with separate counts for each window ID.<br />
|-<br />
| Accepted<br />
| Boolean<br />
| Whether the action was accepted<br />
|}<br />
<br />
==== Close Window (clientbound) ====<br />
<br />
This packet is sent from the server to the client when a window is forcibly closed, such as when a chest is destroyed while it's open.<br />
<br />
Note, notchian clients send a close window packet with Window ID 0 to close their inventory even though there is never an [[#Open Window|Open Window]] packet for inventory. <br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
| 0x12<br />
| Play<br />
| Client<br />
| Window ID<br />
| Unsigned Byte<br />
| This is the ID of the window that was closed. 0 for inventory.<br />
|}<br />
<br />
==== Open Window ====<br />
<br />
This is sent to the client when it should open an inventory, such as a chest, workbench, or furnace. This message is not sent anywhere for clients opening their own inventory.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="5"| 0x13<br />
|rowspan="5"| Play<br />
|rowspan="5"| Client<br />
| Window ID<br />
| Unsigned Byte<br />
| A unique id number for the window to be displayed. Notchian server implementation is a counter, starting at 1.<br />
|-<br />
| Window Type<br />
| String (32)<br />
| The window type to use for display. See [[Inventory]] for a list.<br />
|-<br />
| Window Title<br />
| [[Chat]]<br />
| The title of the window<br />
|-<br />
| Number Of Slots<br />
| Unsigned Byte<br />
| Number of slots in the window (excluding the number of slots in the player inventory)<br />
|-<br />
| Entity ID<br />
| Optional Int<br />
| EntityHorse's EID. Only sent when Window Type is “EntityHorse”<br />
|}<br />
<br />
See [[Inventory]] for further information.<br />
<br />
==== Window Items ====<br />
[[File:Inventory-slots.png|thumb|The inventory slots]]<br />
<br />
Sent by the server when items in multiple slots (in a window) are added/removed. This includes the main inventory, equipped armour and crafting slots.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x14<br />
|rowspan="3"| Play<br />
|rowspan="3"| Client<br />
| Window ID<br />
| Unsigned Byte<br />
| The ID of window which items are being sent for. 0 for player inventory.<br />
|-<br />
| Count<br />
| Short<br />
| Number of elements in the following array<br />
|-<br />
| Slot Data<br />
| Array of [[Slot Data|Slot]]<br />
| <br />
|}<br />
<br />
See [[Inventory#Windows|inventory windows]] for further information about how slots are indexed.<br />
<br />
==== Window Property ====<br />
<br />
This packet is used to inform the client that part of a GUI window should be updated.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x15<br />
|rowspan="3"| Play<br />
|rowspan="3"| Client<br />
| Window ID<br />
| Unsigned Byte<br />
| <br />
|-<br />
| Property<br />
| Short<br />
| The property to be updated, see below<br />
|-<br />
| Value<br />
| Short<br />
| The new value for the property, see below<br />
|}<br />
<br />
The meaning of the Property field depends on the type of the window. The following table shows the known combinations of window type and property, and how the value is to be interpreted.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Window type<br />
! Property<br />
! Value<br />
|-<br />
|rowspan="4"| Furnace<br />
| 0: Fire icon (fuel left)<br />
| counting from fuel burn time down to 0 (in-game ticks)<br />
|-<br />
| 1: Maximum fuel burn time<br />
| fuel burn time or 0 (in-game ticks)<br />
|-<br />
| 2: Progress arrow<br />
| counting from 0 to maximum progress (in-game ticks)<br />
|-<br />
| 3: Maximum progress<br />
| always 200 on the notchian server<br />
|-<br />
|rowspan="10"| Enchantment Table<br />
| 0: Level requirement for top enchantment slot<br />
|rowspan="3"| The enchantment's xp level requirement<br />
|-<br />
| 1: Level requirement for middle enchantment slot<br />
|-<br />
| 2: Level requirement for bottom enchantment slot<br />
|-<br />
| 3: The enchantment seed<br />
| Used for drawing the enchantment names (in [[Wikipedia:Standard Galactic Alphabet|SGA]]) clientside. The same seed ''is'' used to calculate enchantments, but some of the data isn't sent to the client to prevent easily guessing the entire list (the seed value here is the regular seed bitwise and <code>0xFFFFFFF0</code>).<br />
|-<br />
| 4: Enchantment ID shown on mouse hover over top enchantment slot<br />
|rowspan="3"| The enchantment id (set to -1 to hide it)<br />
|-<br />
| 5: Enchantment ID shown on mouse hover over middle enchantment slot<br />
|-<br />
| 6: Enchantment ID shown on mouse hover over bottom enchantment slot<br />
|-<br />
| 7: Enchantment level shown on mouse hover over the top slot<br />
|rowspan="3"| The enchantment level (1 = I, 2 = II, 6 = VI, etc.), or -1 if no enchant<br />
|-<br />
| 8: Enchantment level shown on mouse hover over the middle slot<br />
|-<br />
| 9: Enchantment level shown on mouse hover over the bottom slot<br />
|-<br />
|rowspan="3"| Beacon<br />
| 0: Power level<br />
| 0-4, controls what effect buttons are enabled<br />
|-<br />
| 1: First potion effect<br />
| {{Minecraft Wiki|Data values#Status effects|Potion effect ID}} for the first effect, or -1 if no effect<br />
|-<br />
| 2: Second potion effect<br />
| {{Minecraft Wiki|Data values#Status effects|Potion effect ID}} for the second effect, or -1 if no effect<br />
|-<br />
| Anvil<br />
| 0: Repair cost<br />
| The repair's cost in xp levels<br />
|-<br />
| Brewing Stand<br />
| 0: Brew time<br />
| 0–400, with 400 making the arrow empty, and 0 making the arrow full<br />
|}<br />
<br />
==== Set Slot ====<br />
<br />
Sent by the server when an item in a slot (in a window) is added/removed.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x16<br />
|rowspan="3"| Play<br />
|rowspan="3"| Client<br />
| Window ID<br />
| Byte<br />
| The window which is being updated. 0 for player inventory. Note that all known window types include the player inventory. This packet will only be sent for the currently opened window while the player is performing actions, even if it affects the player inventory. After the window is closed, a number of these packets are sent to update the player's inventory window (0).<br />
|-<br />
| Slot<br />
| Short<br />
| The slot that should be updated<br />
|-<br />
| Slot Data<br />
| [[Slot Data|Slot]]<br />
| <br />
|}<br />
<br />
To set the cursor (the item currently dragged with the mouse), use -1 as Window ID and as Slot.<br />
<br />
This packet can only be used to edit the hotbar of the player's inventory if window ID is set to 0 (slots 36 through 44). If the window ID is set to -2, then any slot in the inventory can be used but no add item animation will be played.<br />
<br />
==== Set Cooldown ====<br />
<br />
Applies a cooldown period to all items with the given type. Used by the Notchian server with enderpearls. This packet should be sent when the cooldown starts and also when the cooldown ends (to compensate for lag), although the client will end the cooldown automatically.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x17<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Item ID<br />
| VarInt<br />
| Numeric ID of the item to apply a cooldown to.<br />
|-<br />
| Cooldown Ticks<br />
| VarInt<br />
| Number of ticks to apply a cooldown for, or 0 to clear the cooldown.<br />
|}<br />
<br />
==== Plugin Message (clientbound) ====<br />
<br />
{{Main|Plugin channels}}<br />
<br />
Mods and plugins can use this to send their data. Minecraft itself uses a number of [[plugin channel]]s. These internal channels are prefixed with <code>MC|</code>.<br />
<br />
More documentation on this: [http://dinnerbone.com/blog/2012/01/13/minecraft-plugin-channels-messaging/ http://dinnerbone.com/blog/2012/01/13/minecraft-plugin-channels-messaging/]<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x18<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Channel<br />
| String (20)<br />
| Name of the [[plugin channel]] used to send the data<br />
|-<br />
| Data<br />
| Byte Array<br />
| Any data, depending on the channel. <code><nowiki>MC|</nowiki></code> channels are documented [[plugin channel|here]]. The length of this array must be inferred from the packet length.<br />
|}<br />
<br />
==== Named Sound Effect ====<br />
{{See also|#Sound Effect}}<br />
<br />
Used to play a sound effect on the client. Custom sounds may be added by resource packs.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="7"| 0x19<br />
|rowspan="7"| Play<br />
|rowspan="7"| Client<br />
| Sound Name<br />
| String (256)<br />
| All sound effect names as of 1.11.0 can be seen [http://pokechu22.github.io/Burger/1.11.html#sounds here].<br />
|-<br />
| Sound Category<br />
| VarInt Enum<br />
| The category that this sound will be played from ([https://gist.github.com/konwboj/7c0c380d3923443e9d55 current categories])<br />
|-<br />
| Effect Position X<br />
| Int<br />
| Effect X multiplied by 8 ([[Data types#Fixed-point numbers|fixed-point number]] with only 3 bits dedicated to the fractional part)<br />
|-<br />
| Effect Position Y<br />
| Int<br />
| Effect Y multiplied by 8 ([[Data types#Fixed-point numbers|fixed-point number]] with only 3 bits dedicated to the fractional part)<br />
|-<br />
| Effect Position Z<br />
| Int<br />
| Effect Z multiplied by 8 ([[Data types#Fixed-point numbers|fixed-point number]] with only 3 bits dedicated to the fractional part)<br />
|-<br />
| Volume<br />
| Float<br />
| 1 is 100%, can be more<br />
|-<br />
| Pitch<br />
| Float<br />
| Float between 0.5 and 2.0 by Notchian clients<br />
|}<br />
<br />
==== Disconnect (play) ====<br />
<br />
Sent by the server before it disconnects a client. The client assumes that the server has already closed the connection by the time the packet arrives.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
| 0x1A<br />
| Play<br />
| Client<br />
| Reason<br />
| [[Chat]]<br />
| Displayed to the client when the connection terminates.<br />
|}<br />
<br />
==== Entity Status ====<br />
<br />
Entity statuses generally trigger an animation for an entity. The available statuses vary by the entity's type (and are available to subclasses of that type as well).<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x1B<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Entity ID<br />
| Int<br />
| <br />
|-<br />
| Entity Status<br />
| Byte Enum<br />
| See below<br />
|}<br />
<br />
See [[entities]] for a list of which statuses are valid for each type of entity.<br />
<br />
==== Explosion ====<br />
<br />
Sent when an explosion occurs (creepers, TNT, and ghast fireballs).<br />
<br />
Each block in Records is set to air. Coordinates for each axis in record is int(X) + record.x<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="9"| 0x1C<br />
|rowspan="9"| Play<br />
|rowspan="9"| Client<br />
| X<br />
| Float<br />
| <br />
|-<br />
| Y<br />
| Float<br />
| <br />
|-<br />
| Z<br />
| Float<br />
| <br />
|-<br />
| Radius<br />
| Float<br />
| Currently unused in the client<br />
|-<br />
| Record Count<br />
| Int<br />
| Number of elements in the following array<br />
|-<br />
| Records<br />
| Array of (Byte, Byte, Byte)<br />
| Each record is 3 signed bytes long, each bytes are the XYZ (respectively) offsets of affected blocks.<br />
|-<br />
| Player Motion X<br />
| Float<br />
| X velocity of the player being pushed by the explosion<br />
|-<br />
| Player Motion Y<br />
| Float<br />
| Y velocity of the player being pushed by the explosion<br />
|-<br />
| Player Motion Z<br />
| Float<br />
| Z velocity of the player being pushed by the explosion<br />
|}<br />
<br />
==== Unload Chunk ====<br />
<br />
Tells the client to unload a chunk column.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x1D<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Chunk X<br />
| Int<br />
| Block coordinate divided by 16, rounded down<br />
|-<br />
| Chunk Z<br />
| Int<br />
| Block coordinate divided by 16, rounded down<br />
|}<br />
<br />
It is legal to send this packet even if the given chunk is not currently loaded.<br />
<br />
==== Change Game State ====<br />
<br />
Used for a wide variety of game state things, from whether to bed use to gamemode to demo messages.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x1E<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Reason<br />
| Unsigned Byte<br />
| See below<br />
|-<br />
| Value<br />
| Float<br />
| Depends on Reason<br />
|}<br />
<br />
''Reason codes'':<br />
<br />
{| class="wikitable"<br />
! Reason<br />
! Effect<br />
! Value<br />
|-<br />
| 0<br />
| Invalid Bed<br />
| Would be used to switch between messages, but the only used message is 0 for invalid bed<br />
|-<br />
| 1<br />
| End raining<br />
| <br />
|-<br />
| 2<br />
| Begin raining<br />
| <br />
|-<br />
| 3<br />
| Change gamemode<br />
| 0: Survival, 1: Creative, 2: Adventure, 3: Spectator<br />
|-<br />
| 4<br />
| Exit end<br />
| 0: Immediately send Client Status of respawn without showing end credits; 1: Show end credits and respawn at the end (or when esc is pressed). 1 is sent if the player has not yet received the "The end?" achievement, while if they do have it 0 is used.<br />
|-<br />
| 5<br />
| Demo message<br />
| 0: Show welcome to demo screen, 101: Tell movement controls, 102: Tell jump control, 103: Tell inventory control<br />
|- <br />
| 6<br />
| Arrow hitting player<br />
| Appears to be played when an arrow strikes another player in Multiplayer<br />
|-<br />
| 7<br />
| Fade value<br />
| The current darkness value. 1 = Dark, 0 = Bright, Setting the value higher causes the game to change color and freeze<br />
|-<br />
| 8<br />
| Fade time<br />
| Time in ticks for the sky to fade<br />
|-<br />
| 10<br />
| Play elder guardian mob appearance (effect and sound)<br />
| <br />
|}<br />
<br />
==== Keep Alive (clientbound) ====<br />
<br />
The server will frequently send out a keep-alive, each containing a random ID. The client must respond with the same packet. If the client does not respond to them for over 30 seconds, the server kicks the client. Vice versa, if the server does not send any keep-alives for 20 seconds, the client will disconnect and yields a "Timed out" exception.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x1F<br />
|rowspan="1"| Play<br />
|rowspan="1"| Client<br />
| Keep Alive ID<br />
| VarInt<br />
| <br />
|}<br />
<br />
==== Chunk Data ====<br />
{{Main|Chunk Format}}<br />
{{See also|#Unload Chunk}}<br />
<br />
The server only sends skylight information for chunk pillars in the {{Minecraft Wiki|Overworld}}, it's up to the client to know in which dimenison the player is currently located. You can also infer this information from the primary bitmask and the amount of uncompressed bytes sent. This packet also sends all block entities in the chunk (though sending them is not required; it is still legal to send them with [[#Update Block Entity|Update Block Entity]] later).<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="9"| 0x20<br />
|rowspan="9"| Play<br />
|rowspan="9"| Client<br />
| Chunk X<br />
| Int<br />
| Chunk coordinate (block coordinate divided by 16, rounded down)<br />
|-<br />
| Chunk Z<br />
| Int<br />
| Chunk coordinate (block coordinate divided by 16, rounded down)<br />
|-<br />
| Ground-Up Continuous<br />
| Boolean<br />
| See [[Chunk Format#Ground-up continuous|Chunk Format]]<br />
|-<br />
| Primary Bit Mask<br />
| VarInt<br />
| Bitmask with bits set to 1 for every 16×16×16 chunk section whose data is included in Data. The least significant bit represents the chunk section at the bottom of the chunk column (from y=0 to y=15).<br />
|- <br />
| Size<br />
| VarInt<br />
| Size of Data in bytes<br />
|-<br />
| Data<br />
| Byte array<br />
| See [[Chunk Format#Data structure|data structure]] in Chunk Format<br />
|-<br />
| Number of block entities<br />
| VarInt<br />
| Length of the following array<br />
|-<br />
| Block entities<br />
| Array of [[NBT|NBT Tag]]<br />
| All block entities in the chunk. Use the x, y, and z tags in the NBT to determine their positions.<br />
|}<br />
<br />
==== Effect ====<br />
<br />
Sent when a client is to play a sound or particle effect.<br />
<br />
By default, the Minecraft client adjusts the volume of sound effects based on distance. The final boolean field is used to disable this, and instead the effect is played from 2 blocks away in the correct direction. Currently this is only used for effect 1023 (wither spawn) and effect 1028 (enderdragon death); it is ignored on other effects.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="4"| 0x21<br />
|rowspan="4"| Play<br />
|rowspan="4"| Client<br />
| Effect ID<br />
| Int<br />
| The ID of the effect, see below<br />
|-<br />
| Location<br />
| Position<br />
| The location of the effect<br />
|-<br />
| Data<br />
| Int<br />
| Extra data for certain effects, see below<br />
|-<br />
| Disable Relative Volume<br />
| Boolean<br />
| See above<br />
|}<br />
<br />
Effect IDs:<br />
<br />
{| class="wikitable"<br />
! ID<br />
! Name<br />
! Data<br />
|-<br />
!colspan="3"| Sound<br />
|-<br />
| 1000<br />
| Dispenser dispenses<br />
| <br />
|-<br />
| 1001<br />
| Dispenser fails to dispense<br />
| <br />
|-<br />
| 1002<br />
| Dispenser shoots<br />
| <br />
|-<br />
| 1003<br />
| Ender eye launched<br />
| <br />
|-<br />
| 1004<br />
| Firework shot<br />
| <br />
|-<br />
| 1005<br />
| Iron door opened<br />
| <br />
|-<br />
| 1006<br />
| Wooden door opened<br />
| <br />
|-<br />
| 1007<br />
| Wooden trapdoor opened<br />
| <br />
|-<br />
| 1008<br />
| Fence gate opened<br />
| <br />
|-<br />
| 1009<br />
| Fire extinguished<br />
| <br />
|-<br />
| 1010<br />
| Play record<br />
| {{Minecraft Wiki|Music Discs|Record ID}}<br />
|-<br />
| 1011<br />
| Iron door closed<br />
| <br />
|-<br />
| 1012<br />
| Wooden door closed<br />
| <br />
|-<br />
| 1013<br />
| Wooden trapdoor closed<br />
| <br />
|-<br />
| 1014<br />
| Fence gate closed<br />
| <br />
|-<br />
| 1015<br />
| Ghast warns<br />
| <br />
|-<br />
| 1016<br />
| Ghast shoots<br />
| <br />
|-<br />
| 1017<br />
| Enderdragon shoots<br />
| <br />
|-<br />
| 1018<br />
| Blaze shoots<br />
| <br />
|-<br />
| 1019<br />
| Zombie attacks wood door<br />
| <br />
|-<br />
| 1020<br />
| Zombie attacks iron door<br />
| <br />
|-<br />
| 1021<br />
| Zombie breaks wood door<br />
|<br />
|-<br />
| 1022<br />
| Wither breaks block<br />
|<br />
|-<br />
| 1023<br />
| Wither spawned<br />
| <br />
|-<br />
| 1024<br />
| Wither shoots<br />
|<br />
|-<br />
| 1025<br />
| Bat takes off<br />
|<br />
|-<br />
| 1026<br />
| Zombie infects<br />
|<br />
|-<br />
| 1027<br />
| Zombie villager converted<br />
|<br />
|-<br />
| 1028<br />
| Ender dragon death<br />
|<br />
|-<br />
| 1029<br />
| Anvil destroyed<br />
| <br />
|-<br />
| 1030<br />
| Anvil used<br />
| <br />
|-<br />
| 1031<br />
| Anvil landed<br />
|<br />
|-<br />
| 1032<br />
| Portal travel<br />
| <br />
|-<br />
| 1033<br />
| Chorus flower grown<br />
|<br />
|-<br />
| 1034<br />
| Chorus flower died<br />
| <br />
|-<br />
| 1035<br />
| Brewing stand brewed<br />
|<br />
|-<br />
| 1036<br />
| Iron trapdoor opened<br />
| <br />
|-<br />
| 1037<br />
| Iron trapdoor closed<br />
|<br />
|-<br />
!colspan="3"| Particle<br />
|-<br />
| 2000<br />
| Spawns 10 smoke particles, e.g. from a fire<br />
| Direction, see below<br />
|-<br />
| 2001<br />
| Block break + block break sound<br />
| {{Minecraft Wiki|Data values|Block ID}}<br />
|-<br />
| 2002/2007<br />
| Splash potion. Particle effect + glass break sound.<br />
| [http://minecraft.gamepedia.com/Data_values#Potions Potion ID]<br />
|-<br />
| 2003<br />
| Eye of Ender entity break animation — particles and sound<br />
| <br />
|-<br />
| 2004<br />
| Mob spawn particle effect: smoke + flames<br />
| <br />
|-<br />
| 2005<br />
| Bonemeal particles<br />
| How many particles to spawn (if set to 0, 15 are spawned)<br />
|-<br />
| 2006<br />
| Dragon breath<br />
|<br />
|-<br />
| 3000<br />
| End gateway spawn<br />
| <br />
|-<br />
| 3001<br />
| Enderdragon growl<br />
|<br />
|}<br />
<br />
Smoke directions:<br />
<br />
{| class="wikitable"<br />
! ID<br />
! Direction<br />
|-<br />
| 0<br />
| South-East<br />
|-<br />
| 1<br />
| South<br />
|-<br />
| 2<br />
| South-West<br />
|-<br />
| 3<br />
| East<br />
|-<br />
| 4<br />
| (Up or middle ?)<br />
|-<br />
| 5<br />
| West<br />
|-<br />
| 6<br />
| North-East<br />
|-<br />
| 7<br />
| North<br />
|-<br />
| 8<br />
| North-West<br />
|}<br />
<br />
==== Particle ====<br />
<br />
Displays the named particle<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="11"| 0x22<br />
|rowspan="11"| Play<br />
|rowspan="11"| Client<br />
| Particle ID<br />
| Int<br />
| See below<br />
|-<br />
| Long Distance<br />
| Boolean<br />
| If true, particle distance increases from 256 to 65536<br />
|-<br />
| X<br />
| Float<br />
| X position of the particle<br />
|-<br />
| Y<br />
| Float<br />
| Y position of the particle<br />
|-<br />
| Z<br />
| Float<br />
| Z position of the particle<br />
|-<br />
| Offset X<br />
| Float<br />
| This is added to the X position after being multiplied by random.nextGaussian()<br />
|-<br />
| Offset Y<br />
| Float<br />
| This is added to the Y position after being multiplied by random.nextGaussian()<br />
|-<br />
| Offset Z<br />
| Float<br />
| This is added to the Z position after being multiplied by random.nextGaussian()<br />
|-<br />
| Particle Data<br />
| Float<br />
| The data of each particle<br />
|-<br />
| Particle Count<br />
| Int<br />
| The number of particles to create<br />
|-<br />
| Data<br />
| Array of VarInt<br />
| Length depends on particle. "iconcrack" has length of 2, "blockcrack", and "blockdust" have lengths of 1, the rest have 0.<br />
|}<br />
<br />
Particle IDs:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Particle Name<br />
! Particle ID<br />
|-<br />
| explode<br />
| 0<br />
|-<br />
| largeexplosion<br />
| 1<br />
|-<br />
| hugeexplosion<br />
| 2<br />
|-<br />
| fireworksSpark<br />
| 3<br />
|-<br />
| bubble<br />
| 4<br />
|-<br />
| splash<br />
| 5<br />
|-<br />
| wake<br />
| 6<br />
|-<br />
| suspended<br />
| 7<br />
|-<br />
| depthsuspend<br />
| 8<br />
|-<br />
| crit<br />
| 9<br />
|-<br />
| magicCrit<br />
| 10<br />
|-<br />
| smoke<br />
| 11<br />
|-<br />
| largesmoke<br />
| 12<br />
|-<br />
| spell<br />
| 13<br />
|-<br />
| instantSpell<br />
| 14<br />
|-<br />
| mobSpell<br />
| 15<br />
|-<br />
| mobSpellAmbient<br />
| 16<br />
|-<br />
| witchMagic<br />
| 17<br />
|-<br />
| dripWater<br />
| 18<br />
|-<br />
| dripLava<br />
| 19<br />
|-<br />
| angryVillager<br />
| 20<br />
|-<br />
| happyVillager<br />
| 21<br />
|-<br />
| townaura<br />
| 22<br />
|-<br />
| note<br />
| 23<br />
|-<br />
| portal<br />
| 24<br />
|-<br />
| enchantmenttable<br />
| 25<br />
|-<br />
| flame<br />
| 26<br />
|-<br />
| lava<br />
| 27<br />
|-<br />
| footstep<br />
| 28<br />
|-<br />
| cloud<br />
| 29<br />
|-<br />
| reddust<br />
| 30<br />
|-<br />
| snowballpoof<br />
| 31<br />
|-<br />
| snowshovel<br />
| 32<br />
|-<br />
| slime<br />
| 33<br />
|-<br />
| heart<br />
| 34<br />
|-<br />
| barrier<br />
| 35<br />
|-<br />
| iconcrack_(id)_(data)<br />
| 36<br />
|-<br />
| blockcrack_(id+(data<<12))<br />
| 37<br />
|-<br />
| blockdust_(id)<br />
| 38<br />
|-<br />
| droplet<br />
| 39<br />
|-<br />
| take<br />
| 40<br />
|-<br />
| mobappearance<br />
| 41<br />
|-<br />
| dragonbreath<br />
| 42<br />
|-<br />
| endrod<br />
| 43<br />
|-<br />
| damageindicator<br />
| 44<br />
|-<br />
| sweepattack<br />
| 45<br />
|-<br />
| fallingdust<br />
| 46<br />
|}<br />
<br />
==== Join Game ====<br />
<br />
See [[Protocol Encryption]] for information on logging in.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="7"| 0x23<br />
|rowspan="7"| Play<br />
|rowspan="7"| Client<br />
| Entity ID<br />
| Int<br />
| The player's Entity ID (EID)<br />
|-<br />
| Gamemode<br />
| Unsigned Byte<br />
| 0: Survival, 1: Creative, 2: Adventure, 3: Spectator. Bit 3 (0x8) is the hardcore flag.<br />
|-<br />
| Dimension<br />
| Int Enum<br />
| -1: Nether, 0: Overworld, 1: End; also, note that this is not a VarInt but instead a regular int.<br />
|-<br />
| Difficulty<br />
| Unsigned Byte<br />
| 0: peaceful, 1: easy, 2: normal, 3: hard<br />
|-<br />
| Max Players<br />
| Unsigned Byte<br />
| Was once used by the client to draw the player list, but now is ignored<br />
|-<br />
| Level Type<br />
| String Enum (16)<br />
| default, flat, largeBiomes, amplified, default_1_1<br />
|-<br />
| Reduced Debug Info<br />
| Boolean<br />
| If true, a Notchian client shows reduced information on the {{Minecraft Wiki|debug screen}}. For servers in development, this should almost always be false.<br />
|}<br />
<br />
==== Map ====<br />
<br />
Updates a rectangular area on a {{Minecraft Wiki|map}} item.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
!colspan="2"| Field Name<br />
!colspan="2"| Field Type<br />
! Notes<br />
|-<br />
|rowspan="13"| 0x24<br />
|rowspan="13"| Play<br />
|rowspan="13"| Client<br />
|colspan="2"| Item Damage<br />
|colspan="2"| VarInt<br />
| The damage value (map ID) of the map being modified<br />
|-<br />
|colspan="2"| Scale<br />
|colspan="2"| Byte<br />
| From 0 for a fully zoomed-in map (1 block per pixel) to 4 for a fully zoomed-out map (16 blocks per pixel)<br />
|- <br />
|colspan="2"| Tracking Position<br />
|colspan="2"| Boolean<br />
| Specifies whether the icons are shown<br />
|- <br />
|colspan="2"| Icon Count<br />
|colspan="2"| VarInt<br />
| Number of elements in the following array<br />
|-<br />
|rowspan="3"| Icon<br />
| Direction And Type<br />
|rowspan="3"| Array<br />
| Byte<br />
| 0xF0 = Direction, 0x0F = Type<br />
|-<br />
| X<br />
| Byte<br />
| <br />
|-<br />
| Z<br />
| Byte<br />
| <br />
|- <br />
|colspan="2"| Columns<br />
|colspan="2"| Byte<br />
| Number of columns updated<br />
|-<br />
|colspan="2"| Rows<br />
|colspan="2"| Optional Byte<br />
| Only if Columns is more than 0; number of rows updated<br />
|-<br />
|colspan="2"| X<br />
|colspan="2"| Optional Byte<br />
| Only if Columns is more than 0; x offset of the westernmost column<br />
|-<br />
|colspan="2"| Z<br />
|colspan="2"| Optional Byte<br />
| Only if Columns is more than 0; z offset of the northernmost row<br />
|-<br />
|colspan="2"| Length<br />
|colspan="2"| Optional VarInt<br />
| Only if Columns is more than 0; length of the following array<br />
|-<br />
|colspan="2"| Data<br />
|colspan="2"| Optional Array of Unsigned Byte<br />
| Only if Columns is more than 0; see {{Minecraft Wiki|Map item format}}<br />
|}<br />
<br />
For icons, a direction of 0 is a vertical icon and increments by 22.5&deg; (360/16).<br />
<br />
Types are based off of rows and columns in <code>map_icons.png</code>:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Icon type<br />
! Result<br />
|-<br />
| 0<br />
| White arrow (players)<br />
|-<br />
| 1<br />
| Green arrow (item frames)<br />
|-<br />
| 2<br />
| Red arrow<br />
|-<br />
| 3<br />
| Blue arrow<br />
|-<br />
| 4<br />
| White cross<br />
|-<br />
| 5<br />
| Red pointer<br />
|-<br />
| 6<br />
| White circle (off-map players)<br />
|-<br />
| 7<br />
| Small white circle (far-off-map players)<br />
|-<br />
| 8<br />
| Mansion<br />
|-<br />
| 9<br />
| Temple<br />
|-<br />
| 10-15<br />
| Unused (blue square)<br />
|}<br />
<br />
==== Entity ====<br />
<br />
This packet may be used to initialize an entity.<br />
<br />
For player entities, either this packet or any move/look packet is sent every game tick. So the meaning of this packet is basically that the entity did not move/look since the last such packet.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x25<br />
|rowspan="1"| Play<br />
|rowspan="1"| Client<br />
| Entity ID<br />
| VarInt<br />
| <br />
|}<br />
<br />
==== Entity Relative Move ====<br />
<br />
This packet is sent by the server when an entity moves less then 8 blocks; if an entity moves more than 8 blocks [[#Entity Teleport|Entity Teleport]] ([[#Play|Play]], 0x4A, clientbound) should be sent instead.<br />
<br />
This packet allows at most 8 blocks movement in any direction, because short range is from -32768 to 32767. And <code>32768 / (128 * 32)</code> = 8.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="5"| 0x26<br />
|rowspan="5"| Play<br />
|rowspan="5"| Client<br />
| Entity ID<br />
| VarInt<br />
| <br />
|-<br />
| Delta X<br />
| Short<br />
| Change in X position as <code>(currentX * 32 - prevX * 32) * 128</code><br />
|-<br />
| Delta Y<br />
| Short<br />
| Change in Y position as <code>(currentY * 32 - prevY * 32) * 128</code><br />
|-<br />
| Delta Z<br />
| Short<br />
| Change in Z position as <code>(currentZ * 32 - prevZ * 32) * 128</code><br />
|-<br />
| On Ground<br />
| Boolean<br />
| <br />
|}<br />
<br />
==== Entity Look And Relative Move ====<br />
<br />
This packet is sent by the server when an entity rotates and moves. Since a short range is limited from -32768 to 32767, and movement is offset of fixed-point numbers, this packet allows at most 8 blocks movement in any direction. (<code>-32768 / (32 * 128) == -8</code>)<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="7"| 0x27<br />
|rowspan="7"| Play<br />
|rowspan="7"| Client<br />
| Entity ID<br />
| VarInt<br />
| <br />
|-<br />
| Delta X<br />
| Short<br />
| Change in X position as <code>(currentX * 32 - prevX * 32) * 128</code><br />
|-<br />
| Delta Y<br />
| Short<br />
| Change in Y position as <code>(currentY * 32 - prevY * 32) * 128</code><br />
|-<br />
| Delta Z<br />
| Short<br />
| Change in Z position as <code>(currentZ * 32 - prevZ * 32) * 128</code><br />
|-<br />
| Yaw<br />
| Angle<br />
| New angle, not a delta<br />
|-<br />
| Pitch<br />
| Angle<br />
| New angle, not a delta<br />
|-<br />
| On Ground<br />
| Boolean<br />
| <br />
|}<br />
<br />
==== Entity Look ====<br />
<br />
This packet is sent by the server when an entity rotates.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="4"| 0x28<br />
|rowspan="4"| Play<br />
|rowspan="4"| Client<br />
| Entity ID<br />
| VarInt<br />
| <br />
|-<br />
| Yaw<br />
| Angle<br />
| New angle, not a delta<br />
|-<br />
| Pitch<br />
| Angle<br />
| New angle, not a delta<br />
|-<br />
| On Ground<br />
| Boolean<br />
| <br />
|}<br />
<br />
==== Vehicle Move (clientbound) ====<br />
<br />
Note that all fields use absolute positioning and do not allow for relative positioning.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="7"| 0x29<br />
|rowspan="7"| Play<br />
|rowspan="7"| Client<br />
| X<br />
| Double<br />
| Absolute position (X coordinate)<br />
|-<br />
| Y<br />
| Double<br />
| Absolute position (Y coordinate)<br />
|-<br />
| Z<br />
| Double<br />
| Absolute position (Z coordinate)<br />
|-<br />
| Yaw<br />
| Float<br />
| Absolute rotation on the vertical axis, in degrees<br />
|-<br />
| Pitch<br />
| Float<br />
| Absolute rotation on the horizontal axis, in degrees<br />
|}<br />
<br />
==== Open Sign Editor ====<br />
<br />
Sent when the client has placed a sign and is allowed to send [[#Update Sign|Update Sign]].<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x2A<br />
|rowspan="1"| Play<br />
|rowspan="1"| Client<br />
| Location<br />
| Position<br />
| <br />
|}<br />
<br />
==== Player Abilities (clientbound) ====<br />
<br />
The latter 2 floats are used to indicate the field of view and flying speed respectively, while the first byte is used to determine the value of 4 booleans.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x2B<br />
|rowspan="3"| Play<br />
|rowspan="3"| Client<br />
| Flags<br />
| Byte<br />
| Bit field, see below<br />
|-<br />
| Flying Speed<br />
| Float<br />
| <br />
|-<br />
| Field of View Modifier<br />
| Float<br />
| Modifies the field of view, like a speed potion. A Notchian server will use the same value as the movement speed (send in the [[Protocol#Entity_Properties|Entity Properties]] packet).<br />
|}<br />
<br />
About the flags:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Field<br />
! Bit<br />
|-<br />
| Invulnerable<br />
| 0x01<br />
|-<br />
| Flying<br />
| 0x02<br />
|-<br />
| Allow Flying<br />
| 0x04<br />
|-<br />
| Creative Mode<br />
| 0x08<br />
|}<br />
<br />
==== Combat Event ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
!colspan="2"| Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="8"| 0x2C<br />
|rowspan="8"| Play<br />
|rowspan="8"| Client<br />
|colspan="2"| Event<br />
| VarInt Enum<br />
| Determines the layout of the remaining packet<br />
|-<br />
! Event<br />
! Field Name<br />
! <br />
! <br />
|-<br />
| 0: enter combat<br />
| ''no fields''<br />
| ''no fields''<br />
| <br />
|-<br />
|rowspan="2"| 1: end combat<br />
| Duration<br />
| VarInt<br />
| <br />
|-<br />
| Entity ID<br />
| Int<br />
| <br />
|-<br />
|rowspan="3"| 2: entity dead<br />
| Player ID<br />
| VarInt<br />
| <br />
|-<br />
| Entity ID<br />
| Int<br />
| <br />
|-<br />
| Message<br />
| [[Chat]]<br />
| <br />
|}<br />
<br />
==== Player List Item ====<br />
<br />
Sent by the server to update the user list (<tab> in the client).<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
!colspan="4"| Field Name<br />
!colspan="3"| Field Type<br />
! Notes<br />
|-<br />
|rowspan="19"| 0x2D<br />
|rowspan="19"| Play<br />
|rowspan="19"| Client<br />
|colspan="4"| Action<br />
|colspan="3"| VarInt<br />
| Determines the rest of the Player format after the UUID<br />
|-<br />
|colspan="4"| Number Of Players<br />
|colspan="3"| VarInt<br />
| Number of elements in the following array<br />
|-<br />
|rowspan="17"| Player<br />
|colspan="3"| UUID<br />
|rowspan="17"| Array<br />
|colspan="2"| UUID<br />
| <br />
|-<br />
! Action<br />
!colspan="2"| Field Name<br />
!colspan="2"| <br />
! <br />
|-<br />
|rowspan="10"| 0: add player<br />
|colspan="2"| Name<br />
|colspan="2"| String (16)<br />
| <br />
|-<br />
|colspan="2"| Number Of Properties<br />
|colspan="2"| VarInt<br />
| Number of elements in the following array<br />
|-<br />
|rowspan="4"| Property<br />
| Name<br />
|rowspan="4"| Array<br />
| String (32767)<br />
| <br />
|-<br />
| Value<br />
| String (32767)<br />
| <br />
|- <br />
| Is Signed<br />
| Boolean<br />
| <br />
|-<br />
| Signature<br />
| Optional String (32767)<br />
| Only if Is Signed is true<br />
|-<br />
|colspan="2"| Gamemode<br />
|colspan="2"| VarInt<br />
| <br />
|-<br />
|colspan="2"| Ping<br />
|colspan="2"| VarInt<br />
| <br />
|-<br />
|colspan="2"| Has Display Name<br />
|colspan="2"| Boolean<br />
| <br />
|-<br />
|colspan="2"| Display Name<br />
|colspan="2"| Optional [[Chat]]<br />
| Only if Has Display Name is true<br />
|-<br />
| 1: update gamemode<br />
|colspan="2"| Gamemode<br />
|colspan="2"| VarInt<br />
| <br />
|- <br />
| 2: update latency<br />
|colspan="2"| Ping<br />
|colspan="2"| VarInt<br />
| <br />
|-<br />
|rowspan="2"| 3: update display name<br />
|colspan="2"| Has Display Name<br />
|colspan="2"| Boolean<br />
| <br />
|-<br />
|colspan="2"| Display Name<br />
|colspan="2"| Optional [[Chat]]<br />
| Only send if Has Display Name is true<br />
|-<br />
| 4: remove player<br />
|colspan="2"| ''no fields''<br />
|colspan="2"| ''no fields''<br />
| <br />
|}<br />
<br />
The Property field looks as in the response of [[Mojang API#UUID -> Profile + Skin/Cape]], except of course using the protocol format instead of JSON. That is, each player will usually have one property with Name “textures” and Value being a base64-encoded JSON string as documented at [[Mojang API#UUID -> Profile + Skin/Cape]]. An empty properties array is also acceptable, and will cause clients to display the player with one of the two default skins depending on UUID.<br />
<br />
==== Player Position And Look (clientbound) ==== <br />
<br />
Updates the player's position on the server. This packet will also close the “Downloading Terrain” screen when joining/respawning.<br />
<br />
If the distance between the last known position of the player on the server and the new position set by this packet is greater than 100 meters, the client will be kicked for “You moved too quickly :( (Hacking?)”.<br />
<br />
Also if the fixed-point number of X or Z is set greater than <code>3.2E7D</code> the client will be kicked for “Illegal position”.<br />
<br />
Yaw is measured in degrees, and does not follow classical trigonometry rules. The unit circle of yaw on the XZ-plane starts at (0, 1) and turns counterclockwise, with 90 at (-1, 0), 180 at (0, -1) and 270 at (1, 0). Additionally, yaw is not clamped to between 0 and 360 degrees; any number is valid, including negative numbers and numbers greater than 360.<br />
<br />
Pitch is measured in degrees, where 0 is looking straight ahead, -90 is looking straight up, and 90 is looking straight down.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="7"| 0x2E<br />
|rowspan="7"| Play<br />
|rowspan="7"| Client<br />
| X<br />
| Double<br />
| Absolute or relative position, depending on Flags<br />
|-<br />
| Y<br />
| Double<br />
| Absolute or relative position, depending on Flags<br />
|-<br />
| Z<br />
| Double<br />
| Absolute or relative position, depending on Flags<br />
|-<br />
| Yaw<br />
| Float<br />
| Absolute or relative rotation on the X axis, in degrees<br />
|-<br />
| Pitch<br />
| Float<br />
| Absolute or relative rotation on the Y axis, in degrees<br />
|-<br />
| Flags<br />
| Byte<br />
| Bit field, see below<br />
|-<br />
| Teleport ID<br />
| VarInt<br />
| Client should confirm this packet with [[#Teleport Confirm|Teleport Confirm]] containing the same Teleport ID<br />
|}<br />
<br />
About the Flags field:<br />
<br />
<Dinnerbone> It's a bitfield, X/Y/Z/Y_ROT/X_ROT. If X is set, the x value is relative and not absolute.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Field<br />
! Bit<br />
|-<br />
| X<br />
| 0x01<br />
|-<br />
| Y<br />
| 0x02<br />
|-<br />
| Z<br />
| 0x04<br />
|-<br />
| Y_ROT<br />
| 0x08<br />
|-<br />
| X_ROT<br />
| 0x10<br />
|}<br />
<br />
==== Use Bed ==== <br />
<br />
This packet tells that a player goes to bed.<br />
<br />
The client with the matching Entity ID will go into bed mode.<br />
<br />
This Packet is sent to all nearby players including the one sent to bed.<br />
<br />
Any packets sent with a location not currently occupied by a bed will be ignored by clients.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x2F<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Entity ID<br />
| VarInt<br />
| Sleeping player's EID<br />
|-<br />
| Location<br />
| Position<br />
| Block location of the head part of the bed<br />
|}<br />
<br />
==== Unlock Recipes ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="8"| 0x30<br />
|rowspan="8"| Play<br />
|rowspan="8"| Client<br />
|-<br />
| Action<br />
| VarInt<br />
| 0: init, 1: add, 2: remove<br />
|-<br />
| Crafting Book Open<br />
| Boolean<br />
| If true, then the crafting book will be open when the player opens its inventory.<br />
|-<br />
| Filtering Craftable<br />
| Boolean<br />
| If true, then the filtering option is active when the players opens its inventory.<br />
|-<br />
| Array size 1<br />
| VarInt<br />
| Number of elements in the following array<br />
|-<br />
| Recipe IDs<br />
| Array of VarInt<br />
|<br />
|-<br />
| Array size 2<br />
| Optional VarInt<br />
| Number of elements in the following array, only present if mode is 0 (init)<br />
|-<br />
| Recipe IDs<br />
| Optional Array of VarInt, only present if mode is 0 (init)<br />
|<br />
|}<br />
Action:<br />
* 0 (init) = All the recipes in the list 2 will added to the recipe book. All the recipes in list 1 will be tagged as displayed, recipes that aren't tagged will be shown in the notification. VERIFY LIST ORDER?<br />
* 1 (add) = All the recipes in the list are added and their icon will be shown in the notification.<br />
* 2 (remove) = Remove all the recipes in the list. This allows them to re-displayed when they are readded.<br />
<br />
Recipe ID:<br />
These are hardcoded values in the client and server, all the recipe json files will be loaded in a specific order (alphabetical, like sounds) and internal ids will be assigned in that order. There are also inbuilt recipes like fireworks, banners, etc., these are the first recipes to have their id assigned. Due the fact that the recipes are loaded in a specific order will the ids very likely change when recipes get added. [https://twitter.com/dinnerbone/status/856505341479145472 Custom recipes are scheduled for Minecraft 1.13], so most likely will things change a bit in that version.<br />
<br />
==== Destroy Entities ====<br />
<br />
Sent by the server when a list of entities is to be destroyed on the client.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x31<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Count<br />
| VarInt<br />
| Number of elements in the following array<br />
|-<br />
| Entity IDs<br />
| Array of VarInt<br />
| The list of entities of destroy<br />
|}<br />
<br />
==== Remove Entity Effect ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x32<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Entity ID<br />
| VarInt<br />
| <br />
|-<br />
| Effect ID<br />
| Byte<br />
| See {{Minecraft Wiki|Status effect#List of effects|this table}}<br />
|}<br />
<br />
==== Resource Pack Send ==== <br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x33<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| URL<br />
| String (32767)<br />
| The URL to the resource pack.<br />
|-<br />
| Hash<br />
| String (40)<br />
| A 40 character hexadecimal and lowercase [[wikipedia:SHA-1|SHA-1]] hash of the resource pack file. (must be lower case in order to work)<br />If it's not a 40 character hexadecimal string, the client will not use it for hash verification and likely waste bandwidth — but it will still treat it as a unique id<br />
|}<br />
<br />
==== Respawn ====<br />
<br />
To change the player's dimension (overworld/nether/end), send them a respawn packet with the appropriate dimension, followed by prechunks/chunks for the new dimension, and finally a position and look packet. You do not need to unload chunks, the client will do it automatically.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="4"| 0x34<br />
|rowspan="4"| Play<br />
|rowspan="4"| Client<br />
| Dimension<br />
| Int Enum<br />
| -1: The Nether, 0: The Overworld, 1: The End<br />
|-<br />
| Difficulty<br />
| Unsigned Byte<br />
| 0: Peaceful, 1: Easy, 2: Normal, 3: Hard<br />
|-<br />
| Gamemode<br />
| Unsigned Byte<br />
| 0: survival, 1: creative, 2: adventure, 3: spectator. The hardcore flag is not included<br />
|-<br />
| Level Type<br />
| String (16)<br />
| Same as [[#Join Game|Join Game]]<br />
|}<br />
<br />
{{Warning2|Avoid changing player's dimension to same dimension they were already in unless they are dead. If you change the dimension to one they are already in, weird bugs can occur, such as the player being unable to attack other players in new world (until they die and respawn).<br />
<br />
If you must respawn a player in the same dimension without killing them, send two respawn packets, one to a different world and then another to the world you want. You do not need to complete the first respawn; it only matters that you send two packets.}}<br />
<br />
==== Entity Head Look ====<br />
<br />
Changes the direction an entity's head is facing.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x35<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Entity ID<br />
| VarInt<br />
| <br />
|-<br />
| Head Yaw<br />
| Angle<br />
| New angle, not a delta<br />
|}<br />
<br />
==== Select Advancement Tab ====<br />
<br />
Sent by the server to indicate that the client should switch advancement tab. Sent either when the client switches tab in the GUI or when an advancement in another tab is made.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x36<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Has id<br />
| Boolean<br />
| Indicates if the next field is present<br />
|-<br />
| Optional Identifier<br />
| String (32767)<br />
| See below<br />
|}<br />
<br />
The Identifier can be one of the following:<br />
<br />
{| class="wikitable"<br />
! Optional Identifier<br />
|-<br />
| minecraft:story/root<br />
|-<br />
| minecraft:nether/root<br />
|-<br />
| minecraft:end/root<br />
|-<br />
| minecraft:adventure/root<br />
|-<br />
| minecraft:husbandry/root<br />
|}<br />
<br />
If no or an invalid identifier is sent, the client will switch to the first tab in the GUI.<br />
<br />
==== World Border ==== <br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
!colspan="2"| Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="18"| 0x37<br />
|rowspan="18"| Play<br />
|rowspan="18"| Client<br />
|colspan="2"| Action<br />
| VarInt Enum<br />
| Determines the format of the rest of the packet<br />
|-<br />
! Action<br />
! Field Name<br />
! <br />
! <br />
|-<br />
| 0: set size<br />
| Diameter<br />
| Double<br />
| Length of a single side of the world border, in meters<br />
|-<br />
|rowspan="3"| 1: lerp size<br />
| Old Diameter<br />
| Double<br />
| Current length of a single side of the world border, in meters<br />
|-<br />
| New Diameter<br />
| Double<br />
| Target length of a single side of the world border, in meters<br />
|-<br />
| Speed<br />
| VarLong<br />
| Number of real-time ''milli''seconds until New Diameter is reached. It appears that Notchian server does not sync world border speed to game ticks, so it gets out of sync with server lag. If the world border is not moving, this is set to 0.<br />
|-<br />
|rowspan="2"| 2: set center<br />
| X<br />
| Double<br />
| <br />
|-<br />
| Z<br />
| Double<br />
| <br />
|-<br />
|rowspan="8"| 3: initialize<br />
| X<br />
| Double<br />
| <br />
|-<br />
| Z<br />
| Double<br />
| <br />
|-<br />
| Old Diameter<br />
| Double<br />
| Current length of a single side of the world border, in meters<br />
|-<br />
| New Diameter<br />
| Double<br />
| Target length of a single side of the world border, in meters<br />
|-<br />
| Speed<br />
| VarLong<br />
| Number of real-time ''milli''seconds until New Diameter is reached. It appears that Notchian server does not sync world border speed to game ticks, so it gets out of sync with server lag. If the world border is not moving, this is set to 0.<br />
|-<br />
| Portal Teleport Boundary<br />
| VarInt<br />
| Resulting coordinates from a portal teleport are limited to ±value. Usually 29999984.<br />
|-<br />
| Warning Time<br />
| VarInt<br />
| In seconds as set by <code>/worldborder warning time</code><br />
|-<br />
| Warning Blocks<br />
| VarInt<br />
| In meters<br />
|-<br />
|rowspan="1"| 4: set warning time<br />
| Warning Time<br />
| VarInt<br />
| In seconds as set by <code>/worldborder warning time</code><br />
|-<br />
|rowspan="1"| 5: set warning blocks<br />
| Warning Blocks<br />
| VarInt<br />
| In meters<br />
|}<br />
<br />
The Notchian client determines how solid to display the warning by comparing to whichever is higher, the warning distance or whichever is lower, the distance from the current diameter to the target diameter or the place the border will be after warningTime seconds. In pseudocode:<br />
<br />
<syntaxhighlight lang="java"><br />
distance = max(min(resizeSpeed * 1000 * warningTime, abs(targetDiameter - currentDiameter)), warningDistance);<br />
if (playerDistance < distance) {<br />
warning = 1.0 - playerDistance / distance;<br />
} else {<br />
warning = 0.0;<br />
}<br />
</syntaxhighlight><br />
<br />
==== Camera ====<br />
<br />
Sets the entity that the player renders from. This is normally used when the player left-clicks an entity while in spectator mode.<br />
<br />
The player's camera will move with the entity and look where it is looking. The entity is often another player, but can be any type of entity. The player is unable to move this entity (move packets will act as if they are coming from the other entity).<br />
<br />
If the given entity is not loaded by the player, this packet is ignored. To return control to the player, send this packet with their entity ID.<br />
<br />
The Notchian server resets this (sends it back to the default entity) whenever the spectated entity is killed or the player sneaks, but only if they were spectating an entity. It also sends this packet whenever the player switches out of spectator mode (even if they weren't spectating an entity).<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x38<br />
|rowspan="1"| Play<br />
|rowspan="1"| Client<br />
| Camera ID<br />
| VarInt<br />
| ID of the entity to set the client's camera to<br />
|}<br />
<br />
The notchian also loads certain shaders for given entities:<br />
<br />
* Creeper &rarr; <code>shaders/post/creeper.json</code><br />
* Spider (and cave spider) &rarr; <code>shaders/post/spider.json</code><br />
* Enderman &rarr; <code>shaders/post/invert.json</code><br />
* Anything else &rarr; the current shader is unloaded<br />
<br />
==== Held Item Change (clientbound) ====<br />
<br />
Sent to change the player's slot selection.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x39<br />
|rowspan="1"| Play<br />
|rowspan="1"| Client<br />
| Slot<br />
| Byte<br />
| The slot which the player has selected (0–8)<br />
|}<br />
<br />
==== Display Scoreboard ====<br />
<br />
This is sent to the client when it should display a scoreboard.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x3A<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Position<br />
| Byte<br />
| The position of the scoreboard. 0: list, 1: sidebar, 2: below name.<br />
|-<br />
| Score Name<br />
| String (16)<br />
| The unique name for the scoreboard to be displayed.<br />
|}<br />
<br />
==== Entity Metadata ====<br />
<br />
Updates one or more [[Entities#Entity Metadata Format|metadata]] properties for an existing entity. Any properties not included in the Metadata field are left unchanged.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x3B<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Entity ID<br />
| VarInt<br />
| <br />
|-<br />
| Metadata<br />
| [[Entities#Entity Metadata Format|Entity Metadata]]<br />
| <br />
|}<br />
<br />
==== Attach Entity ====<br />
<br />
This packet is sent when an entity has been {{Minecraft Wiki|Lead|leashed}} to another entity.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x3C<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Attached Entity ID<br />
| Int<br />
| Attached entity's EID<br />
|-<br />
| Holding Entity ID<br />
| Int<br />
| ID of the entity holding the lead. Set to -1 to detach.<br />
|}<br />
<br />
==== Entity Velocity ====<br />
<br />
Velocity is believed to be in units of 1/8000 of a block per server tick (50ms); for example, -1343 would move (-1343 / 8000) = −0.167875 blocks per tick (or −3,3575 blocks per second).<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="4"| 0x3D<br />
|rowspan="4"| Play<br />
|rowspan="4"| Client<br />
| Entity ID<br />
| VarInt<br />
| <br />
|-<br />
| Velocity X<br />
| Short<br />
| Velocity on the X axis<br />
|-<br />
| Velocity Y<br />
| Short<br />
| Velocity on the Y axis<br />
|-<br />
| Velocity Z<br />
| Short<br />
| Velocity on the Z axis<br />
|}<br />
<br />
==== Entity Equipment ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x3E<br />
|rowspan="3"| Play<br />
|rowspan="3"| Client<br />
| Entity ID<br />
| VarInt<br />
| Entity's EID<br />
|-<br />
| Slot<br />
| VarInt Enum<br />
| Equipment slot. 0: main hand, 1: off hand, 2–5: armor slot (2: boots, 3: leggings, 4: chestplate, 5: helmet)<br />
|-<br />
| Item<br />
| [[Slot Data|Slot]]<br />
| <br />
|}<br />
<br />
==== Set Experience ====<br />
<br />
Sent by the server when the client should change experience levels.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x3F<br />
|rowspan="3"| Play<br />
|rowspan="3"| Client<br />
| Experience bar<br />
| Float<br />
| Between 0 and 1<br />
|-<br />
| Level<br />
| VarInt<br />
| <br />
|-<br />
| Total Experience<br />
| VarInt<br />
| See {{Minecraft Wiki|Experience#Leveling up}} on the Minecraft Wiki for Total Experience to Level conversion<br />
|}<br />
<br />
==== Update Health ====<br />
<br />
Sent by the server to update/set the health of the player it is sent to.<br />
<br />
Food {{Minecraft Wiki|Food#Hunger vs. Saturation|saturation}} acts as a food “overcharge”. Food values will not decrease while the saturation is over zero. Players logging in automatically get a saturation of 5.0. Eating food increases the saturation as well as the food bar.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x40<br />
|rowspan="3"| Play<br />
|rowspan="3"| Client<br />
| Health<br />
| Float<br />
| 0 or less = dead, 20 = full HP<br />
|-<br />
| Food<br />
| VarInt<br />
| 0–20<br />
|- <br />
| Food Saturation<br />
| Float<br />
| Seems to vary from 0.0 to 5.0 in integer increments<br />
|}<br />
<br />
==== Scoreboard Objective ====<br />
<br />
This is sent to the client when it should create a new {{Minecraft Wiki|scoreboard}} objective or remove one.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="4"| 0x41<br />
|rowspan="4"| Play<br />
|rowspan="4"| Client<br />
| Objective Name<br />
| String (16)<br />
| An unique name for the objective<br />
|-<br />
| Mode<br />
| Byte<br />
| 0 to create the scoreboard. 1 to remove the scoreboard. 2 to update the display text. <br />
|-<br />
| Objective Value<br />
| Optional String (32)<br />
| Only if mode is 0 or 2. The text to be displayed for the score<br />
|-<br />
| Type<br />
| Optional String (16)<br />
| Only if mode is 0 or 2. “integer” or “hearts”<br />
|}<br />
<br />
==== Set Passengers ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x42<br />
|rowspan="3"| Play<br />
|rowspan="3"| Client<br />
| Entity ID<br />
| VarInt<br />
| Vehicle's EID<br />
|-<br />
| Passenger Count<br />
| VarInt<br />
| Number of elements in the following array<br />
|-<br />
| Passengers<br />
| Array of VarInt<br />
| EIDs of entity's passengers<br />
|}<br />
<br />
==== Teams ====<br />
<br />
Creates and updates teams.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
!colspan="2"| Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="23"| 0x43<br />
|rowspan="23"| Play<br />
|rowspan="23"| Client<br />
|colspan="2"| Team Name<br />
| String (16)<br />
| A unique name for the team. (Shared with scoreboard).<br />
|-<br />
|colspan="2"| Mode<br />
| Byte<br />
| Determines the layout of the remaining packet<br />
|-<br />
|rowspan="9"| 0: create team<br />
| Team Display Name<br />
| String (32)<br />
| <br />
|-<br />
| Team Prefix<br />
| String (16)<br />
| Displayed before the names of players that are part of this team<br />
|-<br />
| Team Suffix<br />
| String (16)<br />
| Displayed after the names of players that are part of this team<br />
|-<br />
| Friendly Flags<br />
| Byte<br />
| Bit mask. 0x01: Allow friendly fire, 0x02: can see invisible players on same team<br />
|-<br />
| Name Tag Visibility<br />
| String Enum (32)<br />
| <code>always</code>, <code>hideForOtherTeams</code>, <code>hideForOwnTeam</code>, <code>never</code><br />
|-<br />
| Collision Rule<br />
| String Enum (32)<br />
| <code>always</code>, <code>pushOtherTeams</code>, <code>pushOwnTeam</code>, <code>never</code><br />
|-<br />
| Color<br />
| Byte<br />
| For colors, the same [[Chat]] colors (0-15). -1 indicates RESET/no color.<br />
|-<br />
| Entity Count<br />
| VarInt<br />
| Number of elements in the following array<br />
|-<br />
| Entities<br />
| Array of String (40)<br />
| Identifiers for the entities in this team. For players, this is their username; for other entities, it is their UUID.<br />
|-<br />
| 1: remove team<br />
| ''no fields''<br />
| ''no fields''<br />
| <br />
|-<br />
|rowspan="7"| 2: update team info<br />
| Team Display Name<br />
| String (32)<br />
| <br />
|-<br />
| Team Prefix<br />
| String (16)<br />
| Displayed before the names of entities that are part of this team<br />
|-<br />
| Team Suffix<br />
| String (16)<br />
| Displayed after the names of entities that are part of this team<br />
|-<br />
| Friendly Flags<br />
| Byte<br />
| Bit mask. 0x01: Allow friendly fire, 0x02: can see invisible entities on same team<br />
|-<br />
| Name Tag Visibility<br />
| String Enum (32)<br />
| <code>always</code>, <code>hideForOtherTeams</code>, <code>hideForOwnTeam</code>, <code>never</code><br />
|-<br />
| Collision Rule<br />
| String Enum (32)<br />
| <code>always</code>, <code>pushOtherTeams</code>, <code>pushOwnTeam</code>, <code>never</code><br />
|-<br />
| Color<br />
| Byte<br />
| For colors, the same [[Chat]] colors (0-15). -1 indicates RESET/no color.<br />
|-<br />
|rowspan="2"| 3: add players to team<br />
| Entity Count<br />
| VarInt<br />
| Number of elements in the following array<br />
|-<br />
| Entities<br />
| Array of String (40)<br />
| Identifiers for the entities added. For players, this is their username; for other entities, it is their UUID.<br />
|-<br />
|rowspan="2"| 4: remove players from team<br />
| Entity Count<br />
| VarInt<br />
| Number of elements in the following array<br />
|-<br />
| Entities<br />
| Array of String (40)<br />
| Identifiers for the entities removed. For players, this is their username; for other entities, it is their UUID.<br />
|}<br />
<br />
==== Update Score ====<br />
<br />
This is sent to the client when it should update a scoreboard item. <br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="4"| 0x44<br />
|rowspan="4"| Play<br />
|rowspan="4"| Client<br />
| Entity Name<br />
| String (40)<br />
| The entity whose score this is. For players, this is their username; for other entities, it is their UUID.<br />
|-<br />
| Action<br />
| Byte<br />
| 0 to create/update an item. 1 to remove an item.<br />
|-<br />
| Objective Name<br />
| String (16)<br />
| The name of the objective the score belongs to<br />
|-<br />
| Value<br />
| Optional VarInt<br />
| The score to be displayed next to the entry. Only sent when Action does not equal 1.<br />
|}<br />
<br />
==== Spawn Position ====<br />
<br />
Sent by the server after login to specify the coordinates of the spawn point (the point at which players spawn at, and which the compass points to). It can be sent at any time to update the point compasses point at.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x45<br />
|rowspan="1"| Play<br />
|rowspan="1"| Client<br />
| Location<br />
| Position<br />
| Spawn location<br />
|}<br />
<br />
==== Time Update ====<br />
<br />
Time is based on ticks, where 20 ticks happen every second. There are 24000 ticks in a day, making Minecraft days exactly 20 minutes long.<br />
<br />
The time of day is based on the timestamp modulo 24000. 0 is sunrise, 6000 is noon, 12000 is sunset, and 18000 is midnight.<br />
<br />
The default SMP server increments the time by <code>20</code> every second.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x46<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| World Age<br />
| Long<br />
| In ticks; not changed by server commands<br />
|-<br />
| Time of day<br />
| Long<br />
| The world (or region) time, in ticks. If negative the sun will stop moving at the Math.abs of the time<br />
|}<br />
<br />
==== Title ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
!colspan="2"| Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="10"| 0x47<br />
|rowspan="10"| Play<br />
|rowspan="10"| Client<br />
|colspan="2"| Action<br />
| VarInt Enum<br />
| <br />
|-<br />
! Action<br />
! Field Name<br />
! <br />
! <br />
|-<br />
| 0: set title<br />
| Title Text<br />
| [[Chat]]<br />
| <br />
|-<br />
| 1: set subtitle<br />
| Subtitle Text<br />
| [[Chat]]<br />
| <br />
|- <br />
| 2: set action bar<br />
| Action bar text<br />
| [[Chat]]<br />
| Behaves the same as with position 2 in [[#Chat Message (clientbound)|Chat Message (clientbound)]]<br />
|-<br />
|rowspan="3"| 3: set times and display<br />
| Fade In<br />
| Int<br />
| Ticks to spend fading in<br />
|-<br />
| Stay<br />
| Int<br />
| Ticks to keep the title displayed<br />
|-<br />
| Fade Out<br />
| Int<br />
| Ticks to spend out, not when to start fading out<br />
|-<br />
| 4: hide<br />
| ''no fields''<br />
| ''no fields''<br />
| <br />
|-<br />
| 5: reset<br />
| ''no fields''<br />
| ''no fields''<br />
| <br />
|}<br />
<br />
“Hide” makes the title disappear, but if you run times again the same title will appear. “Reset” erases the text.<br />
<br />
The title is visible on screen for Fade In + Stay + Fade Out ticks.<br />
<br />
==== Sound Effect ====<br />
<br />
This packet is used to play a number of hardcoded sound events. For custom sounds, use [[#Named Sound Effect|Named Sound Effect]] ([[#Play|Play]], 0x19, clientbound).<br />
<br />
{{Warning|Numeric sound effect IDs are liable to change between versions}}<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="7"| 0x48<br />
|rowspan="7"| Play<br />
|rowspan="7"| Client<br />
| Sound ID<br />
| VarInt<br />
| ID of hardcoded sound event ([http://pokechu22.github.io/Burger/1.11.html#sounds events] as of 1.11.0)<br />
|-<br />
| Sound Category<br />
| VarInt Enum<br />
| The category that this sound will be played from ([https://gist.github.com/konwboj/7c0c380d3923443e9d55 current categories])<br />
|-<br />
| Effect Position X<br />
| Int<br />
| Effect X multiplied by 8 ([[Data types#Fixed-point numbers|fixed-point number]] with only 3 bits dedicated to the fractional part)<br />
|-<br />
| Effect Position Y<br />
| Int<br />
| Effect Y multiplied by 8 ([[Data types#Fixed-point numbers|fixed-point number]] with only 3 bits dedicated to the fractional part)<br />
|-<br />
| Effect Position Z<br />
| Int<br />
| Effect Z multiplied by 8 ([[Data types#Fixed-point numbers|fixed-point number]] with only 3 bits dedicated to the fractional part)<br />
|-<br />
| Volume<br />
| Float<br />
| 1.0 is 100%, capped between 0.0 and 1.0 by Notchian clients<br />
|-<br />
| Pitch<br />
| Float<br />
| Float between 0.5 and 2.0 by Notchian clients<br />
<br />
|}<br />
<br />
==== Player List Header And Footer ====<br />
<br />
This packet may be used by custom servers to display additional information above/below the player list. It is never sent by the Notchian server.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x49<br />
|rowspan="2"| Play<br />
|rowspan="2"| Client<br />
| Header<br />
| [[Chat]]<br />
| To remove the header, send a empty translatable component: {"translate":""}<br />
|-<br />
| Footer<br />
| [[Chat]]<br />
| To remove the footer, send a empty translatable component: {"translate":""}<br />
|}<br />
<br />
==== Collect Item ====<br />
<br />
Sent by the server when someone picks up an item lying on the ground — its sole purpose appears to be the animation of the item flying towards you. It doesn't destroy the entity in the client memory, and it doesn't add it to your inventory. The server only checks for items to be picked up after each [[#Player Position|Player Position]] (and [[#Player Position And Look|Player Position And Look]]) packet sent by the client.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x4A<br />
|rowspan="3"| Play<br />
|rowspan="3"| Client<br />
| Collected Entity ID<br />
| VarInt<br />
| <br />
|- <br />
| Collector Entity ID<br />
| VarInt<br />
| <br />
|- <br />
| Pickup Item Count<br />
| VarInt<br />
| Seems to be 1 for XP orbs, otherwise the number of items in the stack.<br />
|}<br />
<br />
==== Entity Teleport ====<br />
<br />
This packet is sent by the server when an entity moves more than 4 blocks.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="7"| 0x4B<br />
|rowspan="7"| Play<br />
|rowspan="7"| Client<br />
| Entity ID<br />
| VarInt<br />
| <br />
|-<br />
| X<br />
| Double<br />
| <br />
|-<br />
| Y<br />
| Double<br />
| <br />
|-<br />
| Z<br />
| Double<br />
| <br />
|-<br />
| Yaw<br />
| Angle<br />
| New angle, not a delta<br />
|-<br />
| Pitch<br />
| Angle<br />
| New angle, not a delta<br />
|-<br />
| On Ground<br />
| Boolean<br />
| <br />
|}<br />
<br />
==== Advancements ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
!colspan="2"| Field Name<br />
!colspan="2"| Field Type<br />
! Notes<br />
|-<br />
|rowspan="9"| 0x4C<br />
|rowspan="9"| Play<br />
|rowspan="9"| Client<br />
|colspan="2"| Reset/Clear<br />
|colspan="2"| Boolean<br />
| Whether to reset/clear the current advancements<br />
|-<br />
|colspan="2"| Mapping size<br />
|colspan="2"| VarInt<br />
| Size of the following array<br />
|-<br />
|rowspan="2"| Advancement mapping<br />
| Key<br />
|rowspan="2"| Array<br />
| Identifier<br />
| The identifier of the advancement<br />
|-<br />
| Value<br />
| Advancement<br />
| See below<br />
|-<br />
|colspan="2"| List size<br />
|colspan="2"| VarInt<br />
| Size of the following array<br />
|-<br />
|colspan="2"| Identifiers<br />
|colspan="2"| Array of Identifier<br />
| The identifiers of the advancements that should be removed<br />
|-<br />
|colspan="2"| Progress size<br />
|colspan="2"| VarInt<br />
| Size of the following array<br />
|-<br />
|rowspan="2"| Progress mapping<br />
| Key<br />
|rowspan="2"| Array<br />
| Identifier<br />
| The identifier of the advancement<br />
|-<br />
| Value<br />
| Advancement progress<br />
| See below<br />
|}<br />
<br />
Advancement structure:<br />
<br />
{| class="wikitable"<br />
!colspan="2"| Field Name<br />
!colspan="2"| Field Type<br />
! Notes<br />
|-<br />
|colspan="2"| Has parent<br />
|colspan="2"| Boolean<br />
| Indicates whether the next field exists.<br />
|-<br />
|colspan="2"| Parent id<br />
|colspan="2"| Optional Identifier<br />
| The identifier of the parent advancement.<br />
|-<br />
|colspan="2"| Has display<br />
|colspan="2"| Boolean<br />
| Indicates whether the next field exists<br />
|-<br />
|colspan="2"| Display data<br />
|colspan="2"| Optional advancement display<br />
| See below.<br />
|-<br />
|colspan="2"| Number of criteria<br />
|colspan="2"| VarInt<br />
| Size of the following array<br />
|-<br />
|rowspan="2"| Criteria<br />
| Key<br />
|rowspan="2"| Array<br />
| Identifier<br />
| The identifier of the criterion<br />
|-<br />
| Value<br />
| '''Void'''<br />
| There is ''no'' content written here. Perhaps this will be expanded in the future?<br />
|-<br />
|colspan="2"| Array length<br />
|colspan="2"| VarInt<br />
| Number of arrays in the following array<br />
|-<br />
|rowspan="2"| Requirements<br />
| Array length 2<br />
|rowspan="2"| Array<br />
| VarInt<br />
| Number of elements in the following array<br />
|-<br />
| Requirement<br />
| Array of String<br />
| Array of required criteria<br />
|}<br />
<br />
Advancement display:<br />
<br />
{| class="wikitable"<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
| Title<br />
| Chat<br />
|<br />
|-<br />
| Description<br />
| Chat<br />
|<br />
|-<br />
| Icon<br />
| [[Slot]]<br />
|<br />
|-<br />
| Frame type<br />
| VarInt enum<br />
| 0 = <code>task</code>, 1 = <code>challenge</code>, 2 = <code>goal</code><br />
|-<br />
| Flags<br />
| Integer<br />
| 0x1: has background texture; 0x2: <code>show_toast</code>; 0x4: <code>hidden</code><br />
|-<br />
| Background texture<br />
| Optional Identifier<br />
| Background texture location. Only if flags indicates it.<br />
|-<br />
| X coord<br />
| Float<br />
| <br />
|-<br />
| Y coord<br />
| Float<br />
| <br />
|}<br />
<br />
Advancement progress:<br />
<br />
{| class="wikitable"<br />
!colspan="2"| Field Name<br />
!colspan="2"| Field Type<br />
! Notes<br />
|-<br />
|colspan="2"| Size<br />
|colspan="2"| VarInt<br />
| Size of the following array<br />
|-<br />
|rowspan="2"| Criteria<br />
| Criterion identifier<br />
|rowspan="2"| Array<br />
| Identifier<br />
| The identifier of the criterion.<br />
|-<br />
| Criterion progress<br />
| Criterion progress<br />
|<br />
|}<br />
<br />
Criterion progress:<br />
<br />
{| class="wikitable"<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
| Achieved<br />
| Boolean<br />
| If true, next field is present<br />
|-<br />
| Date of achieving<br />
| Optional Long<br />
| As returned by [https://docs.oracle.com/javase/6/docs/api/java/util/Date.html#getTime() <code>Date.getTime</code>]<br />
|}<br />
<br />
==== Entity Properties ====<br />
<br />
Sets {{Minecraft Wiki|Attribute|attributes}} on the given entity.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
!colspan="2"| Field Name<br />
!colspan="2"| Field Type<br />
! Notes<br />
|-<br />
|rowspan="6"| 0x4D<br />
|rowspan="6"| Play<br />
|rowspan="6"| Client<br />
|colspan="2"| Entity ID<br />
|colspan="2"| VarInt<br />
| <br />
|-<br />
|colspan="2"| Number Of Properties<br />
|colspan="2"| Int<br />
| Number of elements in the following array<br />
|-<br />
|rowspan="4"| Property<br />
| Key<br />
|rowspan="4"| Array<br />
| String (64)<br />
| See below<br />
|-<br />
| Value<br />
| Double<br />
| See below<br />
|-<br />
| Number Of Modifiers<br />
| VarInt<br />
| Number of elements in the following array<br />
|-<br />
| Modifiers<br />
| Array of Modifier Data<br />
| See {{Minecraft Wiki|Attribute#Modifiers}}. Modifier Data defined below.<br />
|}<br />
<br />
Known Key values (see also {{Minecraft Wiki|Attribute#Modifiers}}):<br />
<br />
{| class="wikitable"<br />
|-<br />
! Key<br />
! Default<br />
! Min<br />
! Max<br />
! Label<br />
|-<br />
| generic.maxHealth<br />
| 20.0<br />
| 0.0<br />
| 1024.0<br />
| Max Health<br />
|-<br />
| generic.followRange<br />
| 32.0<br />
| 0.0<br />
| 2048.0<br />
| Follow Range<br />
|-<br />
| generic.knockbackResistance<br />
| 0.0 <br />
| 0.0<br />
| 1.0<br />
| Knockback Resistance<br />
|-<br />
| generic.movementSpeed<br />
| 0.699999988079071<br />
| 0.0<br />
| 1024.0<br />
| Movement Speed<br />
|-<br />
| generic.attackDamage<br />
| 2.0<br />
| 0.0<br />
| 2048.0<br />
| Attack Damage<br />
|-<br />
| generic.attackSpeed<br />
| 4.0<br />
| 0.0<br />
| 1024.0<br />
| Attack Speed<br />
|-<br />
| generic.flyingSpeed<br />
| 0.4000000059604645<br />
| 0.0<br />
| 1024.0<br />
| Flying Speed<br />
|-<br />
| horse.jumpStrength<br />
| 0.7<br />
| 0.0<br />
| 2.0<br />
| Jump Strength<br />
|-<br />
| zombie.spawnReinforcements<br />
| 0.0<br />
| 0.0<br />
| 1.0<br />
| Spawn Reinforcements Chance<br />
|}<br />
<br />
''Modifier Data'' structure:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
| UUID<br />
| UUID<br />
| <br />
|-<br />
| Amount<br />
| Double<br />
| May be positive or negative<br />
|-<br />
| Operation<br />
| Byte<br />
| See below<br />
|}<br />
<br />
The operation controls how the base value of the modifier is changed.<br />
<br />
* 0: Add/subtract amount<br />
* 1: Add/subtract amount percent of the current value<br />
* 2: Multiply by amount percent<br />
<br />
All of the 0's are applied first, and then the 1's, and then the 2's.<br />
<br />
==== Entity Effect ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="5"| 0x4E<br />
|rowspan="5"| Play<br />
|rowspan="5"| Client<br />
| Entity ID<br />
| VarInt<br />
| <br />
|-<br />
| Effect ID<br />
| Byte<br />
| See {{Minecraft Wiki|Status effect#List of effects|this table}}<br />
|-<br />
| Amplifier<br />
| Byte<br />
| Notchian client displays effect level as Amplifier + 1<br />
|-<br />
| Duration<br />
| VarInt<br />
| Seconds<br />
|-<br />
| Flags<br />
| Byte<br />
| Bit field, see below.<br />
|}<br />
<br />
Within flags:<br />
<br />
* 0x01: Is ambient - was the effect spawned from a beacon? All beacon-generated effects are ambient. Ambient effects use a different icon in the HUD (blue border rather than gray). If all effects on an entity are ambient, the [[Entities#Living|"Is potion effect ambient" living metadata field]] should be set to true. Usually should not be enabled.<br />
* 0x02: Show particles - should all particles from this effect be hidden? Effects with particles hidden are not included in the calculation of the effect color, and are not rendered on the HUD (but are still rendered within the inventory). Usually should be enabled.<br />
<br />
=== Serverbound ===<br />
<br />
==== Teleport Confirm ====<br />
<br />
Sent by client as confirmation of [[#Player Position And Look (clientbound)|Player Position And Look]] ([[#Play|Play]], 0x2E, clientbound).<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
| 0x00<br />
| Play<br />
| Server<br />
| Teleport ID<br />
| VarInt<br />
| The ID given by the [[#Player Position And Look (clientbound)|Player Position And Look]] packet<br />
|}<br />
<br />
==== Prepare Crafting Grid ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
!colspan="2"| Field Name<br />
!colspan="2"| Field Type<br />
! Notes<br />
|-<br />
|rowspan="12"| 0x01<br />
|rowspan="12"| Play<br />
|rowspan="12"| Server<br />
|colspan="2"| Window ID<br />
|colspan="2"| Byte<br />
| The window id.<br />
|-<br />
|colspan="2"| Action number<br />
|colspan="2"| Short<br />
| The transaction number. Will be send to the client in a Confirm Transaction packet.<br />
|-<br />
|colspan="2"| Array size<br />
|colspan="2"| Short<br />
| Number of elements in the following array<br />
|-<br />
|rowspan="3"| Return Entry<br />
| Item<br />
|rowspan="3"| Array<br />
| Slot<br />
| The item stack that will be put in the inventory slot<br />
|-<br />
| Crafting Slot<br />
| Byte<br />
| The crafting slot index in the active container<br />
|-<br />
| Player Slot<br />
| Byte<br />
| The player slot index in the player inventory<br />
|-<br />
|colspan="2"| Array Size<br />
|colspan="2"| Short<br />
| Number of elements in the following array<br />
|-<br />
|rowspan="3"| Prepare Entry<br />
| Item<br />
|rowspan="3"| Array<br />
| Slot<br />
| The item stack that will be put in the crafting slot<br />
|-<br />
| Crafting Slot<br />
| Byte<br />
| The crafting slot index in the active container<br />
|-<br />
| Player Slot<br />
| Byte<br />
| The player slot index in the player inventory<br />
|}<br />
<br />
This packet is send when a player clicks a recipe in the crafting book that is craftable (white border).<br />
<br />
1. Return Entries:<br />
* All the items on the crafting slot are set to null/empty.<br />
* Every entry item stack will be added to the player inventory, to the specific player slot.<br />
<br />
2. Prepare Entries:<br />
* All the items on the player inventory slots their quantity is decreased by 1.<br />
* Every entry item stack will be put in the proper crafting grid slot.<br />
<br />
The server will send a Confirm Transaction packet back to the client with the provided transaction id.<br />
<br />
<br />
==== Tab-Complete (serverbound) ====<br />
<br />
Sent when the user presses ''tab'' while writing text.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="4"| 0x02<br />
|rowspan="4"| Play<br />
|rowspan="4"| Server<br />
| Text<br />
| String (32767)<br />
| All text behind the cursor (e.g. to the left of the cursor in left-to-right languages like English)<br />
|-<br />
| Assume Command<br />
| Boolean<br />
| If true, the server will parse Text as a command even if it doesn't start with a <code>/</code>. Used in the command block GUI.<br />
|-<br />
| Has Position<br />
| Boolean<br />
| <br />
|-<br />
| Looked At Block<br />
| Optional Position<br />
| The position of the block being looked at. Only sent if Has Position is true.<br />
|}<br />
<br />
==== Chat Message (serverbound) ====<br />
<br />
Used to send a chat message to the server. The message may not be longer than 256 characters or else the server will kick the client.<br />
<br />
If the message starts with a <code>/</code>, the server will attempt to interpret it as a command. Otherwise, the server will broadcast the same chat message to all players on the server (including the player that sent the message), prepended with player's name. Specifically, it will respond with a translate [[chat]] component, "<code>chat.type.text</code>" with the first parameter set to the display name of the player (including some chat component logic to support clicking the name to send a PM) and the second parameter set to the message. See [[Chat#Processing chat|processing chat]] for more information.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x03<br />
|rowspan="1"| Play<br />
|rowspan="1"| Server<br />
| Message<br />
| String (256)<br />
| The client sends the raw input, not a [[Chat]] component<br />
|}<br />
<br />
==== Client Status ====<br />
<br />
Sent when the client is ready to complete login and when the client is ready to respawn after death.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x04<br />
|rowspan="1"| Play<br />
|rowspan="1"| Server<br />
| Action ID<br />
| VarInt Enum<br />
| See below<br />
|}<br />
<br />
''Action ID'' values:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Action ID<br />
! Action<br />
|-<br />
| 0<br />
| Perform respawn<br />
|-<br />
| 1<br />
| Request stats<br />
|}<br />
<br />
==== Client Settings ====<br />
<br />
Sent when the player connects, or when settings are changed.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="6"| 0x05<br />
|rowspan="6"| Play<br />
|rowspan="6"| Server<br />
| Locale<br />
| String (16)<br />
| e.g. en_GB<br />
|-<br />
| View Distance<br />
| Byte<br />
| Client-side render distance, in chunks<br />
|-<br />
| Chat Mode<br />
| VarInt Enum<br />
| 0: enabled, 1: commands only, 2: hidden. See [[Chat#Processing chat|processing chat]] for more information.<br />
|-<br />
| Chat Colors<br />
| Boolean<br />
| “Colors” multiplayer setting<br />
|-<br />
| Displayed Skin Parts<br />
| Unsigned Byte<br />
| Bit mask, see below<br />
|-<br />
| Main Hand<br />
| VarInt Enum<br />
| 0: Left, 1: Right<br />
|}<br />
<br />
''Displayed Skin Parts'' flags:<br />
<br />
* Bit 0 (0x01): Cape enabled<br />
* Bit 1 (0x02): Jacket enabled<br />
* Bit 2 (0x04): Left Sleeve enabled<br />
* Bit 3 (0x08): Right Sleeve enabled<br />
* Bit 4 (0x10): Left Pants Leg enabled<br />
* Bit 5 (0x20): Right Pants Leg enabled<br />
* Bit 6 (0x40): Hat enabled<br />
<br />
The most significant bit (bit 7, 0x80) appears to be unused.<br />
<br />
==== Confirm Transaction (serverbound) ====<br />
<br />
If a transaction sent by the client was not accepted, the server will reply with a [[#Confirm Transaction (clientbound)|Confirm Transaction (clientbound)]] packet with the Accepted field set to false. When this happens, the client must send this packet to apologize (as with movement), otherwise the server ignores any successive transactions.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x06<br />
|rowspan="3"| Play<br />
|rowspan="3"| Server<br />
| Window ID<br />
| Byte<br />
| The ID of the window that the action occurred in<br />
|-<br />
| Action Number<br />
| Short<br />
| Every action that is to be accepted has a unique number. This number is an incrementing integer (starting at 1) with separate counts for each window ID.<br />
|-<br />
| Accepted<br />
| Boolean<br />
| Whether the action was accepted<br />
|}<br />
<br />
==== Enchant Item ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x07<br />
|rowspan="2"| Play<br />
|rowspan="2"| Server<br />
| Window ID<br />
| Byte<br />
| The ID of the enchantment table window sent by [[#Open Window|Open Window]]<br />
|-<br />
| Enchantment<br />
| Byte<br />
| The position of the enchantment on the enchantment table window, starting with 0 as the topmost one<br />
|}<br />
<br />
==== Click Window ====<br />
<br />
This packet is sent by the player when it clicks on a slot in a window.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="6"| 0x08<br />
|rowspan="6"| Play<br />
|rowspan="6"| Server<br />
| Window ID<br />
| Unsigned Byte<br />
| The ID of the window which was clicked. 0 for player inventory.<br />
|-<br />
| Slot<br />
| Short<br />
| The clicked slot number, see below<br />
|-<br />
| Button<br />
| Byte<br />
| The button used in the click, see below<br />
|-<br />
| Action Number<br />
| Short<br />
| A unique number for the action, implemented by Notchian as a counter, starting at 1 (different counter for every window ID). Used by the server to send back a [[#Confirm Transaction (clientbound)|Confirm Transaction (clientbound)]].<br />
|-<br />
| Mode<br />
| VarInt Enum<br />
| Inventory operation mode, see below<br />
|-<br />
| Clicked item<br />
| [[Slot Data|Slot]]<br />
| The clicked slot. Has to be empty (item ID = -1) for drop mode.<br />
|}<br />
<br />
See [[Inventory]] for further information about how slots are indexed.<br />
<br />
When right-clicking on a stack of items, half the stack will be picked up and half left in the slot. If the stack is an odd number, the half left in the slot will be smaller of the amounts.<br />
<br />
The distinct type of click performed by the client is determined by the combination of the Mode and Button fields.<br />
<br />
{| class="wikitable"<br />
! Mode<br />
! Button<br />
! Slot<br />
! Trigger<br />
|-<br />
!rowspan="2"| 0<br />
| 0<br />
| Normal<br />
| Left mouse click<br />
|-<br />
| 1<br />
| Normal<br />
| Right mouse click<br />
|-<br />
!rowspan="2"| 1<br />
| 0<br />
| Normal<br />
| Shift + left mouse click<br />
|-<br />
| 1<br />
| Normal<br />
| Shift + right mouse click ''(identical behavior)''<br />
|-<br />
!rowspan="5"| 2<br />
| 0<br />
| Normal<br />
| Number key 1<br />
|-<br />
| 1<br />
| Normal<br />
| Number key 2<br />
|-<br />
| 2<br />
| Normal<br />
| Number key 3<br />
|-<br />
| ⋮<br />
| ⋮<br />
| ⋮<br />
|-<br />
| 8<br />
| Normal<br />
| Number key 9<br />
|-<br />
!rowspan="1"| 3<br />
| 2<br />
| Normal<br />
| Middle click, only defined for creative players in non-player inventories.<br />
|-<br />
!rowspan="4"| 4<br />
| 0<br />
| Normal*<br />
| Drop key (Q) (* Clicked item is different, see above)<br />
|-<br />
| 1<br />
| Normal*<br />
| Ctrl + Drop key (Ctrl-Q) ''(drops full stack)''<br />
|-<br />
| 0<br />
| -999<br />
| Left click outside inventory holding nothing ''(no-op)''<br />
|-<br />
| 1<br />
| -999<br />
| Right click outside inventory holding nothing ''(no-op)''<br />
|-<br />
!rowspan="9"| 5<br />
| 0<br />
| -999<br />
| Starting left mouse drag<br />
|-<br />
| 4<br />
| -999<br />
| Starting right mouse drag<br />
|-<br />
| 8<br />
| -999<br />
| Starting middle mouse drag, only defined for creative players in non-player inventories. (Note: the vanilla client will still incorrectly send this for non-creative players - see [https://bugs.mojang.com/browse/MC-46584 MC-46584])<br />
|-<br />
| 1<br />
| Normal<br />
| Add slot for left-mouse drag<br />
|-<br />
| 5<br />
| Normal<br />
| Add slot for right-mouse drag<br />
|-<br />
| 9<br />
| Normal<br />
| Add slot for middle-mouse drag, only defined for creative players in non-player inventories. (Note: the vanilla client will still incorrectly send this for non-creative players - see [https://bugs.mojang.com/browse/MC-46584 MC-46584])<br />
|-<br />
| 2<br />
| -999<br />
| Ending left mouse drag<br />
|-<br />
| 6<br />
| -999<br />
| Ending right mouse drag<br />
|-<br />
| 10<br />
| -999<br />
| Ending middle mouse drag, only defined for creative players in non-player inventories. (Note: the vanilla client will still incorrectly send this for non-creative players - see [https://bugs.mojang.com/browse/MC-46584 MC-46584])<br />
|-<br />
! 6<br />
| 0<br />
| Normal<br />
| Double click<br />
|}<br />
<br />
Starting from version 1.5, “painting mode” is available for use in inventory windows. It is done by picking up stack of something (more than 1 item), then holding mouse button (left, right or middle) and dragging held stack over empty (or same type in case of right button) slots. In that case client sends the following to server after mouse button release (omitting first pickup packet which is sent as usual):<br />
<br />
# packet with mode 5, slot -999, button (0 for left | 4 for right);<br />
# packet for every slot painted on, mode is still 5, button (1 | 5);<br />
# packet with mode 5, slot -999, button (2 | 6);<br />
<br />
If any of the painting packets other than the “progress” ones are sent out of order (for example, a start, some slots, then another start; or a left-click in the middle) the painting status will be reset.<br />
<br />
The server will send back a [[#Confirm Transaction (clientbound)|Confirm Transaction]] packet. If the click was not accepted, the client must send a matching [[#Confirm Transaction (serverbound)|serverbound confirm transaction]] packet before sending more [[#Click Window|Click Window]] packets, otherwise the server will reject them silently. The Notchian server also sends a [[#Window Items|Window Items]] packet for the open window and [[#Set Slot|Set Slot]] packets for the clicked and cursor slot, but only when the click was not accepted, probably to resynchronize client and server.<br />
<br />
==== Close Window (serverbound) ====<br />
<br />
This packet is sent by the client when closing a window.<br />
<br />
Notchian clients send a Close Window packet with Window ID 0 to close their inventory even though there is never an [[#Open Window|Open Window]] packet for the inventory.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
| 0x09<br />
| Play<br />
| Server<br />
| Window ID<br />
| Unsigned Byte<br />
| This is the ID of the window that was closed. 0 for player inventory.<br />
|}<br />
<br />
==== Plugin Message (serverbound) ====<br />
<br />
{{Main|Plugin channels}}<br />
<br />
Mods and plugins can use this to send their data. Minecraft itself uses a number of [[plugin channel]]s. These internal channels are prefixed with <code>MC|</code>.<br />
<br />
More documentation on this: [http://dinnerbone.com/blog/2012/01/13/minecraft-plugin-channels-messaging/ http://dinnerbone.com/blog/2012/01/13/minecraft-plugin-channels-messaging/]<br />
<br />
Note that the length of Data is known only from the packet length, since the packet has no length field of any kind.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x0A<br />
|rowspan="2"| Play<br />
|rowspan="2"| Server<br />
| Channel<br />
| String (20)<br />
| Name of the [[plugin channel]] used to send the data<br />
|-<br />
| Data<br />
| Byte Array<br />
| Any data, depending on the channel. <code><nowiki>MC|</nowiki></code> channels are documented [[plugin channel|here]]. The length of this array must be inferred from the packet length.<br />
|}<br />
<br />
==== Use Entity ====<br />
<br />
This packet is sent from the client to the server when the client attacks or right-clicks another entity (a player, minecart, etc).<br />
<br />
A Notchian server only accepts this packet if the entity being attacked/used is visible without obstruction and within a 4-unit radius of the player's position.<br />
<br />
Note that middle-click in creative mode is interpreted by the client and sent as a [[#Creative Inventory Action|Creative Inventory Action]] packet instead.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="6"| 0x0B<br />
|rowspan="6"| Play<br />
|rowspan="6"| Server<br />
| Target<br />
| VarInt<br />
| <br />
|-<br />
| Type<br />
| VarInt Enum<br />
| 0: interact, 1: attack, 2: interact at<br />
|-<br />
| Target X<br />
| Optional Float<br />
| Only if Type is interact at<br />
|-<br />
| Target Y<br />
| Optional Float<br />
| Only if Type is interact at<br />
|-<br />
| Target Z<br />
| Optional Float<br />
| Only if Type is interact at<br />
|-<br />
| Hand<br />
| Optional VarInt Enum<br />
| Only if Type is interact or interact at; 0: main hand, 1: off hand<br />
|}<br />
<br />
==== Keep Alive (serverbound) ====<br />
<br />
The server will frequently send out a keep-alive, each containing a random ID. The client must respond with the same packet.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
| 0x0C<br />
| Play<br />
| Server<br />
| Keep Alive ID<br />
| VarInt<br />
| <br />
|}<br />
<br />
==== Player ====<br />
<br />
This packet as well as [[#Player Position|Player Position]] ([[#Play|Play]], 0x04, serverbound), [[#Player Look|Player Look]] ([[#Play|Play]], 0x05, serverbound), and [[#Player Position And Look 2|Player Position And Look]] ([[#Play|Play]], 0x06, serverbound) are called the “serverbound movement packets”.<br />
<br />
This packet is used to indicate whether the player is on ground (walking/swimming), or airborne (jumping/falling).<br />
<br />
When dropping from sufficient height, fall damage is applied when this state goes from false to true. The amount of damage applied is based on the point where it last changed from true to false. Note that there are several movement related packets containing this state.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x0D<br />
|rowspan="1"| Play<br />
|rowspan="1"| Server<br />
| On Ground<br />
| Boolean<br />
| True if the client is on the ground, false otherwise<br />
|}<br />
<br />
==== Player Position ====<br />
<br />
Updates the player's XYZ position on the server.<br />
<br />
Checking for moving too fast is achieved like this:<br />
<br />
* Each server tick, the player's current position is stored<br />
* When a player moves, the changes in x, y, and z coordinates are compared with the positions from the previous tick (&Delta;x, &Delta;y, &Delta;z)<br />
* Total movement distance squared is computed as &Delta;x&sup2; + &Delta;y&sup2; + &Delta;z&sup2;<br />
* The expected movement distance squared is computed as velocityX&sup2; + veloctyY&sup2; + velocityZ&sup2;<br />
* If the total movement distance squared value minus the expected movement distance squared value is more than 100 (300 if the player is using an elytra), they are moving too fast.<br />
<br />
If the player is moving too fast, it will be logged that "<player> moved too quickly! " followed by the change in x, y, and z, and the player will be teleported back to their current (before this packet) serverside position.<br />
<br />
Also, if the absolute value of X or the absolute value of Z is a value greater than 3.2×10<sup>7</sup>, or X, Y, or Z are not finite (either positive infinity, negative infinity, or NaN), the client will be kicked for “Invalid move player packet received”.<br />
<br />
Vanilla clients will send one such packet every 20 ticks if idle.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="4"| 0x0E<br />
|rowspan="4"| Play<br />
|rowspan="4"| Server<br />
| X<br />
| Double<br />
| Absolute position<br />
|-<br />
| Feet Y<br />
| Double<br />
| Absolute feet position, normally Head Y - 1.62 <br />
|-<br />
| Z<br />
| Double<br />
| Absolute position<br />
|-<br />
| On Ground<br />
| Boolean<br />
| True if the client is on the ground, false otherwise<br />
|}<br />
<br />
==== Player Position And Look (serverbound) ====<br />
<br />
A combination of [[#Player Look|Player Look]] and [[#Player Position|Player Position]].<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="6"| 0x0F<br />
|rowspan="6"| Play<br />
|rowspan="6"| Server<br />
| X<br />
| Double<br />
| Absolute position<br />
|-<br />
| Feet Y<br />
| Double<br />
| Absolute feet position, normally Head Y - 1.62<br />
|-<br />
| Z<br />
| Double<br />
| Absolute position<br />
|-<br />
| Yaw<br />
| Float<br />
| Absolute rotation on the X Axis, in degrees<br />
|-<br />
| Pitch<br />
| Float<br />
| Absolute rotation on the Y Axis, in degrees<br />
|-<br />
| On Ground<br />
| Boolean<br />
| True if the client is on the ground, false otherwise<br />
|}<br />
<br />
==== Player Look ====<br />
[[File:Minecraft-trig-yaw.png|thumb|The unit circle for yaw]]<br />
[[File:Yaw.png|thumb|The unit circle of yaw, redrawn]]<br />
<br />
Updates the direction the player is looking in.<br />
<br />
Yaw is measured in degrees, and does not follow classical trigonometry rules. The unit circle of yaw on the XZ-plane starts at (0, 1) and turns counterclockwise, with 90 at (-1, 0), 180 at (0,-1) and 270 at (1, 0). Additionally, yaw is not clamped to between 0 and 360 degrees; any number is valid, including negative numbers and numbers greater than 360.<br />
<br />
Pitch is measured in degrees, where 0 is looking straight ahead, -90 is looking straight up, and 90 is looking straight down.<br />
<br />
The yaw and pitch of player (in degrees), standing at point (x0, y0, z0) and looking towards point (x, y, z) can be calculated with:<br />
<br />
dx = x-x0<br />
dy = y-y0<br />
dz = z-z0<br />
r = sqrt( dx*dx + dy*dy + dz*dz )<br />
yaw = -atan2(dx,dz)/PI*180<br />
if yaw < 0 then<br />
yaw = 360 - yaw<br />
pitch = -arcsin(dy/r)/PI*180<br />
<br />
You can get a unit vector from a given yaw/pitch via:<br />
<br />
x = -cos(pitch) * sin(yaw)<br />
y = -sin(pitch)<br />
z = cos(pitch) * cos(yaw)<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x10<br />
|rowspan="3"| Play<br />
|rowspan="3"| Server<br />
| Yaw<br />
| Float<br />
| Absolute rotation on the X Axis, in degrees<br />
|-<br />
| Pitch<br />
| Float<br />
| Absolute rotation on the Y Axis, in degrees<br />
|-<br />
| On Ground<br />
| Boolean<br />
| True if the client is on the ground, False otherwise<br />
|}<br />
<br />
==== Vehicle Move (serverbound) ====<br />
<br />
Sent when a player moves in a vehicle. Fields are the same as in [[#Player Position And Look (serverbound)|Player Position And Look]] ([[#Play|Play]], 0x2E, serverbound). Note that all fields use absolute positioning and do not allow for relative positioning.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="7"| 0x11<br />
|rowspan="7"| Play<br />
|rowspan="7"| Server<br />
| X<br />
| Double<br />
| Absolute position (X coordinate)<br />
|-<br />
| Y<br />
| Double<br />
| Absolute position (Y coordinate)<br />
|-<br />
| Z<br />
| Double<br />
| Absolute position (Z coordinate)<br />
|-<br />
| Yaw<br />
| Float<br />
| Absolute rotation on the vertical axis, in degrees<br />
|-<br />
| Pitch<br />
| Float<br />
| Absolute rotation on the horizontal axis, in degrees<br />
|}<br />
<br />
==== Steer Boat ====<br />
<br />
Used to ''visually'' update whether boat paddles are turning. The server will update the [[Entities#Boat|Boat entity metadata]] to match the values here.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x12<br />
|rowspan="2"| Play<br />
|rowspan="2"| Server<br />
| Right paddle turning<br />
| Boolean<br />
|<br />
|-<br />
| Left paddle turning<br />
| Boolean<br />
|<br />
|}<br />
<br />
Right paddle turning is set to true when the left button or forward button is held; left paddle turning is set to true when the right button or forward button is set to true.<br />
<br />
==== Player Abilities (serverbound) ====<br />
<br />
The latter 2 bytes are used to indicate the walking and flying speeds respectively, while the first byte is used to determine the value of 4 booleans.<br />
<br />
The vanilla client sends this packet when the player starts/stops flying with the Flags parameter changed accordingly. All other parameters are ignored by the vanilla server.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x13<br />
|rowspan="3"| Play<br />
|rowspan="3"| Server<br />
| Flags<br />
| Byte<br />
| Bit mask. 0x08: damage disabled (god mode), 0x04: can fly, 0x02: is flying, 0x01: is Creative<br />
|-<br />
| Flying Speed<br />
| Float<br />
| <br />
|-<br />
| Walking Speed<br />
| Float<br />
| <br />
|}<br />
<br />
==== Player Digging ====<br />
<br />
Sent when the player mines a block. A Notchian server only accepts digging packets with coordinates within a 6-unit radius between the center of the block and 1.5 units from the player's feet (''not'' their eyes).<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x14<br />
|rowspan="3"| Play<br />
|rowspan="3"| Server<br />
| Status<br />
| VarInt Enum<br />
| The action the player is taking against the block (see below)<br />
|-<br />
| Location<br />
| Position<br />
| Block position<br />
|-<br />
| Face<br />
| Byte Enum<br />
| The face being hit (see below)<br />
|}<br />
<br />
Status can be one of seven values:<br />
<br />
{| class="wikitable"<br />
! Value<br />
! Meaning<br />
! Notes<br />
|-<br />
| 0<br />
| Started digging<br />
| <br />
|-<br />
| 1<br />
| Cancelled digging<br />
| Sent when the player lets go of the Mine Block key (default: left click)<br />
|-<br />
| 2<br />
| Finished digging<br />
| Sent when the client thinks it is finished<br />
|-<br />
| 3<br />
| Drop item stack<br />
| Triggered by using the Drop Item key (default: Q) with the modifier to drop the entire selected stack (default: depends on OS). Location is always set to 0/0/0, Face is always set to -Y.<br />
|-<br />
| 4<br />
| Drop item<br />
| Triggered by using the Drop Item key (default: Q). Location is always set to 0/0/0, Face is always set to -Y.<br />
|-<br />
| 5<br />
| Shoot arrow / finish eating<br />
| Location is always set to 0/0/0, Face is always set to Special.<br />
|-<br />
| 6<br />
| Swap item in hand<br />
| Used to swap or assign an item to the second hand. Location is always set to 0/0/0, Face is always set to -Y.<br />
|}<br />
<br />
The Face field can be one of the following values, representing the face being hit (or the Special value used for “shoot arrow / finish eating”):<br />
<br />
{| class="wikitable"<br />
|-<br />
! Value<br />
! Offset<br />
! Face<br />
|-<br />
| 0<br />
| -Y<br />
| Bottom<br />
|-<br />
| 1<br />
| +Y<br />
| Top<br />
|-<br />
| 2<br />
| -Z<br />
| North<br />
|-<br />
| 3<br />
| +Z<br />
| South<br />
|-<br />
| 4<br />
| -X<br />
| West<br />
|-<br />
| 5<br />
| +X<br />
| East<br />
|-<br />
| 255<br />
| —<br />
| Special<br />
|}<br />
<br />
==== Entity Action ====<br />
<br />
Sent by the client to indicate that it has performed certain actions: sneaking (crouching), sprinting, exiting a bed, jumping with a horse, and opening a horse's inventory while riding it.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x15<br />
|rowspan="3"| Play<br />
|rowspan="3"| Server<br />
| Entity ID<br />
| VarInt<br />
| Player ID<br />
|-<br />
| Action ID<br />
| VarInt Enum<br />
| The ID of the action, see below<br />
|-<br />
| Jump Boost<br />
| VarInt<br />
| Only used by the “start jump with horse” action, in which case it ranges from 0 to 100. In all other cases it is 0.<br />
|}<br />
<br />
Action ID can be one of the following values:<br />
<br />
{| class="wikitable"<br />
! ID<br />
! Action<br />
|-<br />
| 0<br />
| Start sneaking<br />
|-<br />
| 1<br />
| Stop sneaking<br />
|-<br />
| 2<br />
| Leave bed<br />
|-<br />
| 3<br />
| Start sprinting<br />
|-<br />
| 4<br />
| Stop sprinting<br />
|-<br />
| 5<br />
| Start jump with horse<br />
|-<br />
| 6<br />
| Stop jump with horse<br />
|-<br />
| 7<br />
| Open horse inventory<br />
|-<br />
| 8<br />
| Start flying with elytra<br />
|}<br />
<br />
Leave bed is only sent when the “Leave Bed” button is clicked on the sleep GUI, not when waking up due today time.<br />
<br />
Open horse inventory is only sent when pressing the inventory key (default: E) while on a horse — all other methods of opening a horse's inventory (involving right-clicking or shift-right-clicking it) do not use this packet.<br />
<br />
“Open inventory” is now sent via the [[#Client Status|Client Status]] ([[#Play|Play]], 0x03, serverbound) packet.<br />
<br />
==== Steer Vehicle ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="3"| 0x16<br />
|rowspan="3"| Play<br />
|rowspan="3"| Server<br />
| Sideways<br />
| Float<br />
| Positive to the left of the player<br />
|-<br />
| Forward<br />
| Float<br />
| Positive forward<br />
|-<br />
| Flags<br />
| Unsigned Byte<br />
| Bit mask. 0x1: jump, 0x2: unmount<br />
|}<br />
<br />
Also known as 'Input' packet.<br />
<br />
==== Crafting Book Data ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
!colspan="2"| Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="5"| 0x17<br />
|rowspan="5"| Play<br />
|rowspan="5"| Server<br />
|colspan="2"| Type<br />
| VarInt<br />
| Determines the format of the rest of the packet<br />
|-<br />
! Type<br />
! Field Name<br />
! <br />
! <br />
|-<br />
| 0: Displayed Recipe<br />
| Recipe ID<br />
| Int<br />
| The internal id of the displayed recipe.<br />
|-<br />
|rowspan="2"| 1: Crafting Book Status<br />
| Crafting Book Open<br />
| Boolean<br />
| Whether the player has the crafting book currently openened/active.<br />
|-<br />
| Crafting Filter<br />
| Boolean<br />
| Whether the player has the crafting filter option currently active.<br />
|}<br />
<br />
The Crafting Book Status type is send when the player closes its inventory.<br />
<br />
==== Resource Pack Status ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x18<br />
|rowspan="2"| Play<br />
|rowspan="2"| Server<br />
| Result<br />
| VarInt Enum<br />
| 0: successfully loaded, 1: declined, 2: failed download, 3: accepted<br />
|}<br />
<br />
==== Advancement Tab ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x19<br />
|rowspan="2"| Play<br />
|rowspan="2"| Server<br />
| Action<br />
| VarInt enum<br />
| 0: Opened tab, 1: Closed screen<br />
|-<br />
| Tab ID<br />
| Optional identifier<br />
| Only present if action is Opened tab<br />
|}<br />
<br />
==== Held Item Change (serverbound) ====<br />
<br />
Sent when the player changes the slot selection<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x1A<br />
|rowspan="1"| Play<br />
|rowspan="1"| Server<br />
| Slot<br />
| Short<br />
| The slot which the player has selected (0–8)<br />
|}<br />
<br />
==== Creative Inventory Action ====<br />
<br />
While the user is in the standard inventory (i.e., not a crafting bench) in Creative mode, the player will send this packet.<br />
<br />
Clicking in the creative inventory menu is quite different from non-creative inventory management. Picking up an item with the mouse actually deletes the item from the server, and placing an item into a slot or dropping it out of the inventory actually tells the server to create the item from scratch. (This can be verified by clicking an item that you don't mind deleting, then severing the connection to the server; the item will be nowhere to be found when you log back in.) As a result of this implementation strategy, the "Destroy Item" slot is just a client-side implementation detail that means "I don't intend to recreate this item.". Additionally, the long listings of items (by category, etc.) are a client-side interface for choosing which item to create. Picking up an item from such listings sends no packets to the server; only when you put it somewhere does it tell the server to create the item in that location.<br />
<br />
This action can be described as "set inventory slot". Picking up an item sets the slot to item ID -1. Placing an item into an inventory slot sets the slot to the specified item. Dropping an item (by clicking outside the window) effectively sets slot -1 to the specified item, which causes the server to spawn the item entity, etc.. All other inventory slots are numbered the same as the non-creative inventory (including slots for the 2x2 crafting menu, even though they aren't visible in the vanilla client).<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x1B<br />
|rowspan="2"| Play<br />
|rowspan="2"| Server<br />
| Slot<br />
| Short<br />
| Inventory slot<br />
|-<br />
| Clicked Item<br />
| [[Slot Data|Slot]]<br />
| <br />
|}<br />
<br />
==== Update Sign ====<br />
<br />
{{anchor|Update Sign (serverbound)}}This message is sent from the client to the server when the “Done” button is pushed after placing a sign.<br />
<br />
The server only accepts this packet after [[#Open Sign Editor|Open Sign Editor]] ([[#Play|Play]], 0x2A, clientbound), otherwise this packet is silently ignored.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="5"| 0x1C<br />
|rowspan="5"| Play<br />
|rowspan="5"| Server<br />
| Location<br />
| Position<br />
| Block Coordinates<br />
|-<br />
| Line 1<br />
| String (384)<br />
| First line of text in the sign<br />
|-<br />
| Line 2<br />
| String (384)<br />
| Second line of text in the sign<br />
|-<br />
| Line 3<br />
| String (384)<br />
| Third line of text in the sign<br />
|-<br />
| Line 4<br />
| String (384)<br />
| Fourth line of text in the sign<br />
|}<br />
<br />
==== Animation (serverbound) ====<br />
<br />
Sent when the player's arm swings.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
| 0x1D<br />
| Play<br />
| Server<br />
| Hand<br />
| VarInt Enum<br />
| Hand used for the animation. 0: main hand, 1: off hand.<br />
|}<br />
<br />
==== Spectate ====<br />
<br />
Teleports the player to the given entity. The player must be in spectator mode.<br />
<br />
The Notchian client only uses this to teleport to players, but it appears to accept any type of entity. The entity does not need to be in the same dimension as the player; if necessary, the player will be respawned in the right world. If the given entity cannot be found (or isn't loaded), this packet will be ignored. It will also be ignored if the player attempts to teleport to themselves.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x1E<br />
|rowspan="1"| Play<br />
|rowspan="1"| Server<br />
| Target Player<br />
| UUID<br />
| UUID of the player to teleport to (can also be an entity UUID)<br />
|}<br />
<br />
==== Player Block Placement ====<br />
<br />
{| class="wikitable"<br />
|-<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="6"| 0x1F<br />
|rowspan="6"| Play<br />
|rowspan="6"| Server<br />
| Location<br />
| Position<br />
| Block position<br />
|-<br />
| Face<br />
| VarInt Enum<br />
| The face on which the block is placed (as documented at [[#Player Digging|Player Digging]])<br />
|-<br />
| Hand<br />
| VarInt Enum<br />
| The hand from which the block is placed; 0: main hand, 1: off hand<br />
|-<br />
| Cursor Position X<br />
| Float<br />
| The position of the crosshair on the block, from 0 to 1 increasing from west to east<br />
|-<br />
| Cursor Position Y<br />
| Float<br />
| The position of the crosshair on the block, from 0 to 1 increasing from bottom to top<br />
|-<br />
| Cursor Position Z<br />
| Float<br />
| The position of the crosshair on the block, from 0 to 1 increasing from north to south<br />
|}<br />
<br />
In normal operation (i.e. placing a block), this packet is sent once, with the values set normally.<br />
<br />
The Cursor Position X/Y/Z fields (also known as in-block coordinates) are calculated using raytracing. The unit corresponds to sixteen pixel in the default resource pack. For example, let's say a slab is being placed against the south face of a full block. The Cursor Position X will be higher if the player was pointing near the right (east) edge of the face, lower if pointing near the left. The Cursor Position Y will be used to determine whether it will appear as a bottom slab (values 0.0–0.5) or as a top slab (values 0.5-1.0). The Cursor Position Z should be 1.0 since the player was looking at the southernmost part of the block.<br />
<br />
This packet has a special case where X, Y, Z, and Face are all -1. (Note that Y is unsigned so set to 255.) This special packet indicates that the currently held item for the player should have its state updated such as eating food, pulling back bows, using buckets, etc.<br />
<br />
Special note on using buckets: When using buckets, the Notchian client might send two packets: first a normal and then a special case. The first normal packet is sent when you're looking at a block (e.g. the water you want to scoop up). This normal packet does not appear to do anything with a Notchian server. The second, special case packet appears to perform the action — based on current position/orientation and with a distance check — it appears that buckets can only be used within a radius of 6 units.<br />
<br />
==== Use Item ====<br />
<br />
Sent when pressing the Use Item key (default: right click) with an item in hand.<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
| 0x20<br />
| Play<br />
| Server<br />
| Hand<br />
| VarInt Enum<br />
| Hand used for the animation. 0: main hand, 1: off hand.<br />
|}<br />
<br />
== Status ==<br />
{{Main|Server List Ping}}<br />
<br />
=== Clientbound ===<br />
<br />
==== Response ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x00<br />
|rowspan="1"| Status<br />
|rowspan="1"| Client<br />
| JSON Response<br />
| String (32767)<br />
| See [[Server List Ping#Response]]<br />
|}<br />
<br />
==== Pong ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x01<br />
|rowspan="1"| Status<br />
|rowspan="1"| Client<br />
| Payload<br />
| Long<br />
| Should be the same as sent by the client<br />
|}<br />
<br />
=== Serverbound ===<br />
<br />
==== Request ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x00<br />
| Status<br />
| Server<br />
|colspan="3"| ''no fields''<br />
|}<br />
<br />
==== Ping ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x01<br />
|rowspan="1"| Status<br />
|rowspan="1"| Server<br />
| Payload<br />
| Long<br />
| May be any number. Notchian clients use a system-dependent time value which is counted in milliseconds.<br />
|}<br />
<br />
== Login ==<br />
<br />
The login process is as follows:<br />
<br />
# C→S: [[#Handshake|Handshake]] with Next State set to 2 (login)<br />
# C→S: [[#Login Start|Login Start]]<br />
# S→C: [[#Encryption Request|Encryption Request]]<br />
# Client auth<br />
# C→S: [[#Encryption Response|Encryption Response]]<br />
# Server auth, both enable encryption<br />
# S→C: [[#Set Compression|Set Compression]] (optional)<br />
# S→C: [[#Login Success|Login Success]]<br />
<br />
Set Compression, if present, must be sent before Login Success. Note that anything sent after Set Compression must use the [[#With_compression|Post Compression packet format]].<br />
<br />
For unauthenticated and localhost connections (either of the two conditions is enough for an unencrypted connection) there is no encryption. In that case [[#Login Start|Login Start]] is directly followed by [[#Login Success|Login Success]].<br />
<br />
See [[Protocol Encryption]] for details.<br />
<br />
=== Clientbound ===<br />
<br />
==== Disconnect (login) ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x00<br />
|rowspan="1"| Login<br />
|rowspan="1"| Client<br />
| Reason<br />
| [[Chat]]<br />
| <br />
|}<br />
<br />
==== Encryption Request ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="5"| 0x01<br />
|rowspan="5"| Login<br />
|rowspan="5"| Client<br />
| Server ID<br />
| String (20)<br />
| Appears to be empty<br />
|-<br />
| Public Key Length<br />
| VarInt<br />
| Length of Public Key<br />
|-<br />
| Public Key<br />
| Byte Array<br />
| <br />
|-<br />
| Verify Token Length<br />
| VarInt<br />
| Length of Verify Token. Always 4 for Notchian servers.<br />
|-<br />
| Verify Token<br />
| Byte Array<br />
| A sequence of random bytes generated by the server<br />
|}<br />
<br />
See [[Protocol Encryption]] for details.<br />
<br />
==== Login Success ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="2"| 0x02<br />
|rowspan="2"| Login<br />
|rowspan="2"| Client<br />
| UUID<br />
| String (36)<br />
| Unlike in other packets, this field contains the UUID as a string with hyphens.<br />
|-<br />
| Username<br />
| String (16)<br />
| <br />
|}<br />
<br />
This packet switches the connection state to [[#Play|play]].<br />
<br />
==== Set Compression ====<br />
<br />
Enables compression. If compression is enabled, all following packets are encoded in the [[#With compression|compressed packet format]]. Negative values will disable compression, meaning the packet format should remain in the [[#Without compression|uncompressed packet format]]. However, this packet is entirely optional, and if not sent, compression will also not be enabled (the notchian server does not send the packet when compression is disabled).<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x03<br />
|rowspan="1"| Login<br />
|rowspan="1"| Client<br />
| Threshold<br />
| VarInt<br />
| Maximum size of a packet before it is compressed<br />
|}<br />
<br />
=== Serverbound ===<br />
<br />
==== Login Start ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="1"| 0x00<br />
|rowspan="1"| Login<br />
|rowspan="1"| Server<br />
| Name<br />
| String (16)<br />
| Player's Username<br />
|}<br />
<br />
==== Encryption Response ====<br />
<br />
{| class="wikitable"<br />
! Packet ID<br />
! State<br />
! Bound To<br />
! Field Name<br />
! Field Type<br />
! Notes<br />
|-<br />
|rowspan="4"| 0x01<br />
|rowspan="4"| Login<br />
|rowspan="4"| Server<br />
| Shared Secret Length<br />
| VarInt<br />
| Length of Shared Secret<br />
|-<br />
| Shared Secret<br />
| Byte Array<br />
| <br />
|-<br />
| Verify Token Length<br />
| VarInt<br />
| Length of Verify Token<br />
|-<br />
| Verify Token<br />
| Byte Array<br />
| <br />
|}<br />
<br />
See [[Protocol Encryption]] for details.<br />
<br />
[[Category:Protocol Details]]<br />
[[Category:Minecraft Modern]]</div>Janmm14https://wiki.vg/index.php?title=Talk:Mojang_API&diff=7958Talk:Mojang API2016-06-07T13:14:34Z<p>Janmm14: /* How to get the bearer access token? */ new section</p>
<hr />
<div>== Skin Change API call ==<br />
<br />
I've added the API call for skin changes but it'll need some editing to fit in with the other calls on the page.<br />
--[[User:Tron|Tron]] ([[User talk:Tron|talk]]) 17:39, 21 March 2016 (UTC)<br />
:How exactly should the payload look like? Whatever I send (even garbage data) I get back a 403 HTTP response with <syntaxhighlight lang="json">{"error":"Forbidden","errorMessage":"Current IP not secured"}</syntaxhighlight> --[[User:Grego87|Grego87]] ([[User talk:Grego87|talk]]) 00:00, 3 May 2016 (UTC)<br />
::I've tried editing the article to address these two issues. To do so I looked at [https://minecraft.net/static/CACHE/js/de279fdd7b68.js Mojang's implementation] ([https://web.archive.org/web/20160518164414/https://minecraft.net/static/CACHE/js/de279fdd7b68.js 05/18/2016 archive], depack [http://jsbeautifier.org/ here]) and various error messages their servers returned my cURL attempts. I've been trying to find an API for 'deleting/resetting' skins, but I cannot understand this mechanism (it would help if I knew javascript). For a good starting point search up "onResetSkinClick". --[[User:Max Shen|Max Shen]] ([[User talk:Max Shen|talk]]) 07:43, 20 May 2016 (UTC)<br />
<br />
== How to get the bearer access token? ==<br />
<br />
I was wondering how to get the access token programmatically, as I want to continue my plugin CustomSkins. Creating a howto which involves using chrome network tools (for example) is the last option I'd like to go. [[User:Janmm14|Janmm14]] ([[User talk:Janmm14|talk]])</div>Janmm14