Difference between revisions of "Slot Data"

From wiki.vg
Jump to navigation Jump to search
(add examples)
(→‎Format: We shouldn't call the NBT data "metadata", as people already use that to refer to the damage)
Line 13: Line 13:
 
== Format ==
 
== Format ==
  
The structure consists of at least a short, which gives the item/block ID [http://www.minecraftwiki.net/wiki/Block_ids#Block_IDs_.28Minecraft_Beta.29]. A value of <code>-1</code> signifies that the slot is empty, and no further data follows.
+
The structure consists of at least a short, which gives the item/block ID [http://www.minecraftwiki.net/wiki/Block_ids]. A value of <code>-1</code> signifies that the slot is empty, and no further data follows.
  
If the block ID is not <code>-1</code>, three more fields follow. These fields are a byte (item count), a short (item damage), and another short (length of item metadata).
+
If the block ID is not <code>-1</code>, three more fields follow. These fields are a byte (item count), a short (item damage), and another short (length of optional NBT data).
  
If the short (length of item metadata) is <code>-1</code>, there is no item metadata, and no further data follows. Otherwise, a byte array will follow.
+
If the short (length of NBT data) is <code>-1</code>, there is no NBT data, and no further data follows. Otherwise, a byte array will follow.
  
 
The byte array contains gzipped (that is RFC 1952 rather than RFC 1950) [[NBT]] data. The format of this data is as follows:
 
The byte array contains gzipped (that is RFC 1952 rather than RFC 1950) [[NBT]] data. The format of this data is as follows:

Revision as of 06:16, 16 November 2012

The slot data structure is how minecraft represents an item and its associated data in the minecraft protocol

Packets

Format

The structure consists of at least a short, which gives the item/block ID [1]. A value of -1 signifies that the slot is empty, and no further data follows.

If the block ID is not -1, three more fields follow. These fields are a byte (item count), a short (item damage), and another short (length of optional NBT data).

If the short (length of NBT data) is -1, there is no NBT data, and no further data follows. Otherwise, a byte array will follow.

The byte array contains gzipped (that is RFC 1952 rather than RFC 1950) NBT data. The format of this data is as follows:

 COMPOUND: ''
   LIST: 'ench'
     COMPOUND
       SHORT: 'id'
       SHORT: 'lvl'
     END
     COMPOUND
       ...etc
     END
 END

Each of the inner, untagged COMPOUNDs represents an enchantment, with its ID[2] and level given as child SHORT elements.

Examples

 ff ff                            | empty slot
 01 16 01 00 00 ff ff             | a diamond pickaxe
 01 16 01 00 00 00 04 CA FE BA BE | a diamond pickaxe with (made-up) NBT data