Difference between revisions of "Slot Data"
Barneygale (talk | contribs) (add examples) |
|||
Line 35: | Line 35: | ||
Each of the inner, untagged COMPOUNDs represents an enchantment, with its ID[http://www.minecraftwiki.net/wiki/Enchantment#Enchantment_Types] and level given as child SHORT elements. | Each of the inner, untagged COMPOUNDs represents an enchantment, with its ID[http://www.minecraftwiki.net/wiki/Enchantment#Enchantment_Types] and level given as child SHORT elements. | ||
+ | |||
+ | == Examples == | ||
+ | |||
+ | <code> | ||
+ | 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 | ||
+ | </code> |
Revision as of 06:10, 16 November 2012
The slot data structure is how minecraft represents an item and its associated data in the minecraft protocol
Packets
- 0x05 Entity Equipment
- 0x0F Player Block Placement
- 0x15 Spawn Dropped Item
- 0x66 Window Click
- 0x67 Set Slot
- 0x68 Window Items (as an array)
- 0x6B Creative Inventory Action
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 item metadata).
If the short (length of item metadata) is -1
, there is no item metadata, 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