Skip to content

Instantly share code, notes, and snippets.

@schwarzeszeux
Last active December 29, 2015 04:09
Show Gist options
  • Save schwarzeszeux/7613395 to your computer and use it in GitHub Desktop.
Save schwarzeszeux/7613395 to your computer and use it in GitHub Desktop.
<?xml version="1.0" encoding="utf-8" ?>
<Packets version="73">
<Packet name="KeepAlive" id="0x00">
<Field name="KeepaliveID" type="int" note="Server-generated random id" />
<Comments>
<![CDATA[
Two-Way
The server will frequently send out a keep-alive, each containing a random ID. The client must respond with the same packet. The Beta server will disconnect a client if it doesn't receive at least one packet before 1200 in-game ticks, and the Beta client will time out the connection under the same conditions. The client may send packets with Keep-alive ID=0.
]]>
</Comments>
</Packet>
<Packet name="LoginRequest" id="0x01">
<Field name="EntityID" type="int" note="The Player's Entity ID" />
<Field name="Leveltype" type="string" note="default, flat, or largeBiomes. level-type in server.properties" />
<Field name="Gamemode" type="byte" note="0: survival, 1: creative, 2: adventure. Bit 3 (0x8) is the hardcore flag" />
<Field name="Dimension" type="byte" note="-1: nether, 0: overworld, 1: end" />
<Field name="Difficulty" type="byte" note="0 thru 3 for Peaceful, Easy, Normal, Hard" />
<Field name="Notused" type="byte" note="Only 0 observed from vanilla server, was previously world height" />
<Field name="Maxplayers" type="byte" note="Used by the client to draw the player list" />
<Comments>
<![CDATA[
Server to Client (and Client to Server in some mods, see below)
See Protocol Encryption for information on logging in.
MinecraftForge sends packet with type 0x01 and 25 bytes(may depend on mods installed with it) following it after completing handshake and enabling encryption. In our tests it sent the following payload:
0x53 0xC8 0xE6 0x1B 0x00 0x07 0x00 0x64 0x00 0x65 0x00 0x66 0x00 0x61 0x00 0x75 0x00 0x6C 0x00 0x74 0xFF 0x02 0x00 0x00 0x00
It is probably safe for server to ignore them unless you know what to do. More insights are needed on MinecraftForge protocol specifics.
]]>
</Comments>
</Packet>
<Packet name="Handshake" id="0x02">
<Field name="ProtocolVersion" type="byte" note="As of 1.5.2 the protocol version is 61. See Protocol version numbers for list." />
<Field name="Username" type="string" note="The username of the player attempting to connect" />
<Field name="ServerHost" type="string" note="" />
<Field name="ServerPort" type="int" note="" />
<Comments>
<![CDATA[
Client to server
See Protocol Encryption for information on logging in.
]]>
</Comments>
</Packet>
<Packet name="ChatMessage" id="0x03">
<Field name="Message" type="string" note="The message being sent."></Field>
<Comments>
<![CDATA[
Client to Server
The default server will check the message to see if it begins with a '/'. If it doesn't, the username of the sender is prepended and sent to all other clients (including the original sender). If it does, the server assumes it to be a command and attempts to process it. A message longer than 100 characters will cause the server to kick the client. (As of 1.3.2, the vanilla client appears to limit the text a user can enter to 100 charaters.) This limits the chat message packet length to 203 bytes (as characters are encoded on 2 bytes). Note that this limit does not apply to chat messages sent by the server, which are limited to 32767 characters since 1.2.5. This change was initially done by allowing the client to not slice the message up to 119 (the previous limit), without changes to the server. For this reason, the vanilla server kept the code to cut messages at 119, but this isn't a protocol limitation and can be ignored.
For more information, see Chat.
Server to Client
The chat string must now be a valid JSON object:
Original Gist from Dinnerbone
Where translate is one of the following:
]]>
</Comments>
</Packet>
<Packet name="TimeUpdate" id="0x04">
<Field name="Ageoftheworld" type="long" note="In ticks; not changed by server commands" />
<Field name="TimeofDay" type="long" note="The world (or region) time, in ticks. If negative the sun will stop moving at the Math.abs of the time." />
<Comments>
<![CDATA[
Server to Client
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.
The time of day is based on the timestamp modulo 24000. 0 is sunrise, 6000 is noon, 12000 is sunset, and 18000 is midnight.
The default SMP server increments the time by 20 every second.
]]>
</Comments>
</Packet>
<Packet name="EntityEquipment" id="0x05">
<Field name="EntityID" type="int" note="Named Entity ID" />
<Field name="Slot" type="short" note="Equipment slot: 0=held, 1-4=armor slot (1 - boots, 2 - leggings, 3 - chestplate, 4 - helmet)" />
<Field name="Item" type="slot" note="Item in slot format" />
<Comments>
<![CDATA[
Server to Client
]]>
</Comments>
</Packet>
<Packet name="SpawnPosition" id="0x06">
<Field name="X" type="int" note="Spawn X in block coordinates" />
<Field name="Y" type="int" note="Spawn Y in block coordinates" />
<Field name="Z" type="int" note="Spawn Z in block coordinates" />
<Comments>
<![CDATA[
Server to Client
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.
]]>
</Comments>
</Packet>
<Packet name="UseEntity" id="0x07">
<Field name="User" type="int" note="The entity of the player (ignored by the server)" />
<Field name="Target" type="int" note="The entity the player is interacting with" />
<Field name="Mousebutton" type="boolean" note="true when the player is left-clicking and false when right-clicking." />
<Comments>
<![CDATA[
Client to Server
This packet is sent from the client to the server when the client attacks or right-clicks another entity (a player, minecart, etc).
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.
]]>
</Comments>
</Packet>
<Packet name="UpdateHealth" id="0x08">
<Field name="Health" type="float" note="0 or less = dead, 20 = full HP" />
<Field name="Food" type="short" note="0 - 20" />
<Field name="FoodSaturation" type="float" note="Seems to vary from 0.0 to 5.0 in integer increments" />
<Comments>
<![CDATA[
Server to Client
Sent by the server to update/set the health of the player it is sent to. Added in protocol version 5.
Food 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.
]]>
</Comments>
</Packet>
<Packet name="Respawn" id="0x09">
<Field name="Dimension" type="int" note="-1: The Nether, 0: The Overworld, 1: The End" />
<Field name="Difficulty" type="byte" note="0 thru 3 for Peaceful, Easy, Normal, Hard. 1 is always sent c->s" />
<Field name="Gamemode" type="byte" note="0: survival, 1: creative, 2: adventure. The hardcore flag is not included" />
<Field name="Worldheight" type="short" note="Defaults to 256" />
<Field name="Leveltype" type="string" note="See 0x01 login" />
<Comments>
<![CDATA[
Server to Client
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.
Please avoid changing player's dimension to same dimension as he was in (i.e. from Nether to Nether, from Overworld to Overworld). While at first glance everything seems to work, weird bugs can occur, i.e. such player will be unable to attack other players in new world (minecraft client just won't send "Use Entity (0x07)" packet on hitting, only "Animation (0x12)" packet), even though he can see them and they can attack him (fixes after his death and respawn though).
If you actually have multiple worlds of same dimension on server and need to teleport player between them, use intermediate world (with different dimension) between them.
]]>
</Comments>
</Packet>
<Packet name="Player" id="0x0A">
<Field name="OnGround" type="boolean" note="True if the client is on the ground, False otherwise" />
<Comments>
<![CDATA[
Client to Server
This packet is used to indicate whether the player is on ground (walking/swimming), or airborne (jumping/falling).
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.
This packet was previously referred to as Flying
]]>
</Comments>
</Packet>
<Packet name="PlayerPosition" id="0x0B">
<Field name="X" type="double" note="Absolute position" />
<Field name="Y" type="double" note="Absolute position" />
<Field name="Stance" type="double" note="Used to modify the players bounding box when going up stairs, crouching, etc…" />
<Field name="Z" type="double" note="Absolute position" />
<Field name="OnGround" type="boolean" note="Derived from packet 0x0A" />
<Comments>
<![CDATA[
Client to Server
Updates the players XYZ position on the server. If Stance - Y is less than 0.1 or greater than 1.65, the stance is illegal and the client will be kicked with the message “Illegal Stance”. 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 units will result in the client being kicked for "You moved too quickly :( (Hacking?)" Also if the absolute number of X or Z is set greater than 3.2E7D the client will be kicked for "Illegal position"
]]>
</Comments>
</Packet>
<Packet name="PlayerLook" id="0x0C">
<Field name="Yaw" type="float" note="Absolute rotation on the X Axis, in degrees" />
<Field name="Pitch" type="float" note="Absolute rotation on the Y Axis, in degrees" />
<Field name="OnGround" type="boolean" note="Derived from packet 0x0A" />
<Comments>
<![CDATA[
Client to Server
Updates the direction the player is looking in.
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 backwards towards (-1, 0), or in other words, it turns clockwise instead of counterclockwise. Additionally, yaw is not clamped to between 0 and 360 degrees; any number is valid, including negative numbers and numbers greater than 360.
Pitch is measured in degrees, where 0 is looking straight ahead, -90 is looking straight up, and 90 is looking straight down.
You can get a unit vector from a given yaw/pitch via:
]]>
</Comments>
</Packet>
<Packet name="PlayerPositionandLook" id="0x0D">
<Field name="X" type="double" note="Absolute position" />
<Field name="Y" type="double" note="Absolute position" />
<Field name="Stance" type="double" note="Used to modify the players bounding box when going up stairs, crouching, etc…" />
<Field name="Z" type="double" note="Absolute position" />
<Field name="Yaw" type="float" note="Absolute rotation on the X Axis" />
<Field name="Pitch" type="float" note="Absolute rotation on the Y Axis" />
<Field name="OnGround" type="boolean" note="Derived from packet 0x0A" />
<Comments>
<![CDATA[
Two-Way
A combination of Player Look and Player position.
]]>
</Comments>
</Packet>
<Packet name="PlayerDigging" id="0x0E">
<Field name="Status" type="byte" note="The action the player is taking against the block (see below)" />
<Field name="X" type="int" note="Block position" />
<Field name="Y" type="byte" note="Block position" />
<Field name="Z" type="int" note="Block position" />
<Field name="Face" type="byte" note="The face being hit (see below)" />
<Comments>
<![CDATA[
Client to Server
Sent when the player mines a block. A Notchian server only accepts digging packets with coordinates within a 6-unit radius of the player's position.
Status can (currently) be one of six values:
Notchian clients send a 0 (started digging) when they start digging and a 2 (finished digging) once they think they are finished. If digging is aborted, the client simply send a 1 (Cancel digging).
Status code 4 (drop item) is a special case. In-game, when you use the Drop Item command (keypress 'q'), a dig packet with a status of 4, and all other values set to 0, is sent from client to server. Status code 3 is similar, but drops the entire stack.
Status code 5 (shoot arrow / finish eating) is also a special case. The x, y and z fields are all set to 0 like above, with the exception of the face field, which is set to 255.
The face can be one of six values, representing the face being hit:
In 1.7.3, when a player opens a door with left click the server receives Packet 0xE+start digging and opens the door.
]]>
</Comments>
</Packet>
<Packet name="PlayerBlockPlacement" id="0x0F">
<Field name="X" type="int" note="Block position" />
<Field name="Y" type="ubyte" note="Block position" />
<Field name="Z" type="int" note="Block position" />
<Field name="Direction" type="byte" note="The offset to use for block/item placement (see below)" />
<Field name="Helditem" type="slot" note="" />
<Field name="CursorpositionX" type="byte" note="The position of the crosshair on the block" />
<Field name="CursorpositionY" type="byte" note="" />
<Field name="CursorpositionZ" type="byte" note="" />
<Comments>
<![CDATA[
Client to Server
In normal operation (ie placing a block), this packet is sent once, with the values set normally.
This packet has a special case where X, Y, Z, and Direction 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, shooting bows, using buckets, etc.
In a Notchian Beta client, the block or item ID corresponds to whatever the client is currently holding, and the client sends one of these packets any time a right-click is issued on a surface, so no assumptions can be made about the safety of the ID. However, with the implementation of server-side inventory, a Notchian server seems to ignore the item ID, instead operating on server-side inventory information and holding selection. The client has been observed (1.2.5 and 1.3.2) to send both real item IDs and -1 in a single session.
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.
]]>
</Comments>
</Packet>
<Packet name="HeldItemChange" id="0x10">
<Field name="SlotID" type="short" note="The slot which the player has selected (0-8)" />
<Comments>
<![CDATA[
Two-Way
Sent when the player changes the slot selection
]]>
</Comments>
</Packet>
<Packet name="UseBed" id="0x11">
<Field name="EntityID" type="int" note="Player ID" />
<Field name="Unknown" type="byte" note="Only 0 has been observed" />
<Field name="Xcoordinate" type="int" note="Bed headboard X as block coordinate" />
<Field name="Ycoordinate" type="byte" note="Bed headboard Y as block coordinate" />
<Field name="Zcoordinate" type="int" note="Bed headboard Z as block coordinate" />
<Comments>
<![CDATA[
Server to Client
This packet tells that a player goes to bed.
The client with the matching Entity ID will go into bed mode.
This Packet is sent to all nearby players including the one sent to bed.
]]>
</Comments>
</Packet>
<Packet name="Animation" id="0x12">
<Field name="EID" type="int" note="Player ID" />
<Field name="Animation" type="byte" note="Animation ID" />
<Comments>
<![CDATA[
Two-Way
Sent whenever an entity should change animation.
Animation can be one of the following values:
Only 1 (swing arm) is sent by notchian clients. Crouching is sent via 0x13. Damage is server-side, and so is not sent by notchian clients. See also Entity Status. As of client 1.5.2, crouching / uncrouching is sent through Entity Metadata.
]]>
</Comments>
</Packet>
<Packet name="EntityAction" id="0x13">
<Field name="EID" type="int" note="Player ID" />
<Field name="ActionID" type="byte" note="The ID of the action, see below." />
<Field name="Unknown" type="int" note="Something to do with horses. Ranged from 0 -> 90" />
<Comments>
<![CDATA[
Client to Server
Sent at least when crouching, leaving a bed, or sprinting. To send action animation to client use 0x28. The client will send this with Action ID = 3 when "Leave Bed" is clicked.
Action ID can be one of the following values:
]]>
</Comments>
</Packet>
<Packet name="SpawnNamedEntity" id="0x14">
<Field name="EID" type="int" note="Player ID" />
<Field name="PlayerName" type="string" note="Max length of 16" />
<Field name="X" type="int" note="Player X as Absolute Integer" />
<Field name="Y" type="int" note="Player Y as Absolute Integer" />
<Field name="Z" type="int" note="Player Z as Absolute Integer" />
<Field name="Yaw" type="byte" note="Player rotation as a packed byte" />
<Field name="Pitch" type="byte" note="Player rotation as a packed byte" />
<Field name="CurrentItem" type="short" note="The item the player is currently holding. Note that this should be 0 for &quot;no item&quot;, unlike -1 used in other packets. A negative value crashes clients." />
<Field name="Metadata" type="Metadata" note="The 1.3 client crashes on packets with no metadata, but the server can send any metadata key of 0, 1 or 8 and the client is fine." />
<Comments>
<![CDATA[
Server to Client
The only named entities (at the moment) are players (either real or NPC/Bot). This packet is sent by the server when a player comes into visible range, not when a player joins.
Servers can, however, safely spawn player entities for players not in visible range. The client appears to handle it correctly.
At one point, the Notchian client was not okay with receiving player entity packets, including 0x14, that refer to its own username or EID; and would teleport to the absolute origin of the map and fall through the Void any time it received them. However, in more recent versions, it appears to handle them correctly, by spawning a new entity as directed (though future packets referring to the entity ID may be handled incorrectly).
]]>
</Comments>
</Packet>
<Packet name="CollectItem" id="0x16">
<Field name="CollectedEID" type="int" note="" />
<Field name="CollectorEID" type="int" note="" />
<Comments>
<![CDATA[
Server to Client
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 (0x1D does that), and it doesn't add it to your inventory (0x67 does that). The server only checks for items to be picked up after each Player Position and Player Position & Look packet sent by the client.
]]>
</Comments>
</Packet>
<Packet name="SpawnObjectVehicle" id="0x17">
<Field name="EID" type="int" note="Entity ID of the Object" />
<Field name="Type" type="byte" note="The type of object (see Entities#Objects)" />
<Field name="X" type="int" note="The Absolute Integer X Position of the object" />
<Field name="Y" type="int" note="The Absolute Integer Y Position of the object" />
<Field name="Z" type="int" note="The Absolute Integer Z Position of the object" />
<Field name="Pitch" type="byte" note="The pitch in steps of 2p/256" />
<Field name="Yaw" type="byte" note="The yaw in steps of 2p/256" />
<Field name="ThrowerEntityId" type="int" note="0 if not a fireball. Otherwise, this is the Entity ID of the thrower" />
<Field name="SpeedX" type="int" note="Not sent if the thrower entity ID is 0. The speed of this fireball along the X axis. Value is multiplied by 8000" write="false" read="false" />
<Field name="SpeedY" type="int" note="Not sent if the thrower entity ID is 0. The speed of this fireball along the Y axis. Value is multiplied by 8000" write="false" read="false" />
<Field name="SpeedZ" type="int" note="Not sent if the thrower entity ID is 0. The speed of this fireball along the Z axis. Value is multiplied by 8000">
<Read>
<![CDATA[
if (this.ThrowerEntityId > 0)
{
this.SpeedX = reader.readShort();
this.SpeedY = reader.readShort();
this.SpeedZ = reader.readShort();
}
]]>
</Read>
<Write>
<![CDATA[
if (this.ThrowerEntityId > 0)
{
writer.writeShort(this.SpeedX);
writer.writeShort(this.SpeedY);
writer.writeShort(this.SpeedZ);
}
]]>
</Write>
</Field>
<Comments>
<![CDATA[
Server to Client
Sent by the server when an Object/Vehicle is created. The throwers entity id is now used for fishing floats too.
]]>
</Comments>
</Packet>
<Packet name="SpawnMob" id="0x18">
<Field name="EID" type="int" note="Entity ID" />
<Field name="Type" type="byte" note="The type of mob. See Entities#Mobs" />
<Field name="X" type="int" note="The Absolute Integer X Position of the object" />
<Field name="Y" type="int" note="The Absolute Integer Y Position of the object" />
<Field name="Z" type="int" note="The Absolute Integer Z Position of the object" />
<Field name="Pitch" type="byte" note="The pitch in steps of 2p/256" />
<Field name="HeadPitch" type="byte" note="The head pitch in steps of 2p/256" />
<Field name="Yaw" type="byte" note="Yaw in steps of 2p/256" />
<Field name="VelocityX" type="short" note="" />
<Field name="VelocityY" type="short" note="" />
<Field name="VelocityZ" type="short" note="" />
<Field name="Metadata" type="Metadata" note="Varies by mob, see Entities" />
<Comments>
<![CDATA[
Server to Client
Sent by the server when a Mob Entity is Spawned
]]>
</Comments>
</Packet>
<Packet name="SpawnPainting" id="0x19">
<Field name="EntityID" type="int" note="Unique entity ID" />
<Field name="Title" type="string" note="Name of the painting; max length 13 (length of &quot;SkullAndRoses&quot;)" />
<Field name="X" type="int" note="Center X coordinate" />
<Field name="Y" type="int" note="Center Y coordinate" />
<Field name="Z" type="int" note="Center Z coordinate" />
<Field name="Direction" type="int" note="Direction the painting faces (0 -z, 1 -x, 2 +z, 3 +x)" />
<Comments>
<![CDATA[
Server to Client
This packet shows location, name, and type of painting.
Calculating the center of an image: given a (width x height) grid of cells, with (0, 0) being the top left corner, the center is (max(0, width / 2 - 1), height / 2). E.g.
2x1 (1, 0) 4x4 (1, 2)
]]>
</Comments>
</Packet>
<Packet name="SpawnExperienceOrb" id="0x1A">
<Field name="EntityID" type="int" note="" />
<Field name="x" type="int" note="" />
<Field name="y" type="int" note="" />
<Field name="z" type="int" note="" />
<Field name="count" type="short" note="" />
<Comments>
<![CDATA[
Server to Client
Spawns one or more experience orbs. Coordinates are in absolute units.
]]>
</Comments>
</Packet>
<Packet name="SteerVehicle" id="0x1B">
<Field name="Sideways" type="float" note="Positive to the left of the player" />
<Field name="Forward" type="float" note="Positive forward" />
<Field name="Jump" type="bool" note="" />
<Field name="Unmount" type="bool" note="True when leaving the vehicle" />
<Comments>
<![CDATA[
Client to Server
Sent by client to steer the horse, minecart and boats. Horses listen to all directions, boats and minecarts only listen to the positive forward value in combination with the direction the player is looking in.
]]>
</Comments>
</Packet>
<Packet name="EntityVelocity" id="0x1C">
<Field name="EntityID" type="int" note="The entity ID" />
<Field name="VelocityX" type="short" note="Velocity on the X axis" />
<Field name="VelocityY" type="short" note="Velocity on the Y axis" />
<Field name="VelocityZ" type="short" note="Velocity on the Z axis" />
<Comments>
<![CDATA[
Server to Client
This packet is new to version 4 of the protocol, and is believed to be Entity Velocity/Motion.
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).
(This packet data values are not fully verified)
]]>
</Comments>
</Packet>
<Packet name="DestroyEntity" id="0x1D">
<Field name="EntityCount" type="byte" note="The amount of entities which should be destroyed" />
<Field name="EntityIDs" type="int[]" note="The list of entity ids which should be destroyed">
<Read>
<![CDATA[
this.EntityIDs = [];
for (var i = 0; i < this.EntityCount; i++)
{
this.EntityIDs[i] = reader.readInt();
}
]]>
</Read>
<Write>
<![CDATA[
]]>
</Write>
</Field>
<Comments>
<![CDATA[
Server to Client
Sent by the server when an list of Entities is to be destroyed on the client.
]]>
</Comments>
</Packet>
<Packet name="Entity" id="0x1E">
<Field name="EID" type="int" note="Entity ID" />
<Comments>
<![CDATA[
Server to Client
Most entity-related packets are subclasses of this packet. When sent from the server to the client, it may initialize the entry.
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.
]]>
</Comments>
</Packet>
<Packet name="EntityRelativeMove" id="0x1F">
<Field name="EID" type="int" note="Entity ID" />
<Field name="dX" type="byte" note="X axis Relative movement as an Absolute Integer" />
<Field name="dY" type="byte" note="Y axis Relative movement as an Absolute Integer" />
<Field name="dZ" type="byte" note="Z axis Relative movement as an Absolute Integer" />
<Comments>
<![CDATA[
Server to Client
This packet is sent by the server when an entity moves less then 4 blocks; if an entity moves more than 4 blocks Entity Teleport should be sent instead.
This packet allows at most four blocks movement in any direction, because byte range is from -128 to 127. Movement is an offset of Absolute Int; to convert relative move to block coordinate offset, divide by 32.
]]>
</Comments>
</Packet>
<Packet name="EntityLook" id="0x20">
<Field name="EID" type="int" note="Entity ID" />
<Field name="Yaw" type="byte" note="The X Axis rotation as a fraction of 360" />
<Field name="Pitch" type="byte" note="The Y Axis rotation as a fraction of 360" />
<Comments>
<![CDATA[
Server to Client
This packet is sent by the server when an entity rotates. Example: "Yaw" field 64 means a 90 degree turn.
]]>
</Comments>
</Packet>
<Packet name="EntityLookandRelativeMove" id="0x21">
<Field name="EID" type="int" note="Entity ID" />
<Field name="dX" type="byte" note="X axis Relative movement as an Absolute Integer" />
<Field name="dY" type="byte" note="Y axis Relative movement as an Absolute Integer" />
<Field name="dZ" type="byte" note="Z axis Relative movement as an Absolute Integer" />
<Field name="Yaw" type="byte" note="The X Axis rotation as a fraction of 360" />
<Field name="Pitch" type="byte" note="The Y Axis rotation as a fraction of 360" />
<Comments>
<![CDATA[
Server to Client
This packet is sent by the server when an entity rotates and moves. Since a byte range is limited from -128 to 127, and movement is offset of Absolute Int, this packet allows at most four blocks movement in any direction. (-128/32 == -4)
]]>
</Comments>
</Packet>
<Packet name="EntityTeleport" id="0x22">
<Field name="EID" type="int" note="Entity ID" />
<Field name="X" type="int" note="X axis position as an Absolute Integer" />
<Field name="Y" type="int" note="Y axis position as an Absolute Integer" />
<Field name="Z" type="int" note="Z axis position as an Absolute Integer" />
<Field name="Yaw" type="byte" note="The X Axis rotation as a fraction of 360" />
<Field name="Pitch" type="byte" note="The Y Axis rotation as a fraction of 360" />
<Comments>
<![CDATA[
Server to Client
This packet is sent by the server when an entity moves more than 4 blocks.
]]>
</Comments>
</Packet>
<Packet name="EntityHeadLook" id="0x23">
<Field name="EntityID" type="int" note="" />
<Field name="HeadYaw" type="byte" note="Head yaw in steps of 2p/256" />
<Comments>
<![CDATA[
Server to Client
Changes the direction an entity's head is facing.
]]>
</Comments>
</Packet>
<Packet name="EntityStatus" id="0x26">
<Field name="EntityID" type="Int" note="" />
<Field name="EntityStatus" type="Byte" note="See below" />
<Comments>
<![CDATA[
Server to Client
]]>
</Comments>
</Packet>
<Packet name="AttachEntity" id="0x27">
<Field name="EntityID" type="int" note="The player entity ID being attached" />
<Field name="VehicleID" type="int" note="The vehicle entity ID attached to (-1 for unattaching)" />
<Field name="Leash" type="boolean" note="If set to true, leashes the entity to the vehicle" />
<Comments>
<![CDATA[
Server to Client
This packet is sent when a player has been attached to an entity (e.g. Minecart)
]]>
</Comments>
</Packet>
<Packet name="EntityMetadata" id="0x28">
<Field name="EntityID" type="int" note="Unique entity ID to update." />
<Field name="EntityMetadata" type="Metadata" note="Metadata varies by entity. See Entities" />
<Comments>
<![CDATA[
Server to Client
]]>
</Comments>
</Packet>
<Packet name="EntityEffect" id="0x29">
<Field name="EntityID" type="int" note="Entity ID of a player" />
<Field name="EffectID" type="byte" note="See here" />
<Field name="Amplifier" type="byte" note="" />
<Field name="Duration" type="short" note="" />
<Comments>
<![CDATA[
Server to Client
]]>
</Comments>
</Packet>
<Packet name="RemoveEntityEffect" id="0x2a">
<Field name="EntityID" type="int" note="Entity ID of a player" />
<Field name="EffectID" type="byte" note="See here" />
<Comments>
<![CDATA[
Server to Client
]]>
</Comments>
</Packet>
<Packet name="SetExperience" id="0x2B">
<Field name="Experiencebar" type="float" note="Used for drawing the experience bar - value is between 0 and 1." />
<Field name="Level" type="short" note="" />
<Field name="Totalexperience" type="short" note="" />
<Comments>
<![CDATA[
Server to Client
Sent by the server when the client should change experience levels.
]]>
</Comments>
</Packet>
<Packet name="EntityProperties" id="0x2C">
<Field name="EntityID" type="int" note="?" />
<Field name="PropertiesCount" type="int" note="Number of string/data pairs that follow. The remaining fields here are repeated this number of times." />
<Field name="Key" type="string" note="" />
<Field name="Value" type="double" note="" />
<Comments>
<![CDATA[
Server to Client
Note: The server sends this packet to inform the user of its movement speed. Users move far too fast when this packet is not sent.
Known values:
]]>
</Comments>
</Packet>
<Packet name="ChunkData" id="0x33">
<Field name="X" type="int" note="Chunk X Coordinate (*16 to get true X)" />
<Field name="Z" type="int" note="Chunk Z Coordinate (*16 to get true Z)" />
<Field name="Groundupcontinuous" type="boolean" note="This is True if the packet represents all sections in this vertical column, where the primary bit map specifies exactly which sections are included, and which are air." />
<Field name="Primarybitmap" type="ushort" note="Bitmask with 1 for every 16x16x16 section which data follows in the compressed data." />
<Field name="Addbitmap" type="ushort" note="Same as above, but this is used exclusively for the 'add' portion of the payload" />
<!--<Field name="Compressedsize" type="int" note="Size of compressed chunk data." />-->
<Field name="Compresseddata" type="ubyte[]" note="The chunk data is compressed using ZLib Deflate function.">
<Read>
<![CDATA[
var length = reader.readInt();
this.Compresseddata = reader.readBytes(length);
]]>
</Read>
<Write>
<![CDATA[
writer.writeInt(this.Compresseddata.length);
writer.writeBytes(this.Compresseddata);
]]>
</Write>
</Field>
<Comments>
<![CDATA[
Server to Client
Chunks are not unloaded by the client automatically. To unload chunks, send this packet with ground-up continuous=true and no 16^3 chunks (eg. primary bit mask=0). The server does not send skylight information for nether-chunks, it's up to the client to know if the player is currently in the nether. You can also infer this information from the primary bitmask and the amount of uncompressed bytes sent.
See also: SMP Map Format
]]>
</Comments>
</Packet>
<Packet name="MultiBlockChange" id="0x34">
<Field name="ChunkX" type="int" note="Chunk X Coordinate" />
<Field name="ChunkZ" type="int" note="Chunk Z Coordinate" />
<Field name="Recordcount" type="short" note="The number of blocks affected" />
<Field name="Datasize" type="int" note="The total size of the data, in bytes. Should always be 4*record count - please confirm." />
<Field name="CoordinateArray" type="Coordinates[]" note="Block coordinates" write="false" read="false" />
<Field name="TypeArray" type="byte[]" note="Block Ids" write="false" read="false" />
<Field name="Metadata" type="byte[]" note="Block metadata.">
<Read>
<![CDATA[
this.CoordinateArray = [];
this.TypeArray = [];
this.Metadata = [];
for (var i = 0; i < this.Datasize; i++)
{
var idMetadata = reader.readShort();
var coordY = reader.readByte();
var coordZX = reader.readByte();
this.CoordinateArray[i] = new Coordinates(coordZX >> 4, coordY, coordZX & 0xF);
this.TypeArray[i] = idMetadata >> 4;
this.Metadata[i] = idMetadata & 0xF;
}
]]>
</Read>
<Write>
<![CDATA[
for (var i = 0; i < this.Datasize; i++)
{
writer.writeShort(this.TypeArray[i] << 4 | this.Metadata[i]);
writer.writeByte(this.CoordinateArray[i].y);
writer.writeByte(this.CoordinateArray[i].z << 4 | this.CoordinateArray[i].z);
}
]]>
</Write>
</Field>
<Comments>
<![CDATA[
Server to Client
Each record is four bytes.
]]>
</Comments>
</Packet>
<Packet name="BlockChange" id="0x35">
<Field name="X" type="int" note="Block X Coordinate" />
<Field name="Y" type="byte" note="Block Y Coordinate" />
<Field name="Z" type="int" note="Block Z Coordinate" />
<Field name="BlockType" type="short" note="The new block type for the block" />
<Field name="BlockMetadata" type="byte" note="The new Metadata for the block" />
<Comments>
<![CDATA[
Server to Client
]]>
</Comments>
</Packet>
<Packet name="BlockAction" id="0x36">
<Field name="X" type="int" note="Block X Coordinate" />
<Field name="Y" type="short" note="Block Y Coordinate" />
<Field name="Z" type="int" note="Block Z Coordinate" />
<Field name="Byte1" type="byte" note="Varies depending on block - see below" />
<Field name="Byte2" type="byte" note="Varies depending on block - see below" />
<Field name="BlockID" type="short" note="The block id this action is set for" />
<Comments>
<![CDATA[
Server to Client
This packet is used for a number of things:
Chests opening and closing
Pistons pushing and pulling
Note blocks playing
See Also: Block Actions
]]>
</Comments>
</Packet>
<Packet name="BlockBreakAnimation" id="0x37">
<Field name="EID" type="int" note="Entity breaking the block?" />
<Field name="X" type="int" note="Block position" />
<Field name="Y" type="int" note="" />
<Field name="Z" type="int" note="" />
<Field name="DestroyStage" type="byte" note="How far destroyed this block is. (0-7)" />
<Comments>
<![CDATA[
Server to Client
]]>
</Comments>
</Packet>
<Packet name="MapChunkBulk" id="0x38">
<Field name="Chunkcolumncount" type="short" note="The number of chunks in this packet" />
<Field name="Datalength" type="int" note="the size of the data field" />
<Field name="Skylightsent" type="boolean" note="Whether or not the chunk data contains a light nibble array. This is true in the main world, false in the end + nether" />
<Field name="chunkPostX" type="int[]" note="" read="flase" write="false" count="false" />
<Field name="chunkPosZ" type="int[]" note="" read="flase" write="false" count="false" />
<Field name="chunkExistFlags" type="short[]" note="" read="flase" write="false" count="false" />
<Field name="chunkHasAddSectionFlags" type="short[]" note="" read="flase" write="false" count="false" />
<Field name="Data" type="byte[][]" note="Compressed chunk data" read="flase" write="false" count="false">
<Read>
<![CDATA[
var compressedData = [];
reader.readFully(compressedData, 0, this.Datalength);
var inflater = new Utils.Inflater();
var decompressedData = inflater.inflate(compressedData);
compressedData = []; // kill compressed data right away;
var i = 0;
for (var j = 0; j < this.Chunkcolumncount; ++j)
{
this.chunkPostX[j] = reader.readInt();
this.chunkPosZ[j] = reader.readInt();
this.chunkExistFlags[j] = reader.readUshort();
this.chunkHasAddSectionFlags[j] = reader.readUshort();
var k = 0;
var l = 0;
var i1;
for (i1 = 0; i1 < 16; ++i1)
{
k += this.chunkExistFlags[j] >> i1 & 1;
l += this.chunkHasAddSectionFlags[j] >> i1 & 1;
}
i1 = 2048 * 4 * k + 256;
i1 += 2048 * l;
if (this.Skylightsent)
{
i1 += 2048 * k;
}
this.Data[j] = decompressedData.slice(i, i + i1);
i += i1;
}
]]>
</Read>
<Write>
<![CDATA[
]]>
</Write>
</Field>
<Comments>
<![CDATA[
Server to Client
See also: SMP Map Format
To reduce the number of bytes this packet is used to send chunks together for better compression results.
If you send this packet to update area surrounding player in the middle of the game, entities within the updated area may become unattackable (vanilla client just won't send "Use Entity (0x07)" packet when you try to hit them, only swing animation, also it will dig blocks through them), even though they will be visible and work correctly in other ways. This is a bug in vanilla client (still there in 1.5.2), but you can workaround it by destroying relevant entities prior to sending 0x38 (via 0x1D) and spawning them again after it.
]]>
</Comments>
</Packet>
<Packet name="Explosion" id="0x3C">
<Field name="X" type="double" note="" />
<Field name="Y" type="double" note="" />
<Field name="Z" type="double" note="" />
<Field name="Radius" type="float" note="Currently unused in the client" />
<Field name="Recordcount" type="int" note="This is the count, not the size. The size is 3 times this value." />
<Field name="Records" type="Coordinates[]" note="Each record is 3 signed bytes long, each bytes are the XYZ (respectively) offsets of affected blocks.">
<Read>
<![CDATA[
this.Records = [];
for (var i = 0; i < this.Recordcount; i++) {
this.Records[i] = new Coordinates(reader.readByte(), reader.readByte(), reader.readByte());
}
]]>
</Read>
<Write>
<![CDATA[
for (var i = 0; i < this.Recordcount; i++) {
writer.writeByte(this.Records[i].x);
writer.writeByte(this.Records[i].y);
writer.writeByte(this.Records[i].z);
}
]]>
</Write>
</Field>
<Field name="PlayerMotionX" type="float" note="X velocity of the player being pushed by the explosion" />
<Field name="PlayerMotionY" type="float" note="Y velocity of the player being pushed by the explosion" />
<Field name="PlayerMotionZ" type="float" note="Z velocity of the player being pushed by the explosion" />
<Comments>
<![CDATA[
Server to Client
Sent when an explosion occurs (creepers, TNT, and ghast fireballs).
Each block in Records is set to air. Coordinates for each axis in record is int(X) + record.x
]]>
</Comments>
</Packet>
<Packet name="SoundOrParticleEffect" id="0x3D">
<Field name="EffectID" type="int" note="The ID of the effect, see below." />
<Field name="X" type="int" note="The X location of the effect." />
<Field name="Y" type="byte" note="The Y location of the effect." />
<Field name="Z" type="int" note="The Z location of the effect." />
<Field name="Data" type="int" note="Extra data for certain effects, see below." />
<Field name="Disablerelativevolume" type="boolean" note="See above" />
<Comments>
<![CDATA[
Server to Client
Sent when a client is to play a sound or particle effect.
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 1013 (mob.wither.spawn), and is ignored for any other value by the client.
Sound:
1000: random.click
1001: random.click
1002: random.bow
1003: random.door_open or random.door_close (50/50 chance)
1004: random.fizz
1005: Play a music disc. Data: Record ID
(1006 not assigned)
1007: mob.ghast.charge
1008: mob.ghast.fireball
(1009 not assigned)
1010: mob.zombie.wood
1011: mob.zombie.metal
1012: mob.zombie.woodbreak
1013: mob.wither.spawn
Particle:
2000: Spawns 10 smoke particles, e.g. from a fire. Data: direction, see below
2001: Block break. Data: Block ID
2002: Splash potion. Particle effect + glass break sound. Data: Potion ID
2003: Eye of ender. Actual client effect to be determined.
2004: Mob spawn particle effect: smoke + flames
Smoke directions:
]]>
</Comments>
</Packet>
<Packet name="NamedSoundEffect" id="0x3E">
<Field name="Soundname" type="string" note="250" />
<Field name="EffectpositionX" type="int" note="effect X multiplied by 8" />
<Field name="EffectpositionY" type="int" note="effect Y multiplied by 8" />
<Field name="EffectpositionZ" type="int" note="effect Z multiplied by 8" />
<Field name="Volume" type="float" note="1 is 100%, can be more" />
<Field name="Pitch" type="byte" note="63 is 100%, can be more" />
<Comments>
<![CDATA[
Server to client
Used to play a sound effect on the client.
All known sound effect names can be seen here.
]]>
</Comments>
</Packet>
<Packet name="Particle" id="0x3F">
<Field name="Particlename" type="string" note="The name of the particle to create. A list can be found here" />
<Field name="X" type="float" note="X position of the particle" />
<Field name="Y" type="float" note="Y position of the particle" />
<Field name="Z" type="float" note="Z position of the particle" />
<Field name="OffsetX" type="float" note="This is added to the X position after being multiplied by random.nextGaussian()" />
<Field name="OffsetY" type="float" note="This is added to the Y position after being multiplied by random.nextGaussian()" />
<Field name="OffsetZ" type="float" note="This is added to the Z position after being multiplied by random.nextGaussian()" />
<Field name="Particlespeed" type="float" note="The speed of each particle" />
<Field name="Numberofparticles" type="int" note="The number of particles to create" />
<Comments>
<![CDATA[
Server to Client
This displays the named particle
]]>
</Comments>
</Packet>
<Packet name="ChangeGameState" id="0x46">
<Field name="Reason" type="byte" note="" />
<Field name="Gamemode" type="byte" note="Used only when reason = 3. 0 is survival, 1 is creative." />
<Comments>
<![CDATA[
Server to Client
This packet appeared with protocol version 10. Currently, it appears when a bed can't be used as a spawn point and when the rain state changes. it could have additional uses in the future.
The class has an array of strings linked to reason codes 0, 1, 2, and 3 but only the codes for 1 and 2 are null.
Reason codes
]]>
</Comments>
</Packet>
<Packet name="SpawnGlobalEntity" id="0x47">
<Field name="EntityID" type="int" note="The entity ID of the thunderbolt" />
<Field name="Type" type="byte" note="The global entity type, currently always 1 for thunderbolt." />
<Field name="X" type="int" note="Thunderbolt X as Absolute Integer" />
<Field name="Y" type="int" note="Thunderbolt Y as Absolute Integer" />
<Field name="Z" type="int" note="Thunderbolt Z as Absolute Integer" />
<Comments>
<![CDATA[
Server to Client
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.
]]>
</Comments>
</Packet>
<Packet name="OpenWindow" id="0x64">
<Field name="Windowid" type="byte" note="A unique id number for the window to be displayed. Notchian server implementation is a counter, starting at 1." />
<Field name="InventoryType" type="byte" note="The window type to use for display. Check below" />
<Field name="Windowtitle" type="string" note="The title of the window." />
<Field name="NumberofSlots" type="byte" note="Number of slots in the window (excluding the number of slots in the player inventory)." />
<Field name="Useprovidedwindowtitle" type="boolean" note="If false, the client will look up a string like &quot;window.minecart&quot;. If true, the client uses what the server provides." />
<Field name="Unknown" type="int" note="Only sent when window type is equal to 11" />
<Comments>
<![CDATA[
Server to Client
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.
See inventory windows for further information.
]]>
</Comments>
</Packet>
<Packet name="CloseWindow" id="0x65">
<Field name="Windowid" type="byte" note="This is the id of the window that was closed. 0 for inventory." />
<Comments>
<![CDATA[
Two-Way
This packet is sent by the client when closing a window. 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.
Note, notchian clients send a close window message with window id 0 to close their inventory even though there is never an Open Window message for inventory.
]]>
</Comments>
</Packet>
<Packet name="ClickWindow" id="0x66">
<Field name="Windowid" type="byte" note="The id of the window which was clicked. 0 for player inventory." />
<Field name="Slot" type="short" note="The clicked slot. See below." />
<Field name="Button" type="byte" note="The button used in the click. See below." />
<Field name="Actionnumber" type="short" note="A unique number for the action, used for transaction handling (See the Transaction packet)." />
<Field name="Mode" type="byte" note="Inventory operation mode. See below." />
<Field name="Clickeditem" type="slot" note="" />
<Comments>
<![CDATA[
Client to Server
This packet is sent by the player when it clicks on a slot in a window.
See inventory windows for further information about how slots are indexed.
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.
The Action number is actually a counter, starting at 1. This number is used by the server as a transaction ID to send back a Transaction packet.
The distinct type of click performed by the client is determined by the combination of the "Mode" and "Button" fields.
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 items), then holding mouse button (left, right or middle) and dragging holded 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):
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.
]]>
</Comments>
</Packet>
<Packet name="SetSlot" id="0x67">
<Field name="Windowid" type="byte" note="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)." />
<Field name="Slot" type="short" note="The slot that should be updated" />
<Field name="Slotdata" type="slot" note="" />
<Comments>
<![CDATA[
Server to Client
Sent by the server when an item in a slot (in a window) is added/removed.
Note that if window ID and slot are both -1, it means the item currently attached to the cursor.
See inventory windows for further information about how slots are indexed.
Slots: [1]
]]>
</Comments>
</Packet>
<Packet name="SetWindowItems" id="0x68">
<Field name="Windowid" type="byte" note="The id of window which items are being sent for. 0 for player inventory." />
<Field name="Count" type="short" note="The number of slots (see below)" />
<Field name="Slotdata" type="Slot[]" note="">
<Read>
<![CDATA[
this.Slotdata = [];
for (var i = 0; i < this.Count; i++)
{
this.Slotdata[i] = reader.readSlot();
}
]]>
</Read>
<Write>
<![CDATA[
for (var i = 0; i < this.Count; i++)
{
writer.writeSlot(this.Slotdata[i]);
}
]]>
</Write>
</Field>
<Comments>
<![CDATA[
Server to Client
Sent by the server when an item in a slot (in a window) is added/removed. This includes the main inventory, equipped armour and crafting slots.
See inventory windows for further information about how slots are indexed.
]]>
</Comments>
</Packet>
<Packet name="UpdateWindowProperty" id="0x69">
<Field name="Windowid" type="byte" note="The id of the window." />
<Field name="Property" type="short" note="Which property should be updated." />
<Field name="Value" type="short" note="The new value for the property." />
<Comments>
<![CDATA[
Server to Client
Furnace
Properties:
0: Progress arrow
1: Fire icon (fuel)
Values:
0-200 for progress arrow
0-200 for fuel indicator
Ranges are presumably in in-game ticks
Enchantment Table
Properties: 0, 1 or 2 depending on the "enchantment slot" being given.
Values: The enchantment's level.
]]>
</Comments>
</Packet>
<Packet name="ConfirmTransaction" id="0x6A">
<Field name="Windowid" type="byte" note="The id of the window that the action occurred in." />
<Field name="Actionnumber" type="short" note="Every action that is to be accepted has a unique number. This field corresponds to that number." />
<Field name="Accepted" type="boolean" note="Whether the action was accepted." />
<Comments>
<![CDATA[
Two-Way
A packet from the server indicating whether a request from the client was accepted, or whether there was a conflict (due to lag). This packet is also sent from the client to the server in response to a server transaction rejection packet.
]]>
</Comments>
</Packet>
<Packet name="CreativeInventoryAction" id="0x6B">
<Field name="Slot" type="short" note="Inventory slot" />
<Field name="Clickeditem" type="slot" note="" />
<Comments>
<![CDATA[
Two-Way
While the user is in the standard inventory (i.e., not a crafting bench) on a creative-mode server then the server will send this packet:
If an item is dropped into the quick bar
If an item is picked up from the quick bar (item id is -1)
]]>
</Comments>
</Packet>
<Packet name="EnchantItem" id="0x6C">
<Field name="WindowID" type="byte" note="The ID sent by Open Window" />
<Field name="Enchantment" type="byte" note="The position of the enchantment on the enchantment table window, starting with 0 as the topmost one." />
<Comments>
<![CDATA[
Client to Server
]]>
</Comments>
</Packet>
<Packet name="UpdateSign" id="0x82">
<Field name="X" type="int" note="Block X Coordinate" />
<Field name="Y" type="short" note="Block Y Coordinate" />
<Field name="Z" type="int" note="Block Z Coordinate" />
<Field name="Text1" type="string" note="First line of text in the sign" />
<Field name="Text2" type="string" note="Second line of text in the sign" />
<Field name="Text3" type="string" note="Third line of text in the sign" />
<Field name="Text4" type="string" note="Fourth line of text in the sign" />
<Comments>
<![CDATA[
Two-Way
This message is sent from the server to the client whenever a sign is discovered or created. This message is sent from the client to the server when the "Done" button is pushed after placing a sign. This message is NOT sent when a sign is destroyed or unloaded.
]]>
</Comments>
</Packet>
<Packet name="ItemData" id="0x83">
<Field name="ItemType" type="short" note="Type of item being modified" />
<Field name="ItemID" type="short" note="The ID (damage value) of the item being modified" />
<!--<Field name="Textlength" type="short" note="Length of following byte array" />-->
<Field name="Text" type="byte[]" note="ASCII text.">
<Read>
<![CDATA[
var length = reader.readShort();
this.Text = reader.readBytes(length);
]]>
</Read>
<Write>
<![CDATA[
writer.writeShort(this.Text.length);
writer.writeBytes(this.Text);
]]>
</Write>
</Field>
<Comments>
<![CDATA[
Server to Client
Sent to specify complex data on an item; currently used only for maps.
Maps If the first byte of the text is 0, the next two bytes are X start and Y start and the rest of the bytes are the colors in that column.
If the first byte of the text is 1, the rest of the bytes are in groups of three: (data, x, y). The lower half of the data is the type (always 0 under vanilla) and the upper half is the direction.
]]>
</Comments>
</Packet>
<Packet name="UpdateTileEntity" id="0x84">
<Field name="X" type="int" note="" />
<Field name="Y" type="short" note="" />
<Field name="Z" type="int" note="" />
<Field name="Action" type="byte" note="The type of update to perform" />
<!--<Field name="Datalength" type="Short" note="Varies" />-->
<Field name="NBTData" type="byte[]" note="Present if data length > 0. Compressed with gzip. Varies">
<Read>
<![CDATA[
var length = reader.readShort();
if (length != -1) {
this.NBTData = reader.readBytes(length);
} else {
this.NBTData = [];
}
]]>
</Read>
<Write>
<![CDATA[
if (this.NBTData == null || this.NBTData == undefined || this.NBTData.length == 0) {
writer.writeShort(-1);
} else {
writer.writeShort(this.NBTData.length);
writer.writeBytes(this.NBTData);
}
]]>
</Write>
</Field>
<Comments>
<![CDATA[
Server to Client
Essentially a block update on a tile entity.
Actions
1: Set mob displayed inside a mob spawner. Custom 1 contains the mob type
]]>
</Comments>
</Packet>
<Packet name="IncrementStatistic" id="0xC8">
<Field name="StatisticID" type="int" note="The ID of the statistic. See List of statistics." />
<Field name="Amount" type="int" note="The amount to increment the statistic." />
<Comments>
<![CDATA[
Server to Client
]]>
</Comments>
</Packet>
<Packet name="PlayerListItem" id="0xC9">
<Field name="Playername" type="string" note="Supports chat colouring, limited to 16 characters." />
<Field name="Online" type="boolean" note="If false, the client will remove the user from the list." />
<Field name="Ping" type="short" note="Ping, presumably in ms." />
<Comments>
<![CDATA[
Server to Client
Sent by the notchian server to update the user list (<tab> in the client). The server sends one packet per user per tick, amounting to 20 packets/s for 1 online user, 40 for 2, and so forth.
]]>
</Comments>
</Packet>
<Packet name="PlayerAbilities" id="0xCA">
<Field name="Flags" type="byte" note="" />
<Field name="Flyingspeed" type="float" note="previous integer value divided by 250" />
<Field name="Walkingspeed" type="float" note="previous integer value divided by 250" />
<Comments>
<![CDATA[
Two-Way
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.
The flags are whether damage is disabled (god mode, 8, bit 3), whether the player can fly (4, bit 2), whether the player is flying (2, bit 1), and whether the player is in creative mode (1, bit 0).
To get the values of these booleans, simply AND (&) the byte with 1,2,4 and 8 respectively, to get the 0 or 1 bitwise value. To set them OR (|) them with their repspective masks. The vanilla client sends this packet when the player starts/stops flying with the second parameter changed accordingly. All other parameters are ignored by the vanilla server.
The client ignores the walking speed and flying speed fields. Send an 0x2C packet as well.
]]>
</Comments>
</Packet>
<Packet name="Tabcomplete" id="0xCB">
<Field name="Text" type="string" note="" />
<Comments>
<![CDATA[
Two-way
Sent C->S when the user presses [tab] while writing text. The payload contains all text behind the cursor.
The server responds with an auto-completion 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.
In the event of more than one possible completion, the server responds with the options packed into the single string field, separated by a null character. Note that as strings are UTF-16, this is two bytes wide.
]]>
</Comments>
</Packet>
<Packet name="ClientSettings" id="0xCC">
<Field name="Locale" type="string" note="" />
<Field name="Viewdistance" type="byte" note="0-3 for 'far', 'normal', 'short', 'tiny'." />
<Field name="Chatflags" type="byte" note="Chat settings. See notes below." />
<Field name="Difficulty" type="byte" note="Client-side difficulty from options.txt" />
<Field name="ShowCape" type="boolean" note="Client-side &quot;show cape&quot; option" />
<Comments>
<![CDATA[
Client to server
Sent when the player connects, or when settings are changed.
Chat flags has several values packed into one byte.
Chat Enabled: Bits 0-1. 00: Enabled. 01: Commands only. 10: Hidden.
Colors Enabled: Bit 3. 0: Disabled. 1: Enabled.
]]>
</Comments>
</Packet>
<Packet name="ClientStatuses" id="0xCD">
<Field name="Payload" type="byte" note="Bit field. 0: Initial spawn, 1: Respawn after death" />
<Comments>
<![CDATA[
Client to server
Sent when the client is ready to complete login and when the client is ready to respawn after death.
]]>
</Comments>
</Packet>
<Packet name="ScoreboardObjective" id="0xCE">
<Field name="Objectivename" type="string" note="An unique name for the objective" />
<Field name="Objectivevalue" type="string" note="The text to be displayed for the score." />
<Field name="CreateRemove" type="byte" note="0 to create the scoreboard. 1 to remove the scoreboard. 2 to update the display text. TODO: Check these values" />
<Comments>
<![CDATA[
Server to Client
This is sent to the client when it should create a new scoreboard or remove one.
]]>
</Comments>
</Packet>
<Packet name="UpdateScore" id="0xCF">
<Field name="ItemName" type="string" note="An unique name to be displayed in the list." />
<Field name="UpdateRemove" type="byte" note="0 to create/update an item. 1 to remove an item." />
<Field name="ScoreName" type="string" note="The unique name for the scoreboard to be updated. Only sent when Update/Remove does not equal 1." />
<Field name="Value" type="int" note="The score to be displayed next to the entry. Only sent when Update/Remove does not equal 1." />
<Comments>
<![CDATA[
Server to Client
This is sent to the client when it should update a scoreboard item.
]]>
</Comments>
</Packet>
<Packet name="DisplayScoreboard" id="0xD0">
<Field name="Position" type="byte" note="The position of the scoreboard. 0 = list, 1 = sidebar, 2 = belowName." />
<Field name="ScoreName" type="string" note="The unique name for the scoreboard to be displayed." />
<Comments>
<![CDATA[
Server to Client
This is sent to the client when it should display a scoreboard.
]]>
</Comments>
</Packet>
<Packet name="Teams" id="0xD1">
<Field name="TeamName" type="string" note="A unique name for the team. (Shared with scoreboard)." />
<Field name="Mode" type="byte" note="If 0 then the team is created.
If 1 then the team is removed.
If 2 the team team information is updated.
If 3 then new players are added to the team.
If 4 then players are removed from the team." />
<Field name="TeamDisplayName" type="string" note="Only if Mode = 0 or 2." />
<Field name="TeamPrefix" type="string" note="Only if Mode = 0 or 2. Displayed before the players' name that are part of this team." />
<Field name="TeamSuffix" type="string" note="Only if Mode = 0 or 2. Displayed after the players' name that are part of this team." />
<Field name="Friendlyfire" type="byte" note="Only if Mode = 0 or 2; 0 for off, 1 for on, 3 for seeing friendly invisibles" />
<Field name="Playercount" type="short" note="Only if Mode = 0 or 3 or 4. Number of players in the array" />
<Field name="Players" type="string[]" note="Only if Mode = 0 or 3 or 4. Players to be added/remove from the team.">
<Read>
<![CDATA[
for (var i = 0; i < this.Playercount; i++)
{
this.Players[i] = reader.readString();
}
]]>
</Read>
</Field>
<Comments>
<![CDATA[
Server to Client
Creates and updates teams.
]]>
</Comments>
</Packet>
<Packet name="PluginMessage" id="0xFA">
<Field name="Channel" type="string" note="Name of the &quot;channel&quot; used to send the data." />
<Field name="data" type="byte[]" note="Any data.">
<Read>
<![CDATA[
var length = reader.readShort();
this.data = reader.readBytes(length);
]]>
</Read>
<Write>
<![CDATA[
writer.writeShort(this.data.length);
writer.writeBytes(this.data);
]]>
</Write>
</Field>
<Comments>
<![CDATA[
Two-Way
Mods and plugins can use this to send their data. As of 1.3, Minecraft itself uses a number of plugin channels. These internal channels are prefixed with MC|.
More documentation on this: http://dinnerbone.com/blog/2012/01/13/minecraft-plugin-channels-messaging/
]]>
</Comments>
</Packet>
<Packet name="EncryptionKeyResponse" id="0xFC">
<!--<Field name="Sharedsecretlength" type="short" note="" />-->
<Field name="Sharedsecret" type="byte[]" note="">
<Read>
<![CDATA[
var length = reader.readShort();
this.Sharedsecret = reader.readBytes(length);
]]>
</Read>
<Write>
<![CDATA[
writer.writeShort(this.Sharedsecret.length);
writer.writeBytes(this.Sharedsecret);
]]>
</Write>
</Field>
<!--<Field name="Verifytokenlength" type="short" note="" />-->
<Field name="Verifytokenresponse" type="byte[]" note="" >
<Read>
<![CDATA[
var length = reader.readShort();
this.Verifytokenresponse = reader.readBytes(length);
]]>
</Read>
<Write>
<![CDATA[
writer.writeShort(this.Verifytokenresponse.length);
writer.writeBytes(this.Verifytokenresponse);
]]>
</Write>
</Field>
<Comments>
<![CDATA[
Two-Way
See Protocol Encryption for information on this packet. Bypassing the encryption is possible, authentication for the player name is still needed if the server is in online mode, but instead of sending this packet, you send Client Statuses instead.
]]>
</Comments>
</Packet>
<Packet name="EncryptionKeyRequest" id="0xFD">
<Field name="Serverid" type="string" note="" />
<!--<Field name="Publickeylength" type="short" note="" />-->
<Field name="Publickey" type="byte[]" note="" />
<!--<Field name="Verifytokenlength" type="short" note="" />-->
<Field name="Verifytoken" type="byte[]" note="" />
<Comments>
<![CDATA[
Server to client
See Protocol Encryption for information on this packet.
]]>
</Comments>
</Packet>
<Packet name="ServerListPing" id="0xFE">
<Field name="Magic" type="byte" note="always 1" />
<Comments>
<![CDATA[
Client to Server
This packet is used by the multiplayer menu to retrieve MOTD, version, and player counts. For more info see Server List Ping
]]>
</Comments>
</Packet>
<Packet name="DisconnectKick" id="0xFF">
<Field name="Reason" type="string" note="Displayed to the client when the connection terminates" />
<Comments>
<![CDATA[
Two-Way
Sent by the server before it disconnects a client, or by the client before it disconnects from the server. The receiver of this packet assumes that the sender has already closed the connection by the time the packet arrives.
Due to race conditions in the client, a local server may need to pause for a short period after sending this packet before closing the connection. An alternative is simply not to close the connection, and wait for the client to do so on receipt of this packet.
]]>
</Comments>
</Packet>
</Packets>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment