Difference between revisions of "Slot Data"
Barneygale (talk | contribs) (→Enchantable items: bows are enchantable now) |
(Updated to 1.3.1) |
||
| Line 15: | Line 15: | ||
For non-empty slots, at least two further fields follow. These fields are a byte (item count) and a short (damage/block metadata) | For non-empty slots, at least two further fields follow. These fields are a byte (item count) and a short (damage/block metadata) | ||
| − | For | + | For every block ID, except -1, further data follows. First, a short gives the length of a proceeding byte array. A value of <code>-1</code> signifies no further data. |
The byte array (if present) contains gzipped (that is RFC 1952 rather than RFC 1950) [[NBT]] data. The format of this data is as follows: | The byte array (if present) contains gzipped (that is RFC 1952 rather than RFC 1950) [[NBT]] data. The format of this data is as follows: | ||
| Line 33: | Line 33: | ||
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. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Revision as of 00:51, 1 August 2012
The slot data structure is how minecraft represents an item and its associated data in the minecraft protocol
Packets
- 0x0F player block placement
- 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.
For non-empty slots, at least two further fields follow. These fields are a byte (item count) and a short (damage/block metadata)
For every block ID, except -1, further data follows. First, a short gives the length of a proceeding byte array. A value of -1 signifies no further data.
The byte array (if present) 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.
