View source for Classic Protocol Extension

'''Classic Protocol Extension''' (CPE) is a project to augment the Minecraft Classic network protocol. Extensions are designed to keep custom clients and servers compatible to standard/vanilla clients and servers. Standard clients and extended clients can play on the same server at the same time. Extensions are also designed to be modular: clients and servers can choose to implement any subset of extensions, and only mutually-supported extensions will be used.

{| class="wikitable" style="margin:10px 10%;border: 1px solid #aaa;border-left:10px solid #f28500;background:#fbfbfb;width:80%;font-size:110%"
|style="padding:10px"|'''This specification has not yet been finalized, and is subject to change.'''
Last revision: 1 September 2013
|}

==Support==
These custom servers plan to add support for CPE: [http://www.fcraft.net/ fCraft], [http://femto.fcraft.net/ FemtoCraft], [http://800craft.net/ 800Craft], [https://github.com/GamezGalaxy/GGS/tree/Classic-Extension GGS]

These custom clients plan to add support for CPE: [http://charged-miners.com/ Charged Miners], [http://github.com/Steveice10/OpenClassic/ OpenClassic], [https://github.com/andrewphorn/ClassiCube-Client ClassiCube]

==Negotiation==
[[File:CPE_Negotiation.png|frame|right]]
'''Client behavior''': Extended clients must use magic number of <code>0x42</code> for the padding byte of the [[Classic_Protocol#Client_.E2.86.92_Server_packets|Player Identification packet]]. After the client has sent its identification packet, it must await a response. If server responds with any packet other than '''ExtInfo''', client must assume that the server does not support CPE. If the server responds with an '''ExtInfo''' packet, client must parse it and any '''ExtEntry''' packets that follow. Client must then compare its locally-supported set of extensions with the list of extensions provided by the server, and find an intersection of these sets. These are the mutually-supported extensions. Client must now send '''ExtInfo''' packet of its own, followed by a list of zero or more client-supported extensions. After sending the last of '''ExtEntry''' packets, client should activate all mutually-supported extensions and resume normal login procedure.

'''Server behavior''': All standard/non-extended clients pad this packet with <code>0x00</code>, so extended servers can easily notice extended clients. All standard/non-extended servers will ignore the modified padding byte, preserving compatibility. When the server sees that padding byte is <code>0x42</code>, it must immediately reply with an '''ExtInfo''' packet, followed by zero or more '''ExtEntry''' packets, and await a response ('''ExtInfo''' packet) from the client. Client will respond with one '''ExtInfo''' and zero or more '''ExtEntry''' packets. Server must then compare its locally-supported set of extensions with the list of extensions provided by the client, and find an intersection of these sets. These are the mutually-supported extensions. After receiving the last of '''ExtEntry''' packets, server should activate all mutually-supported extensions and resume normal login procedure.

:<h4>ExtInfo Packet</h4>
:{| class="wikitable"
|- class="row0"
! class="col0" | Packet ID
! class="col1" | Field Name
! class="col2" | Field Type
! class="col3" | Example
! class="col4" | Notes
|- class="row1"
| class="col0 centeralign" rowspan="2" | 0x10
(16)
| class="col1 centeralign" | AppName
| class="col2 centeralign" | string
| class="col3 centeralign" | <code>MyServer</code>
| class="col4" | Client or server software name
|- class="row2"
| class="col0 centeralign" | ExtensionCount
| class="col1 centeralign" | short
| class="col2 centeralign" | 1
| class="col3" | Between 0 and 32767
|- class="row3"
! class="col0" | Total Size:
| class="col1 rightalign" colspan="4" | 67 bytes
|}

:<h4>ExtEntry Packet</h4>
:{| class="wikitable"
|- class="row0"
! class="col0" | Packet ID
! class="col1" | Field Name
! class="col2" | Field Type
! class="col3" | Example
! class="col4" | Notes
|- class="row1"
| class="col0 centeralign" rowspan="2" | 0x11
(17)
| class="col1 centeralign" | ExtName
| class="col2 centeralign" | string
| class="col3 centeralign" | <code>MyExtension</code>
| class="col4" | Name of a supported extension
|- class="row2"
| class="col0 centeralign" | Version
| class="col1 centeralign" | int
| class="col2 centeralign" | 1
| class="col3" | Only extensions with identical version numbers should be considered compatible.
|- class="row3"
! class="col0" | Total Size:
| class="col1 rightalign" colspan="4" | 69 bytes
|}

==Extensions==
===ClickDistance===
:Used to extend or restrict the distance at which client may click blocks, controlled by the server. Click range is given in player-space units (32 units per block). In Minecraft Classic, the default range is 160.
:'''Motivation''': This extension allows trusted players to have a wider or virtually-unlimited reach. It may simplify operation of certain bots. Restricting the reach may allow new games/mini-games.
:'''Client Behavior''': Upon receiving a '''SetClickDistance''' packet, client should immediately apply the change. Distance should persist between worlds/maps.
:'''Server Behavior''': Server should send '''SetClickDistance''' packet when the server connects, or whenever their permitted click distance changes. Server should allow for some margin-of-error (+/- 1 block) when enforcing click distance restrictions.
:<h4>SetClickDistance packet</h4>
:''Server to Client''
:{| class="wikitable"
|- class="row0"
! class="col0" | Packet ID
! class="col1" | Field Name
! class="col2" | Field Type
! class="col3" | Example
! class="col4" | Notes
|- class="row1"
| class="col0 centeralign" | 0x12
(18)
| class="col1 centeralign" | Distance
| class="col2 centeralign" | short
| class="col3 centeralign" | 160
| class="col4" |
|- class="row2"
! class="col0" | Total Size:
| class="col1 rightalign" colspan="4" | 3 bytes
|}

===CustomBlocks===
:Used to add support for custom block types. Custom block IDs start at 50 (0x32). New block types will be added in batches, a few at a time. Both client and server declare which batch they support, and use the lower of the two versions. Claiming to supporting a batch implies fully implementing all the batches that came before it. If either server or client do not support this extension, only the standard 50 block types should be used.
:'''Motivation''': Adding new visually distinct blocks, to enhance Classic players' experience.
:'''Client behavior''': Client must expect a ''CustomBlockSupportLevel'' packet from a compatible server immediately after sending the last ''ExtEntry'' packet. It should then reply with its own ''CustomBlockSupportLevel'' packet, containing its actual support level. Client must then use the lower of the two levels in operation. Client must not send any block types that are not defined by the current support level. Client should expect ''Heartbeat'' packet only AFTER sending its ''CustomBlockSupportLevel'' packet.
:'''Server behavior''': Server must send a ''CustomBlockSupportLevel'' packet to compatible clients immediately after receiving the last ''ExtEntry'' packet from the client. It should then wait to receive a ''CustomBlockSupportLevel'' packet from the client before sending the ''Handshake''. Server must then use the lower of the two levels in operation. If this level is lower than the server's, it has to filter data sent to the client, to make sure that the client never receives any block types that it does not support. Each level will define what substitutions to use.

:<h4>CustomBlockSupportLevel packet</h4>
:''Server to Client''
:{| class="wikitable"
|- class="row0"
! class="col0" | Packet ID
! class="col1" | Field Name
! class="col2" | Field Type
! class="col3" | Example
! class="col4" | Notes
|- class="row1"
| class="col0 centeralign" | 0x13
(19)
| class="col1 centeralign" | SupportLevel
| class="col2 centeralign" | byte
| class="col3 centeralign" | 1
| class="col4" |
|- class="row2"
! class="col0" | Total Size:
| class="col1 rightalign" colspan="4" | 2
|}

:<h4>Blocks in support level 1</h4>
:Client must be able to receive/render all 16 custom blocks to claim support. Server must be able to receive/store all 16 custom blocks to claim support.
:{| class="wikitable"
!Block name
!Block ID
!Fallback name
!Fallback ID
|-
|'''CobblestoneSlab'''
|0x32 (50)
|Slab
|0x2C (44)
|-
|'''Rope'''
|0x33 (51)
|BrownMushroom
|0x27 (39)
|-
|'''Sandstone'''
|0x34 (52)
|Sand
|0x0C (12)
|-
|'''Snow'''
|0x35 (53)
|Air
|0x00 (0)
|-
|'''Fire'''
|0x36 (54)
|Lava
|0x0A (10)
|-
|'''LightPinkWool'''
|0x37 (55)
|Pink
|0x21 (33)
|-
|'''ForestGreenWool'''
|0x38 (56)
|Green
|0x19 (25)
|-
|'''BrownWool'''
|0x39 (57)
|Dirt
|0x03 (3)
|-
|'''DeepBlue'''
|0x3A (58)
|Blue
|0x1d (29)
|-
|'''Turquoise'''
|0x3B (59)
|Cyan
|0x1c (28)
|-
|'''Ice'''
|0x3C (60)
|Glass
|0x14 (20)
|-
|'''CeramicTile'''
|0x3D (61)
|Iron
|0x2a (42)
|-
|'''Magma'''
|0x3E (62)
|Obsidian
|0x31 (49)
|-
|'''Pillar'''
|0x3F (63)
|White
|0x24 (36)
|-
|'''Crate'''
|0x40 (64)
|WoodenPlanks
|0x05 (5)
|-
|'''StoneBrick'''
|0x41 (65)
|Stone
|0x01 (1)
|}

===HeldBlock===
:Provides a way for the client to notify the server about the blocktype that it is currently holding, and for the server to change the currently-held block type.   
:'''Motivation''': This allows server to know which block player is holding, for example for drawing commands, without needing to wait for the player's click. it also allows for features like [http://www.fcraft.net/wiki//Spectate /Spectate] to show what block a spectated player is holding.
:'''Client behavior''': When this extension is mutually supported, client should use the ''Player ID'' field of the [[Classic_Protocol#Client_.E2.86.92_Server_packets|Position and Orientation packet]] (currently unused) to indicate which blocktype the client is currently holding. It should be ready to accept '''HoldThis''' packets to change the block that the player is holding. If <code>0</code> is given for ''BlockToHold'', client should hide the hand/block from the screen, and should not be able to click blocks, until they switch to a different blocktype. If an unrecognized blocktype is given, no action is needed.
:'''Server behavior''': The server can use '''HoldThis''' packet to force the client to hold the desired block type. It should be done sparingly.

:<h4>HoldThis packet</h4>
:''Server to Client''
:{| class="wikitable"
|- class="row0"
! class="col0" | Packet ID
! class="col1" | Field Name
! class="col2" | Field Type
! class="col3" | Example
! class="col4" | Notes
|- class="row1"
| class="col0 centeralign" rowspan="2" | 0x14
(20)
| class="col1 centeralign" | BlockToHold
| class="col2 centeralign" | byte
| class="col3 centeralign" | <code>49</code>
| class="col4" | Standard block type
|- class="row2"
| class="col1 centeralign" | PreventChange
| class="col2 centeralign" | byte
| class="col3 centeralign" | 0
| class="col4" |0 = Allow player to change blocktype
1 = Prevent player from changing blocktype
|- class="row3"
! class="col0" | Total Size:
| class="col1 rightalign" colspan="4" | 2 bytes
|}

===EmoteFix===
:This extension indicates that the client can render [http://fcraft.net/wiki/Emotes emotes] (ASCII control characters) in chat properly, without padding or suffixes that are required for vanilla client. This extension does not define any new packets.
:'''Motivation''': To improve appearance of emotes in chat.
:'''Client behavior''': Client should not emulate vanilla client's quirks.
:'''Server behavior''': Server should not pad or suffix emotes in chat.

===TextHotKey===
:This extension allows the server to define "hotkeys" for certain commands.
:'''Motivation''': To speed up and simplify access to commonly-used commands and command macros by providing server-defined client-side hotkeys.
:'''Client behavior:''' Client should not try to persist previously-defined hotkeys between sessions. When a defined hotkey is activated by the user, client should open up a text prompt and type in contents of the ''Action'' field. A newline character (<code>\n</code>) in the ''Action'' field indicates that whatever is currently typed-in should be sent to the server. If ''Action'' does not end with a newline, text prompt should be left open, for the user to complete. Client may provide a way for the user to see a list of currently-defined hotkeys, and a way to notify the user when a hotkey was activated.
:'''Server behavior:''' The server should send a definition of each hotkey ('''SetTextHotKey''' packet) once per connection.

:<h4>SetTextHotKey packet</h4>
:''Server to Client''
:{| class="wikitable"
|- class="row0"
! class="col0" | Packet ID
! class="col1" | Field Name
! class="col2" | Field Type
! class="col3" | Example
! class="col4" | Notes
|- class="row1"
| class="col0 centeralign" rowspan="4" | 0x15
(21)
| class="col1 centeralign" | Label
| class="col2 centeralign" | string
| class="col3 centeralign" | <code>Copy</code>
| class="col4" | Readable name of the hotkey
|- class="row2"
| class="col1 centeralign" | Action
| class="col2 centeralign" | string
| class="col3 centeralign" | <code>/Copy </code>
| class="col4" | Text to type in
|- class="row2"
| class="col1 centeralign" | KeyCode
| class="col2 centeralign" | int
| class="col3 centeralign" | <code>113</code>
| class="col4" | [http://www.minecraftwiki.net/wiki/Key_Codes LWJGL keycode] of the key
|- class="row3"
| class="col1 centeralign" | KeyMods
| class="col2 centeralign" | byte
| class="col3 centeralign" | <code>0</code>
| class="col4" | Key modifier [http://en.wikipedia.org/wiki/Flag_word flags], may be combined:
* 0 = None
* 1 = Ctrl
* 2 = Shift
* 4 = Alt
|- class="row4"
! class="col0" | Total Size:
| class="col1 rightalign" colspan="4" | 134 bytes
|}

===ExtPlayerList===
:'''Motivation''': Provides more flexibility in naming of players and loading of skins, autocompletion, and player tab-list display. Separates tracking of in-game entities (spawned player models) and names on the player list. ExtAddPlayerName/ExtRemovePlayerName packets take over managing the player names list (tab-list), and ExtAddEntity/DespawnPlayer packets are used only to manage in-game entities.

:<h4>Client Behavior</h4>
:When '''ExtAddPlayerName''' packet is received for an unrecognized ''NameID'', a new entry must be added to the autocompletion list and tab-list. When receiving '''ExtAddPlayerName''' packet for an already-listed ''NameID'', client must update its ''ListName'', ''GroupName'', and ''GroupRank''. Name list must persist when client changes worlds/maps.

:Names on the tab-list should be grouped by ''GroupName'' in the player tab-list. Names within a ''GroupName'' should be sorted by ''GroupRank'' (in ascending order). Names with the same ''GroupName'' and ''GroupRank'' should be sorted alphabetically by ''ListName''.

:When an '''ExtAddEntity''' packet is received, it must be treated as the '''[[Classic_Protocol#Server_.E2.86.92_Client_packets|SpawnPlayer]]''' packet. ''InGameName'' should be shown above the player's heads in-game. Skin should be loaded using the given ''SkinName'' for a player name. When client receives '''ExtAddEntity''' packet for an already-spawned player, a duplicate entity must not be spawned and existing entity's position should not be changed. Instead their ''InGameName'' and ''SkinName'' should be updated. If a negative ID is given for '''ExtAddEntity''', client must update player's own spawn point, ''InGameName'', and ''SkinName''. The client must ignore regular '''[[Classic_Protocol#Server_.E2.86.92_Client_packets|SpawnPlayer]]''' packets, if any are received. Name list should not be affected by '''ExtAddEntity'''.

:Color codes may be either drawn or stripped from ''ListName'', ''GroupName'', and ''InGameName''.

:When a standard '''[[Classic_Protocol#Server_.E2.86.92_Client_packets|DespawnPlayer]]''' packet is received for a recognized ''EntityID'', player model should be removed from a world. Name list should not be affected by '''[[Classic_Protocol#Server_.E2.86.92_Client_packets|DespawnPlayer]]'''.

:When '''ExtRemovePlayerName''' packet is received for a recognized ''NameID'', they should be removed from autocompletion list and tab-list. When '''[[Classic_Protocol#Server_.E2.86.92_Client_packets|DespawnPlayer]]''' or '''ExtRemovePlayerName''' packet is received for a negative or unrecognized ''PlayerID'', no action should be taken.

:<h4>Server Behavior</h4>
:When a new player connects to the server, '''ExtAddPlayerName''' must be sent. ''GroupName'' and ''GroupRank'' can be used in any way, for example to group players by map/world or rank/class/faction. Server must use '''ExtAddEntity''' in place of standard '''SpawnPlayer''' packet. Server should re-send '''ExtAddPlayerName''' packet, using the identical ''PlayerID'', when player's ''ListName'', ''GroupName'', or ''GroupRank'' change. Server must reliably send an '''ExtRemovePlayerName''' when the player disconnects. Color codes are permitted in ''ListName'', ''GroupName'', and ''InGameName''.

:<h4>ExtAddPlayerName Packet</h4>
:''Server to Client''
:{| class="wikitable"
|- class="row0"
! class="col0" | Packet ID
! class="col1" | Field Name
! class="col2" | Field Type
! class="col3" | Example
! class="col4" | Notes
|- class="row1"
| class="col0 centeralign" rowspan="5" | 0x16
(22)
| class="col1 centeralign" | NameID
| class="col2 centeralign" | short
| class="col3 centeralign" | <code>5</code>
| class="col4" | Between 0 and 255
|- class="row2"
| class="col1 centeralign" | PlayerName
| class="col2 centeralign" | string
| class="col3 centeralign" | <code>Notch</code>
| class="col4" | Player name used for autocompletion.
May be left empty (exclude from autocompletion).
|- class="row3"
| class="col1 centeralign" | ListName
| class="col2 centeralign" | string
| class="col3 centeralign" | <code>&c[Op]Notch</code>
| class="col4" |Name displayed in the in-game list.
|- class="row4"
| class="col1 centeralign" | GroupName
| class="col2 centeralign" | string
| class="col3 centeralign" | <code>Staff</code>
| class="col4" |
|- class="row5"
| class="col1 centeralign" | GroupRank
| class="col2 centeralign" | byte
| class="col3 centeralign" | <code>0</code>
| class="col4" | Rank of a player within the group.
A lower number means higher rank.
|- class="row6"
! class="col0" | Total Size:
| class="col1 rightalign" colspan="4" | 196 bytes
|}

:<h4>ExtAddEntity Packet</h4>
:''Server to Client''
:{| class="wikitable"
|- class="row0"
! class="col0" | Packet ID
! class="col1" | Field Name
! class="col2" | Field Type
! class="col3" | Example
! class="col4" | Notes
|- class="row1"
| class="col0 centeralign" rowspan="3" | 0x17
(23)
| class="col1 centeralign" | EntityID
| class="col2 centeralign" | byte
| class="col3 centeralign" | <code>5</code>
| class="col4" | Between 0 and 127
|- class="row2"
| class="col1 centeralign" | InGameName
| class="col2 centeralign" | string
| class="col3 centeralign" | <code>&cNotch</code>
| class="col4" | Player name to be shown in-game, hovering above player model.
|- class="row3"
| class="col1 centeralign" | SkinName
| class="col2 centeralign" | string
| class="col3 centeralign" | <code>Notch</code>
| class="col4" | Player name whose skin should be used by the client.
|- class="row4"
! class="col0" | Total Size:
| class="col1 rightalign" colspan="4" | 130 bytes

|}

:<h4>ExtRemovePlayerName Packet</h4>
:''Server to Client''
:{| class="wikitable"
|- class="row0"
! class="col0" | Packet ID
! class="col1" | Field Name
! class="col2" | Field Type
! class="col3" | Example
! class="col4" | Notes
|- class="row1"
| class="col0 centeralign" | 0x18
(24)
| class="col1 centeralign" | NameID
| class="col2 centeralign" | short
| class="col3 centeralign" | <code>5</code>
| class="col4" | Between 0 and 255
Matches NameID of the ExtAddPlayerName packet
|- class="row2"
! class="col0" | Total Size:
| class="col1 rightalign" colspan="4" | 3 bytes
|}

===EnvColors===
:This extension allows server to alter some of the colors used by the client in environment rendering.
:'''Motivation''': To allow the server to give worlds/maps a unique feel: time-of-day, weather/climate, lighting effect, etc.
:'''Client behavior''': Client must check for '''EnvSetColor''' packets right before [[Classic_Protocol#Server_.E2.86.92_Client_packets|Level Finalize]] packet, and apply these changes before the map is displayed. Client should be able to ''read'' this packet at other times, but it is not required to then ''apply'' the changes immediately. If an unrecognized or unsupported ''Variable'' field is given, no action is needed.
:'''Server behavior''': Server should normally only use '''EnvSetColor''' packets right before the Level Finalize packet.

:<h4>EnvSetColor Packet</h4>
:''Server to Client''
:{| class="wikitable"
|- class="row0"
! class="col0" | Packet ID
! class="col1" | Field Name
! class="col2" | Field Type
! class="col3" | Example
! class="col4" | Notes
|- class="row1"
| class="col0 centeralign" rowspan="4" | 0x19
(25)
| class="col1 centeralign" | Variable
| class="col2 centeralign" | byte
| class="col3 centeralign" | <code>1</code>
| class="col4" | Enumeration of environmental variables
*0 = sky color
*1 = cloud color
*2 = fog color
*3 = ambient light (blocks in shadow) color
*4 = diffuse light (sunlight) color
|- class="row2"
| class="col1 centeralign" | Red
| class="col2 centeralign" | unsigned byte
| class="col3 centeralign" | <code>0xF9</code>
| class="col4" |
|- class="row3"
| class="col1 centeralign" | Green
| class="col2 centeralign" | unsigned byte
| class="col3 centeralign" | <code>0x3C</code>
| class="col4" |
|- class="row4"
| class="col1 centeralign" | Blue
| class="col2 centeralign" | unsigned byte
| class="col3 centeralign" | <code>0x50</code>
| class="col4" |
|- class="row5"
! class="col0" | Total Size:
| class="col1 rightalign" colspan="4" | 5 bytes
|}

===SelectionCuboid===
:
:'''Motivation''': Allows the server to highlight parts of a world. Applications include zoning, previewing draw command size, previewing undo commands.
:'''Client behavior''':
:'''Server behavior''':

:<h4>MakeSelection packet</h4>
:''Server to Client''
:{| class="wikitable"
|- class="row0"
! class="col0" | Packet ID
! class="col1" | Field Name
! class="col2" | Field Type
! class="col3" | Example
! class="col4" | Notes
|- class="row1"
| class="col0 centeralign" rowspan="12" | 0x20
(26)
| class="col1 centeralign" | SelectionID
| class="col2 centeralign" | byte
| class="col3 centeralign" | <code>0</code>
| class="col4" | Numeric ID of the selection
|- class="row2"
| class="col1 centeralign" | Label
| class="col2 centeralign" | string
| class="col3 centeralign" | <code>SomeZone</code>
| class="col4" | Text label associated with the selection
|- class="row3"
| class="col1 centeralign" | StartX
| class="col2 centeralign" | short
| class="col3 centeralign" | <code>1</code>
| class="col4" | X coordinate of the starting point
|- class="row4"
| class="col1 centeralign" | StartY
| class="col2 centeralign" | short
| class="col3 centeralign" | <code>2</code>
| class="col4" | Y coordinate of the starting point
|- class="row5"
| class="col1 centeralign" | StartZ
| class="col2 centeralign" | short
| class="col3 centeralign" | <code>3</code>
| class="col4" | Z coordinate of the starting point
|- class="row6"
| class="col1 centeralign" | EndX
| class="col2 centeralign" | short
| class="col3 centeralign" | <code>5</code>
| class="col4" | X coordinate of the ending point
|- class="row7"
| class="col1 centeralign" | EndY
| class="col2 centeralign" | short
| class="col3 centeralign" | <code>6</code>
| class="col4" | Y coordinate of the ending point
|- class="row8"
| class="col1 centeralign" | EndZ
| class="col2 centeralign" | short
| class="col3 centeralign" | <code>7</code>
| class="col4" | Z coordinate of the ending point
|- class="row9"
| class="col1 centeralign" | Red
| class="col2 centeralign" | unsigned byte
| class="col3 centeralign" | <code>0xF9</code>
| class="col4" |
|- class="row10"
| class="col1 centeralign" | Green
| class="col2 centeralign" | unsigned byte
| class="col3 centeralign" | <code>0x3C</code>
| class="col4" |
|- class="row11"
| class="col1 centeralign" | Blue
| class="col2 centeralign" | unsigned byte
| class="col3 centeralign" | <code>0x50</code>
| class="col4" |
|- class="row12"
| class="col1 centeralign" | Opacity
| class="col2 centeralign" | unsigned byte
| class="col3 centeralign" | <code>0xFF</code>
| class="col4" | 0x00 = fully transparent
0xFF = fully opaque
|- class="row4"
! class="col0" | Total Size:
| class="col1 rightalign" colspan="4" | 82 bytes
|}

:<h4>RemoveSelection packet</h4>
:''Server to Client''
:{| class="wikitable"
|- class="row0"
! class="col0" | Packet ID
! class="col1" | Field Name
! class="col2" | Field Type
! class="col3" | Example
! class="col4" | Notes
|- class="row1"
| class="col0 centeralign" | 0x21
(27)
| class="col1 centeralign" | SelectionID
| class="col2 centeralign" | byte
| class="col3 centeralign" | <code>0</code>
| class="col4" |
|- class="row2"
! class="col0" | Total Size:
| class="col1 rightalign" colspan="4" | 2 bytes
|}

===BlockPermissions===
:This extension allows the server to instruct the player that certain block types are allowed/disallowed to be placed or deleted.
:'''Motivation''': To prevent players from inadvertently placing or removing prohibited block types (e.g. water, lava, grass, admincrete), before it even reaches the server.
:'''Client behavior:''' Client should prevent placement of prohibited block types (by graying out or hiding blocks in block-selection screen, or any other effective means). Client should prevent player from deleting prohibited block types. Client must be ready to receive ''SetBlockPermission'' packet after map load (''MapEnd'' packet). Permission changes should take effect as soon as packet is received. Admincrete (solid block) permissions set by ''SetBlockPermission'' must always override permission set by ''Handshake'' packet. If BlockType is set to 0, given permissions should affect ALL block types at once, overriding permissions set by any earlier packets. Permissions must persist between map changes. Client may optionally warn the player attempting to place/delete prohibited blocks via sound effect, visual effect, chat message, etc. 
:'''Server behavior:''' Server may send ''SetBlockPermission'' packets any time after map load (''MapEnd'' packet). Any block type may be specified, including custom blocks (if ''CustomBlocks'' is mutually supported). Server must not assume that client is compliant/obedient, and server must still verify each ''SetBlock'' packet coming from the client. What to do with non-complying clients (kick or warn) is up to you.

:<h4>SetBlockPermission packet</h4>
:''Server to Client''
:{| class="wikitable"
|- class="row0"
! class="col0" | Packet ID
! class="col1" | Field Name
! class="col2" | Field Type
! class="col3" | Example
! class="col4" | Notes
|- class="row1"
| class="col0 centeralign" rowspan="4" | 0x22
(28)
| class="col1 centeralign" | BlockType
| class="col2 centeralign" | byte
| class="col3 centeralign" | <code>8</code>
| class="col4" | Block's numeric ID (anything between 1 and max defined block).
|- class="row2"
| class="col1 centeralign" | AllowPlacement
| class="col2 centeralign" | byte
| class="col3 centeralign" | <code>0</code>
| class="col4" | 0 = Prohibited
1 = Allowed
|- class="row2"
| class="col1 centeralign" | AllowDeletion
| class="col2 centeralign" | int
| class="col3 centeralign" | <code>0</code>
| class="col4" | 0 = Prohibited
1 = Allowed
|- class="row4"
! class="col0" | Total Size:
| class="col1 rightalign" colspan="4" | 4 bytes
|}

===OnScreenMenu===
:TODO