Difference between revisions of "Classic Protocol Extension/Proposals"
m (→PlayerClick) |
m (fix typo) |
||
(137 intermediate revisions by 16 users not shown) | |||
Line 120: | Line 120: | ||
|} | |} | ||
− | === | + | ===ColorCodeControl=== |
− | :Proposed by | + | :Proposed by [[User:F|F]] ([[User talk:F|talk]]) 22:00, 28 August 2014 (UTC) |
− | : | + | :Gives servers an option to allow players to type in color codes, and a way to render <code>&</code> character in chat. |
− | :''' | + | :'''Motivation''': Allow players to type in color codes and to use & in chat. |
− | :'''Client Behavior''': | + | :'''Client Behavior''': When this extension is mutually supported, treat character sequence <code>&&</code> as meaning "draw an <code>&</code> character", without modifying current color. Do not allow <code>&</code> to be typed or pasted into chat unless '''''ColorCodeControl''''' packet has been received with ''AllowColorCodes'' set to <code>1</code>. |
− | :'''Server Behavior''': Server should be | + | :'''Server Behavior''': When this extension is mutually supported, server may send '''''ColorCodeControl''''' packet to allow client to type or paste color codes. Server should treat <code>&&</code> as described above. |
− | <h4> | + | <h4>ColorCodeControl packet</h4> |
− | :''Client to Server'' | + | :''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" | ?? | ||
+ | | class="col1 centeralign" | AllowColorCodes | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | 0 | ||
+ | | class="col4 centeralign" | 0 = disallow | ||
+ | 1 = allow | ||
+ | |- class="row2" | ||
+ | ! class="col0" | Total Size: | ||
+ | | class="col1 rightalign" colspan="4" | 2 bytes | ||
+ | |} | ||
+ | ===UnicodeChat=== | ||
+ | :Proposed by [[User:F|F]] ([[User talk:F|talk]]) 22:48, 28 August 2014 (UTC) | ||
+ | :Expands character encoding beyond ASCII. There are three ways to go about this: | ||
+ | :# Expand charset to 256 characters using '''[http://en.wikipedia.org/wiki/Windows-1252 Win-1252]'''. | ||
+ | :#* <span style="color:#060">'''Pro'''</span>: Easiest to implement in clients (few changes to FontRenderer needed) and servers (no multibyte character support needed). | ||
+ | :#* <span style="color:#060">'''Pro'''</span>: No new packets needed. | ||
+ | :#* <span style="color:#060">'''Pro'''</span>: Easy to create custom fonts. | ||
+ | :#* <span style="color:#060">'''Pro'''</span>: Easy for servers to maintain compatibility with legacy clients, since only 128 characters need to be remapped, most of which have decent ASCII matches. | ||
+ | :#* <span style="color:#060">'''Pro'''</span>: Low resource use (low RAM and VRAM use, no additional CPU use, small font file). | ||
+ | :#* <span style="color:#c00">'''Con'''</span>: Still only 256 characters. Only covers Latin-derived (English and Western/Central European) languages and common symbols. | ||
+ | :# Expand charset to Unicode [http://en.wikipedia.org/wiki/Basic_Multilingual_Plane#Basic_Multilingual_Plane Basic Multilingual Plane] (BMP) with '''UCS-2''' fixed-length encoding. | ||
+ | :#* <span style="color:#060">'''Pro'''</span>: Lots of characters (~65k) covering most languages and symbols. | ||
+ | :#* <span style="color:#060">'''Pro'''</span>: Not too hard to implement (characters still fixed-width, native support in WinAPI / Java / C#). | ||
+ | :#* <span style="color:#060">'''Pro'''</span>: Free fonts available that covers all characters. | ||
+ | :#* <span style="color:#c00">'''Con'''</span>: New renderer (possibly third-party library) needed for rendering. | ||
+ | :#* <span style="color:#c00">'''Con'''</span>: Higher resource use (higher RAM and VRAM use, more CPU use, large font file). | ||
+ | :#* <span style="color:#c00">'''Con'''</span>: Very hard to create custom fonts. | ||
+ | :#* <span style="color:#c00">'''Con'''</span>: Still does not cover all characters. | ||
+ | :#* <span style="color:#c00">'''Con'''</span>: Hard for servers to maintain compatibility with legacy clients. | ||
+ | :#* <span style="color:#c00">'''Con'''</span>: Always uses 2 bytes per character for transmission (twice as much as ASCII/CP-1252). | ||
+ | :# Expand charset to Unicode [http://en.wikipedia.org/wiki/Basic_Multilingual_Plane#Basic_Multilingual_Plane Basic Multilingual Plane] (BMP) with '''UTF-8''' variable-length encoding. | ||
+ | :#* <span style="color:#060">'''Pro'''</span>: Lots of characters (~65k) covering most languages and symbols. | ||
+ | :#* <span style="color:#060">'''Pro'''</span>: Not too hard to implement (characters can be freely converted to/from UCS-2, which is natively support in WinAPI / C#). | ||
+ | :#* <span style="color:#060">'''Pro'''</span>: Free fonts available that covers all characters. | ||
+ | :#* <span style="color:#060">'''Pro'''</span>: Uses 1 byte per character for transmission, most of the time. | ||
+ | :#* <span style="color:#c00">'''Con'''</span>: New renderer (possibly third-party library) needed for rendering. | ||
+ | :#* <span style="color:#c00">'''Con'''</span>: Higher resource use (higher RAM and VRAM use, more CPU use, large font file). | ||
+ | :#* <span style="color:#c00">'''Con'''</span>: Hard to create custom fonts (unless some fallback rules are implemented). | ||
+ | :#* <span style="color:#c00">'''Con'''</span>: Still does not cover all characters. | ||
+ | :#* <span style="color:#c00">'''Con'''</span>: Hard for servers to maintain compatibility with legacy clients. | ||
+ | :# Expand charset to full Unicode with '''UTF-8''' variable-length encoding. Includes all the supplemental Unicode planes. | ||
+ | :#* <span style="color:#060">'''Pro'''</span>: Widely used in other software. | ||
+ | :#* <span style="color:#060">'''Pro'''</span>: Theoretically covers all languages and symbols. | ||
+ | :#* <span style="color:#060">'''Pro'''</span>: Uses 1 byte per character for transmission, most of the time. | ||
+ | :#* <span style="color:#c00">'''Con'''</span>: Does not ''actually'' cover all languages and symbols due to non-existence of 100% fonts. | ||
+ | :#* <span style="color:#c00">'''Con'''</span>: Hard to find free fonts that extend beyond the BMP. | ||
+ | :#* <span style="color:#c00">'''Con'''</span>: Harder to work with strings (due to variable-width characters). | ||
+ | :#* <span style="color:#c00">'''Con'''</span>: Third-party library needed for rendering. | ||
+ | :#* <span style="color:#c00">'''Con'''</span>: Highest resource use (highest RAM and VRAM use, most CPU use, largest font files). | ||
+ | :#* <span style="color:#c00">'''Con'''</span>: Hardest to implement (no native support in WinAPI / C#). | ||
+ | :#* <span style="color:#c00">'''Con'''</span>: Hard to create custom fonts (unless some fallback rules are implemented). | ||
+ | :#* <span style="color:#c00">'''Con'''</span>: Hard for servers to maintain compatibility with legacy clients. | ||
+ | |||
+ | ===SelectionCuboid v2=== | ||
+ | :Proposed by FabTheZen, classic1234 and Rayne | ||
+ | :'''Motivation''': Allows the server to not only highlight parts of a world, but also determine whether those regions are walk through or not. This could be used to disallow players to walk inside restricted areas or zones which they are not allowed to build in. It could also be used as a jail when accompanied with the '-hax' option. | ||
+ | :'''Client behavior''': The client must receive the SelectionCuboid extension with version 2. It must also determine whether any selections on the map walk through or not. | ||
+ | :'''Server behavior''': The server behaves the same way SelectionCuboid v1 does. | ||
+ | |||
+ | :<h4>MakeSelection packet v2</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="13" |0x?? | ||
+ | (??) | ||
+ | | class="col1 centeralign" | SelectionID | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>0</code> | ||
+ | | class="col4" | Numeric ID of the selection. Between 0 and 127. | ||
+ | |- 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" | short | ||
+ | | class="col3 centeralign" | <code>255</code> | ||
+ | | class="col4" |Between 0 and 255. | ||
+ | |- class="row10" | ||
+ | | class="col1 centeralign" | Green | ||
+ | | class="col2 centeralign" | short | ||
+ | | class="col3 centeralign" | <code>34</code> | ||
+ | | class="col4" |Between 0 and 255. | ||
+ | |- class="row11" | ||
+ | | class="col1 centeralign" | Blue | ||
+ | | class="col2 centeralign" | short | ||
+ | | class="col3 centeralign" | <code>128</code> | ||
+ | | class="col4" |Between 0 and 255. | ||
+ | |- class="row12" | ||
+ | | class="col1 centeralign" | Opacity | ||
+ | | class="col2 centeralign" | short | ||
+ | | class="col3 centeralign" | <code>255</code> | ||
+ | | class="col4" | 0 = fully transparent | ||
+ | 255 = fully opaque | ||
+ | |- class="row13" | ||
+ | | class="col1 centeralign" | Walkthrough | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>0</code> | ||
+ | | class="col4" | 0 = Not walkthrough | ||
+ | 1 = Walkthrough | ||
+ | |- class="row4" | ||
+ | ! class="col0" | Total Size: | ||
+ | | class="col1 rightalign" colspan="4" | 87 bytes | ||
+ | |} | ||
+ | |||
+ | ===Player Animation=== | ||
+ | :Proposed by ByteBit | ||
+ | :Let the player to do certain actions/animations on the client | ||
+ | :'''Motivation''': Other players will be able to see the block another is holding or whether one placed a block or not. It makes the game's feel more realistic, because blocks don't pop out a no where. | ||
+ | :'''Client Behavior''': On recieve the client should perform the actions required for the animation. | ||
+ | :'''Server Behavior''': The server may send the packet if needed any time after the map is send. | ||
+ | <h4>AnimatePlayer 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" | 0xAC | ||
+ | (172) | ||
+ | | class="col1 centeralign" | Animation Type | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | 1 | ||
+ | | class="col4 centeralign" | Specifies what animation to perform (0: Hold block; 1: Set block; 2: Destroy block; 3: Player name visibility) | ||
+ | |- class="row2" | ||
+ | | class="col1 centeralign" | Player ID | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | 1 | ||
+ | | class="col4 centeralign" | What player to perform this animation on | ||
+ | |- class="row3" | ||
+ | | class="col1 centeralign" | Additional byte | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | 49 (Obsidian) | ||
+ | | class="col4 centeralign" | Needed for specific animations (Block type for 0,1 and 2; for 3: true(1)/false(0)) | ||
+ | |- class="row3" | ||
+ | ! class="col0" | Total Size: | ||
+ | | class="col1 rightalign" colspan="4" | 3 bytes | ||
+ | |} | ||
+ | |||
+ | ===PlayerHealth=== | ||
+ | :Proposed by [[User:Apotter96|Apotter96]] ([[User talk:Apotter96|talk]]) 02:29, 26 July 2015 (UTC)alex96 | ||
+ | :Gives players life count that is controlled by the server and reflected by the client at the top left of the game screen. The server. | ||
+ | :'''Motivation''': RPG and Gun games can go more extensive if they wish with lives. | ||
+ | :'''Client Behavior''': Display player's lives at the top left of screen when the server sends the packet. On player connect, the server needs to tell the client the max amount of lives the player can have, in between 5 and 20. May also dictate how many lives the server is allowed to send. Both need to check with the other end so they can comply together. | ||
+ | :'''Server Behavior''': At any time the server can send the packet telling the client the amount of lives the player has. Once a player connects, the server needs to tell the client how many lives the player is allowed to have, in between 5 and 20. Both need to check with the other end so they can comply together. | ||
+ | :<h4>UpdateLives 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" | 0x?? | ||
+ | (??) | ||
+ | | class="col1 centeralign" | Lives | ||
+ | | class="col2 centeralign" | int | ||
+ | | class="col3 centeralign" | 15 | ||
+ | | class="col4 centeralign" | How many lives the player has | ||
+ | |- class="row2" | ||
+ | | class="col1 centeralign" | MaxLives | ||
+ | | class="col2 centeralign" | int | ||
+ | | class="col3 centeralign" | 15 | ||
+ | | class="col4 centeralign" | The Max amount of lives | ||
+ | |- class="row3" | ||
+ | ! class="col0" | Total Size: | ||
+ | | class="col1 rightalign" colspan="4" | 2 bytes | ||
+ | |} | ||
+ | :<h4>UpdateLives packet</h4> | ||
+ | :''Client to server'' | ||
+ | :{| 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" | 0x?? | ||
+ | (??) | ||
+ | | class="col1 centeralign" | MaxLives | ||
+ | | class="col2 centeralign" | int | ||
+ | | class="col3 centeralign" | 15 | ||
+ | | class="col4 centeralign" | The Max amount of lives | ||
+ | |- class="row2" | ||
+ | ! class="col0" | Total Size: | ||
+ | | class="col1 rightalign" colspan="4" | 2 bytes | ||
+ | |} | ||
+ | :(Comments go here, please sign them) | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ===ExtPlayerList v3=== | ||
+ | :Proposed by Cheesse | ||
+ | :This extension builds upon the current version and adds the ability to change the visibility of name tags. | ||
+ | :'''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 '''''ExtAddEntity3'''''/'''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|DespawnPlayer]]''''' packets are used only to manage in-game entities.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 '''''ExtAddEntity3'''''/'''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|DespawnPlayer]]''''' packets are used only to manage in-game entities. | ||
+ | :'''Client Behavior''': When '''''ExtAddPlayerName''''' packet is received for an unused ''NameID'', a new name must be added to the player-name list. When receiving '''''ExtAddPlayerName''''' packet for an already-listed ''NameID'', client must update its ''ListName'', ''GroupName'', and ''GroupRank''. Names on the player-name list should be grouped by ''GroupName'' in the player-name 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''. Color codes may be either drawn or stripped from ''ListName'', ''GroupName'', and ''InGameName''. Player-name list must persist when client changes worlds/maps. | ||
+ | |||
+ | :When an '''''ExtAddEntity3''''' packet is received, it must be treated as the '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|SpawnPlayer]]''''' packet. A player model must be spawned in-game at the given location, with ''InGameName'' text drawn above it. Skin should be loaded using the given ''SkinName'' for a player name. If ''SkinName'' appears to be a player name, skin should be downloaded from the default skin server. If ''SkinName'' appears to be a full URL to a PNG image (starts with <code>http://</code> or <code>https://</code> and ends with <code>.png</code>) then skin should be downloaded from that URL. If image is correctly sized/proportioned to use as a skin for the current model, it should be used. If a blank or unrecognized value is given for ''SkinName'', or if given image could not be downloaded or used, then the default skin should be used. The client must also set the visibility according to ''NameVisibility'' and the collision ability of the entity according to ''CanCollide''. When client receives '''''ExtAddEntity3''''' packet for an already-spawned player, a duplicate entity must not be spawned and existing entity's position must not be changed. Instead their ''InGameName'', ''SkinName'', ''NameVisibility'', and ''CanCollide'' attributes must be updated. If a negative ''EntityID'' is given for '''''ExtAddEntity3''''', client must update player's own spawn point, ''InGameName'', and ''SkinName''. If any undefined value is given in the ''NameVisibility'' or ''CanCollide'' fields, the client should ignore these fields. The client must ignore regular '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|SpawnPlayer]]''''' packets, if any are received. | ||
+ | |||
+ | :When a standard '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|DespawnPlayer]]''''' packet is received for a recognized ''EntityID'', player model must be removed from a world. When '''''ExtRemovePlayerName''''' packet is received for a recognized ''NameID'', their name must be removed from player-name list. Packets with out-of-range or unrecognized ''NameID''s must be ignored. | ||
+ | |||
+ | :In-game entities must never be affected by '''''ExtAddPlayerName''''' or '''''ExtRemovePlayerName''''' packets. Player name list must never be affected by '''''ExtAddEntity3''''' or '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|DespawnPlayer]]''''' packets. | ||
+ | :'''Server Behavior''': Unique ''NameID'' between 0 and 255 should be assigned to every online player or every player on a map for each map. When a new player connects to the server or joins a new map, '''''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 '''''ExtAddEntity3''''' in place of standard '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|SpawnPlayer]]''''' packet. Server should re-send '''''ExtAddPlayerName''''' packet, using the identical ''NameID'', when player's ''ListName'', ''GroupName'', or ''GroupRank'' change. Server must reliably send an '''''ExtRemovePlayerName''''' packet when the player disconnects. Color codes are permitted in ''ListName'', ''GroupName'', and ''InGameName''. | ||
+ | |||
+ | :''This extension only replaces the ExtAddEntity2 packet of the ExtPlayerList extension version 2. Thus, only the ExtAddEntity3 packet is shown here.'' | ||
+ | :<h4>ExtAddEntity3 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="11" | 0x?? | ||
+ | (??) | ||
+ | | class="col1 centeralign" | EntityID | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>5</code> | ||
+ | | class="col4 centeralign" | Between 0 and 127 | ||
+ | |- class="row2" | ||
+ | | class="col1 centeralign" | InGameName | ||
+ | | class="col2 centeralign" | string | ||
+ | | class="col3 centeralign" | <code>&cNotch</code> | ||
+ | | class="col4 centeralign" | Player name to be shown in-game hovering above the player. | ||
+ | |- class="row3" | ||
+ | | class="col1 centeralign" | SkinName | ||
+ | | class="col2 centeralign" | string | ||
+ | | class="col3 centeralign" | <code>Notch</code> | ||
+ | | class="col4 centeralign" | Name of the skin that should be used by the client. Could also be a URL to a PNG image. | ||
+ | |- class="row4" | ||
+ | | class="col1 centeralign" | SpawnX | ||
+ | | class="col2 centeralign" | short | ||
+ | | class="col3 centeralign" | <code>1</code> | ||
+ | | class="col4 centeralign" | X coordinate (32 units per block) of entity's spawn location. | ||
+ | |- class="row5" | ||
+ | | class="col1 centeralign" | SpawnY | ||
+ | | class="col2 centeralign" | short | ||
+ | | class="col3 centeralign" | <code>2</code> | ||
+ | | class="col4 centeralign" | Y coordinate (32 units per block) of entity's spawn location. | ||
+ | |- class="row6" | ||
+ | | class="col1 centeralign" | SpawnZ | ||
+ | | class="col2 centeralign" | short | ||
+ | | class="col3 centeralign" | <code>3</code> | ||
+ | | class="col4" | Z coordinate (32 units per block) of entity's spawn location. | ||
+ | |- class="row7" | ||
+ | | class="col1 centeralign" | SpawnYaw | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>4</code> | ||
+ | | class="col4 centeralign" | Orientation (left-right) at the entity's spawn location. | ||
+ | |- class="row8" | ||
+ | | class="col1 centeralign" | SpawnPitch | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>5</code> | ||
+ | | class="col4" | Orientation (up-down) at the entity's spawn location. | ||
+ | |- class="row9" | ||
+ | | class="col1 centeralign" | NameVisibility | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>6</code> | ||
+ | | class="col4 centeralign" | Visibility of the InGameName of the entity. Obstacles can be blocks or other entities. | ||
+ | *0 = (Default) Visible only by hovering the cursor over the entity within view. Ignores any obstacles in the way. | ||
+ | *1 = Visible only by hovering the cursor over the entity within view. Invisible when obstacles block the entity. | ||
+ | *2 = Always visible within view (name tag shrinks over distance). Ignores any obstacles in the way. | ||
+ | *3 = Always visible within view (name tag shrinks over distance). Invisible when obstacles block the entity. | ||
+ | *4 = Always visible anywhere (name tag does not shrink over distance). Ignores any obstacles in the way. | ||
+ | *5 = Always visible anywhere (name tag does not shrink over distance). Invisible when obstacles block the entity. | ||
+ | *6 = Never visible. | ||
+ | |- class="row10" | ||
+ | | class="col1 centeralign" | CanCollide | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>0</code> | ||
+ | | class="col4 centeralign" | | ||
+ | *0 = (default) Can collide with the player. | ||
+ | *1 = Cannot collide with the player. | ||
+ | |- class="row11" | ||
+ | | class="col1 centeralign" | Opacity | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>255</code> | ||
+ | | class="col4 centeralign" | From 0-255, the overall opacity of the entity model. | ||
+ | |- class="row12" | ||
+ | ! class="col0" | Total Size: | ||
+ | | class="col1 rightalign" colspan="4" | 140 bytes | ||
+ | |} | ||
+ | :(Comments go here, please sign them) | ||
+ | |||
+ | ===HackControl v2=== | ||
+ | :Proposed by Cheesse | ||
+ | :This extension allows more control over the abilities of players. | ||
+ | :'''Motivation''': To gain control over the movement and action abilities of players. | ||
+ | :'''Client Behavior''': Client must be able to receive '''''HackControl2''''' packets at any time and apply the changes defined in the packet immediately. Any value may be given in any field to allow or adjust an ability. If a negative value is given in any field, the client should set that value to its default. If <code>0</code> is given in any field, the client must deactivate that ability and prevent its use by the player unless otherwise stated. | ||
+ | :'''Server Behavior''': Server may send '''''HackControl2''''' packets to successfully connected clients at any time. | ||
+ | :<h4>HackControl2 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="8" | 0x?? | ||
+ | (??) | ||
+ | | class="col1 centeralign" | FlySpeed | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>0</code> | ||
+ | | class="col4 centeralign" | This value is divided by 25 and multiplied by the default speed of flight to get the custom speed of flight. A value of 255 means there are no restrictions on flight. A value of 0 means flight is not allowed. | ||
+ | |- class="row2" | ||
+ | | class="col1 centeralign" | NoClip | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>0</code> | ||
+ | | class="col4 centeralign" | | ||
+ | *0 = Prevent no-clipping | ||
+ | *1 = Allow no-clipping | ||
+ | |- class="row3" | ||
+ | | class="col1 centeralign" | WalkSpeed | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>64</code> | ||
+ | | class="col4 centeralign" | This value is divided by 25 and multiplied by the default walking speed to get the custom walking speed. A value of 255 means there are no restrictions on walking speed. A value of 0 means the player is not allowed to walk. | ||
+ | |- class="row4" | ||
+ | | class="col1 centeralign" | RunSpeed | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>16</code> | ||
+ | | class="col4 centeralign" | This sets the speedhacking capabilities of the player. This value is divided by 25, then added to 1, then multiplied by the default walking speed to get the custom running speed. A value of 255 means there are no restrictions on running speed. A value of 0 means the player is not allowed to run. | ||
+ | |- class="row5" | ||
+ | | class="col1 centeralign" | AllowRespawn | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>1</code> | ||
+ | | class="col4 centeralign" | | ||
+ | *0 = Prevent respawning | ||
+ | *1 = Allow respawning | ||
+ | |- class="row6" | ||
+ | | class="col1 centeralign" | PointOfView | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>0</code> | ||
+ | | class="col4 centeralign" | | ||
+ | *0 = First-person view | ||
+ | *1 = Third-person behind view | ||
+ | *2 = Third-person front view | ||
+ | |||
+ | Setting this field to a defined value will prevent the player from changing their point of view. Setting it to an undefined value will allow the player to switch points of view. | ||
+ | |- class="row7" | ||
+ | | class="col1 centeralign" | JumpHeight | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>40</code> | ||
+ | | class="col4 centeralign" | Maximum height in player units of the player's normal jump. A value of 0 means the player is not allowed to jump. A value of 255 means there are no restrictions on jump height. | ||
+ | |- class="row8" | ||
+ | | class="col1 centeralign" | SuperJumpHeight | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>100</code> | ||
+ | | class="col4 centeralign" | Maximum height in player units of any other jump abilities the player has, like using speed to get a higher jump. A SuperJumpHeight value of 0 means the player is not allowed to superjump. A value of 255 means there are no restrictions on jump height. | ||
+ | |- class="row9" | ||
+ | ! class="col0" | Total Size: | ||
+ | | class="col1 rightalign" colspan="4" | 9 bytes | ||
+ | |} | ||
+ | :(Comments go here, please sign them) | ||
+ | |||
+ | ===MessageTypes v2=== | ||
+ | :Proposed by Cheesse | ||
+ | :This extension adds new ways of presenting information to the player. | ||
+ | :'''Motivation''': To allow the server to send messages in different places and for limited times. | ||
+ | :'''Client Behavior''': Client must interpret the ''PlayerID'' field of the standard [[Classic_Protocol#Server_.E2.86.92_Client_packets|'''''Message''''']] packet as the ''Message Type'' field. Certain values in this field correspond to different locations for messages on the screen. Any undefined values in this field should be ignored and presented as regular chat messages. Without mutual server-client support for this extension, this field should be ignored. | ||
+ | :'''Server Behavior''': Server may use the ''PlayerID'' field of the [[Classic_Protocol#Server_.E2.86.92_Client_packets|'''''Message''''']] packet to have that message placed at a certain location on the player's screen. | ||
+ | :{| class="wikitable" | ||
+ | |- class="row0" | ||
+ | ! class="col0" | MessageType Value | ||
+ | ! class="col1" | Meaning | ||
+ | ! class="col2" | Message Placement | ||
+ | |- class="row1" | ||
+ | | class="col0 centeralign" | 0 | ||
+ | | class="col1 centeralign" | Chat | ||
+ | | class="col2 centeralign" | In the chatbox. | ||
+ | |- class="row2" | ||
+ | | class="col0 centeralign" | 1 | ||
+ | | class="col1 centeralign" | Status1 | ||
+ | | class="col2 centeralign" | At the top right of the screen. | ||
+ | |- class="row3" | ||
+ | | class="col0 centeralign" | 2 | ||
+ | | class="col1 centeralign" | Status2 | ||
+ | | class="col2 centeralign" | At the top right of the screen below Status1. | ||
+ | |- class="row4" | ||
+ | | class="col0 centeralign" | 3 | ||
+ | | class="col1 centeralign" | Status3 | ||
+ | | class="col2 centeralign" | At the top right of the screen below Status2. | ||
+ | |- class="row5" | ||
+ | | class="col0 centeralign" | 11 | ||
+ | | class="col1 centeralign" | BottomRight1 | ||
+ | | class="col2 centeralign" | At the bottom right of the screen. | ||
+ | |- class="row6" | ||
+ | | class="col0 centeralign" | 12 | ||
+ | | class="col1 centeralign" | BottomRight2 | ||
+ | | class="col2 centeralign" | At the bottom right of the screen above BottomRight1. | ||
+ | |- class="row7" | ||
+ | | class="col0 centeralign" | 13 | ||
+ | | class="col1 centeralign" | BottomRight3 | ||
+ | | class="col2 centeralign" | At the bottom right of the screen above BottomRight2. | ||
+ | |- class="row8" | ||
+ | | class="col0 centeralign" | 45 | ||
+ | | class="col1 centeralign" | LeftHotbar | ||
+ | | class="col2 centeralign" | On top of the hotbar aligned to the left. | ||
+ | |- class="row9" | ||
+ | | class="col0 centeralign" | 54 | ||
+ | | class="col1 centeralign" | RightHotbar | ||
+ | | class="col2 centeralign" | On top of the hotbar aligned to the right. | ||
+ | |- class="row10" | ||
+ | | class="col0 centeralign" | 100 | ||
+ | | class="col1 centeralign" | BigAnnouncement | ||
+ | | class="col2 centeralign" | In large font slightly above the center of the screen. | ||
+ | |- class="row11" | ||
+ | | class="col0 centeralign" | 200 | ||
+ | | class="col1 centeralign" | SmallAnnouncement | ||
+ | | class="col2 centeralign" | Near the center of the screen below BigAnnouncement. | ||
+ | |} | ||
+ | This extension does not define any new packets. | ||
+ | :(Comments go here, please sign them) | ||
+ | |||
+ | ===ExtMapInfo=== | ||
+ | :Proposed by Cheesse | ||
+ | :This extension allows the server to send the client some of the map's metadata and other information | ||
+ | :'''Motivation''': To allow clients to save metadata with the maps they choose to save. This extension can also be modified to add more features to maps. | ||
+ | :'''Client Behavior''': Client must be able to receive '''''FinalMapInfo''''' packets at any time after a '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|LevelInitialize]]''''' packet has been received and before a '''''FinalMapInfo''''' packet has been received. Client should store the values in these fields in memory to be used later. The metadata defined in these fields come from those defined in the ClassicWorld file definitions. Client should ignore any '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|LevelFinalize]]''''' packets recieved. | ||
+ | :'''Server Behavior''': Server must send '''''FinalMapInfo''''' packets with the correct values after it has finished sending the client the raw block data after sending a '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|LevelInitialize]]''''' packet. The server should not send this packet at any other time. The server should never send any '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|LevelFinalize]]''''' packets to the client. | ||
+ | :<h4>FinalMapInfo 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="11" | 0x?? | ||
+ | (??) | ||
+ | | class="col1 centeralign" | "FormatVersion | ||
+ | |||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>1</code> | ||
+ | | class="col4 centeralign" | The FormatVersion is currently set to 1. | ||
+ | |- class="row2" | ||
+ | | class="col1 centeralign" | "MapName" | ||
+ | | class="col2 centeralign" | string | ||
+ | | class="col3 centeralign" | <code>main</code> | ||
+ | | class="col4 centeralign" | The name of the map. | ||
+ | |- class="row3" | ||
+ | | class="col1 centeralign" | "UUID" | ||
+ | | class="col2 centeralign" | byte array [16] | ||
+ | | class="col3 centeralign" | <code>abcdefghijklmnop</code> | ||
+ | | class="col4 centeralign" | The UUID of the map. | ||
+ | |- class="row4" | ||
+ | | class="col1 centeralign" | "XSize" | ||
+ | | class="col2 centeralign" | short | ||
+ | | class="col3 centeralign" | <code>128</code> | ||
+ | | class="col4 centeralign" | The length of the map in the X dimension. | ||
+ | |- class="row5" | ||
+ | | class="col1 centeralign" | "YSize" | ||
+ | | class="col2 centeralign" | short | ||
+ | | class="col3 centeralign" | <code>128</code> | ||
+ | | class="col4 centeralign" | The length of the map in the Y dimension. | ||
+ | |- class="row6" | ||
+ | | class="col1 centeralign" | "ZSize" | ||
+ | | class="col2 centeralign" | short | ||
+ | | class="col3 centeralign" | <code>128</code> | ||
+ | | class="col4 centeralign" | The length of the map in the Z dimension. | ||
+ | |- class="row7" | ||
+ | | class="col1 centeralign" | "CreatedBy" | ||
+ | | class="col2 centeralign" | string | ||
+ | | class="col3 centeralign" | <code>Cheesse</code> | ||
+ | | class="col4 centeralign" | The name of the author of the map. This should be an existing Classicube username. | ||
+ | |- class="row8" | ||
+ | | class="col1 centeralign" | "MapGenSoftware" | ||
+ | | class="col2 centeralign" | string | ||
+ | | class="col3 centeralign" | <code>Mapbuilder</code> | ||
+ | | class="col4 centeralign" | The name of the software used to generate the map. | ||
+ | |- class="row9" | ||
+ | | class="col1 centeralign" | "MapGenName" | ||
+ | | class="col2 centeralign" | string | ||
+ | | class="col3 centeralign" | <code>Flat</code> | ||
+ | | class="col4 centeralign" | The name of the generator function used to generate the map. | ||
+ | |- class="row10" | ||
+ | | class="col1 centeralign" | "TimeCreated" | ||
+ | | class="col2 centeralign" | long | ||
+ | | class="col3 centeralign" | <code>1234567890</code> | ||
+ | | class="col4 centeralign" | The UTC Unix timestamp of the time the map was generated. | ||
+ | |- class="row11" | ||
+ | | class="col1 centeralign" | "TimeLastModified" | ||
+ | | class="col2 centeralign" | long | ||
+ | | class="col3 centeralign" | <code>1234567890</code> | ||
+ | | class="col4 centeralign" | The UTC Unix timestamp of the time the map was last modified. | ||
+ | |- class="row12" | ||
+ | ! class="col0" | Total Size: | ||
+ | | class="col1 rightalign" colspan="4" | 298 bytes | ||
+ | |} | ||
+ | :(Comments go here, please sign them) | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ===BlockDefinitionsExt2=== | ||
+ | :Proposed by Goodly. | ||
+ | :This extension allows servers to define more properties for the custom blocks provided by BlockDefinitions. | ||
+ | :'''Motivation''': To allow for better custom blocks to be created. | ||
+ | :'''Client Behavior''': This extension depends on [[Classic_Protocol_Extension#BlockDefinitions|BlockDefinitions extension]] and [[Classic_Protocol_Extension#BlockDefinitionsExt|BlockDefinitionsExt extension]], and must only be enabled if BOTH extensions are mutually supported. Client should be able receive any number of '''''DefineBlockExt2''''' packets during the level loading process (after receiving '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|LevelInitialize]]''''' and until receiving '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|LevelFinalize]]''''' packets). However, dependent on client, this can be sent after level loading (Some clients might just find it more extensible than others). | ||
+ | :Client must be able to accept and render blocks as specified in '''''DefineBlockExt2''''' packets. Clients must accept any valid definitions with ''BlockID'' between 1 and 254, inclusive. If a new definition is accepted for an already-defined ''BlockID'', the old definition should be replaced. | ||
+ | |||
+ | :<h5>DefineBlockExt2 Packet</h5> | ||
+ | :''Server to Client'' | ||
:{| class="wikitable" | :{| class="wikitable" | ||
|- | |- | ||
− | |||
! Field Name | ! Field Name | ||
! Field Type | ! Field Type | ||
Line 136: | Line 697: | ||
! Notes | ! Notes | ||
|- | |- | ||
− | | class="centeralign" | + | | class="centeralign" | RandomOffset |
− | | class="centeralign" | | + | | class="centeralign" | byte |
+ | | class="centeralign" | <code>1</code> | ||
+ | | Whether or not the block is randomly offset. | ||
+ | * 0 = Not offset (No change). | ||
+ | * 1 = Randomly offset on the X and Z axis from -3/16 to 3/16. | ||
+ | * 2 = Randomly offset on the Y axis from -3/16 to 3/16. | ||
+ | * 3 = Randomly offset on the Y axis from -3/16 to 0. | ||
+ | * 4 = Randomly offset on the X, Y and Z axis from -3/16 to 3/16 | ||
+ | * 5 = Randomly offset on the X and Z axis from -3/16 to 3/16 and randomly offset on the Y axis from -3/16 to 0. | ||
+ | Note: This only effects blocks which have the "Shape" as 0 (sprite) | ||
+ | |- | ||
+ | | class="centeralign" | FatSprite | ||
| class="centeralign" | byte | | class="centeralign" | byte | ||
− | | class="centeralign" | 0 | + | | class="centeralign" | <code>1</code> |
− | | class="centeralign" | 0 = | + | | Whether or not the sprite is stretched closer to the edge of the block, similar to premium. |
+ | * 0 = Not fat (No change). | ||
+ | * 1 = The corners of the sprite are stretched from 0.8 to 15.2. (Instead of the original values of 2.50 to 13.5.) | ||
+ | Note: This only effects blocks which have the "Shape" as 0 (sprite) | ||
+ | |- | ||
+ | | class="centeralign" | Selectable | ||
+ | | class="centeralign" | byte | ||
+ | | class="centeralign" | <code>0</code> | ||
+ | | Whether or not the block/liquid becomes highlighted when pointed at it (Like how liquids are not breakable or selectable by default). | ||
+ | * 0 = Not select-able. | ||
+ | * 1 = Selectable. (No change) | ||
+ | |- | ||
+ | | class="centeralign" | Replaceable | ||
+ | | class="centeralign" | byte | ||
+ | | class="centeralign" | <code>1</code> | ||
+ | | Whether or not the client is able to reach through and place blocks inside of the the block/liquid. | ||
+ | * 0 = No change from original behavior | ||
+ | * 1 = The block can be reached through when placing blocks and can be overwritten if a block is placed inside of it. (Similar to liquid) | ||
|- | |- | ||
− | | class="centeralign" | | + | | class="centeralign" | Red |
| class="centeralign" | byte | | class="centeralign" | byte | ||
− | | class="centeralign" | | + | | class="centeralign" | <code>255</code> |
− | | | + | | Red component that the block is multiplied by. |
|- | |- | ||
− | | class="centeralign" | | + | | class="centeralign" | Green |
− | | class="centeralign" | | + | | class="centeralign" | byte |
− | | class="centeralign" | | + | | class="centeralign" | <code>109</code> |
− | | | + | | Green component that the block is multiplied by. |
− | |||
|- | |- | ||
− | | class="centeralign" | | + | | class="centeralign" | Blue |
− | | class="centeralign" | | + | | class="centeralign" | byte |
− | | class="centeralign" | | + | | class="centeralign" | <code>255</code> |
− | | | + | | Blue component that the block is multiplied by. |
− | |||
|- | |- | ||
! Total Size: | ! Total Size: | ||
− | | class="col1 rightalign" colspan="4" | | + | | class="rightalign" colspan="4" | 8 bytes |
+ | |} | ||
+ | |||
+ | ===SoundControl=== | ||
+ | :Proposed by Cheesse | ||
+ | :This extension allows the client to play music and sounds defined by the server. | ||
+ | :'''Motivation''': To create a more stimulating experience by adding custom sounds and music to the game. | ||
+ | :'''Client Behavior''': The client must be able to receive any packets defined by this extension at any time. It must not play any music unless ordered by the server. It must dispose of any unloaded custom audio or store it in an unusable format. Loops must be played on a loop. Defined BlockSounds must be available for use by custom block types, and any local placement or deletion of a block or any local footsteps on that block that uses custom BlockSounds should have the custom sound played simultaneously. Sounds being played by the '''''PlayEntityLoopSource''''' and '''''PlayEntitySFX''''' must have their sources move with the entity. The client should play SFX ordered by the server immediately after receiving any '''''PlaySFX''''', '''''PlayLevelSFX''''', or '''''PlayEntitySFX''''' packet. If the client receives an undefined value for any packet, that packet should be ignored. When a custom audio file is defined within a default slot, the client should return the default audio to that slot when it becomes undefined. | ||
+ | :'''Server Behavior''': The server may send any packets defined by this extension at any time, however, it is recommended that the server defines all sounds during the level loading phase. All audio defined only for a specific level must be unloaded by the server upon client leaving the level. Defined custom BlockSounds must be available for use by custom blocks. The '''''PlayEntityLoopSource''''' and '''''PlayEntitySFX''''' packets allow servers to attach the source of a sound to an entity. This makes it easier for servers to play "moving" sounds without having to send too much data. All audio files linked by the server must be in .ogg format. All loops MUST have a length longer than 10 seconds. The server is responsible for not infringing upon copyright and licensing. | ||
+ | :<h4>DefineMusic 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" | 0x?? | ||
+ | (??) | ||
+ | | class="col1 centeralign" | SongID | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>0</code> | ||
+ | | class="col4 centeralign" | Valid IDs are from 0-255. IDs for default music are as follows: 0=calm1, 1=calm2, 2=calm3, 3=hal1, 4=hal2, 5=hal3, 6=hal4. Default music may be redefined by the server. | ||
+ | |- class="row2" | ||
+ | | class="col1 centeralign" | SongSource | ||
+ | | class="col2 centeralign" | string | ||
+ | | class="col3 centeralign" | <code>http://www.abc.com/song.ogg</code> | ||
+ | | class="col4 centeralign" | The location of the music file online. The link must lead to a .ogg file. If this field contains only "X" (case-sensitive), the music of the SongID within the SongCategory must be unloaded. If this field contains only "A" (case-sensitive), all music defined within the SongCategory must be unloaded. Otherwise, the client should do nothing. | ||
+ | |- class="row4" | ||
+ | ! class="col0" | Total Size: | ||
+ | | class="col1 rightalign" colspan="4" | 66 bytes | ||
+ | |} | ||
+ | :<h4>DefineBlockSound 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" | 0x?? | ||
+ | (??) | ||
+ | | class="col1 centeralign" | BlockSoundID | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>8</code> | ||
+ | | class="col4 centeralign" | This is a bitfield where the 14 most significant bits represent the "block type" (such as wood, metal, grass) and the 2 least significant bits represent IDs for each individual sound (think of the different sounds for stone blocks). | ||
+ | |- class="row2" | ||
+ | | class="col1 centeralign" | BlockSoundSource | ||
+ | | class="col2 centeralign" | string | ||
+ | | class="col3 centeralign" | <code>http://www.abc.com/water.ogg</code> | ||
+ | | class="col4 centeralign" | The location of the loop file online. The link must lead to a .ogg file. If this field contains only "X" (case-sensitive), the audio for that specific BlockSoundID must be unloaded. If this field contains only "A" (case-sensitive), all sounds with the same "block type" must be unloaded. Otherwise, the client should do nothing. | ||
+ | |- class="row3" | ||
+ | ! class="col0" | Total Size: | ||
+ | | class="col1 rightalign" colspan="4" | 66 bytes | ||
+ | |} | ||
+ | :<h4>DefineLoop 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" | 0x?? | ||
+ | (??) | ||
+ | | class="col1 centeralign" | LoopID | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>3</code> | ||
+ | | class="col4 centeralign" | Valid IDs are from 0-255. | ||
+ | |- class="row2" | ||
+ | | class="col1 centeralign" | LoopSource | ||
+ | | class="col2 centeralign" | string | ||
+ | | class="col3 centeralign" | <code>http://www.abc.com/cavenoise.ogg</code> | ||
+ | | class="col4 centeralign" | The location of the loop file online. The link must lead to a .ogg file. If this field contains only "X" (case-sensitive), the audio for the LoopID must be unloaded. Otherwise, the client should do nothing. | ||
+ | |- class="row3" | ||
+ | ! class="col0" | Total Size: | ||
+ | | class="col1 rightalign" colspan="4" | 66 bytes | ||
+ | |} | ||
+ | :<h4>DefineSFX 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" | 0x?? | ||
+ | (??) | ||
+ | | class="col1 centeralign" | SFXID | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>0</code> | ||
+ | | class="col4 centeralign" | Valid IDs are from 0-255. | ||
+ | |- class="row2" | ||
+ | | class="col1 centeralign" | SFXSource | ||
+ | | class="col2 centeralign" | string | ||
+ | | class="col3 centeralign" | <code>http://www.abc.com/killstreak.ogg</code> | ||
+ | | class="col4 centeralign" | The location of the music file online. The link must lead to a .ogg file. If this field contains only "X", the sound of the SFXID must be unloaded. Otherwise, the client should do nothing. | ||
+ | |- class="row3" | ||
+ | ! class="col0" | Total Size: | ||
+ | | class="col1 rightalign" colspan="4" | 66 bytes | ||
|} | |} | ||
+ | :<h4>PlayMusic 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" | 0x?? | ||
+ | (??) | ||
+ | | class="col1 centeralign" | SongID | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>0</code> | ||
+ | | class="col4 centeralign" | SongID must be defined. | ||
+ | |- class="row2" | ||
+ | | class="col1 centeralign" | Volume | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>100</code> | ||
+ | | class="col4 centeralign" | From 0-200, the volume at which to play the music. | ||
+ | |- class="row3" | ||
+ | | class="col1 centeralign" | Fade | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>0</code> | ||
+ | | class="col4 centeralign" | This is a bitfield from 0-7 with 7 being the most significant bit. Bits 0-3 are for the period taken for the song to fade in. Valid values for this are from 0-15 (in seconds). Bits 4-7 are for are for the fade out, and the values for this are from 0-15 (in seconds). | ||
+ | |- class="row4" | ||
+ | | class="col1 centeralign" | Loop | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>0</code> | ||
+ | | class="col4 centeralign" | From 0-254, the position from the start, in tenths of a second, at which the music should return after the end is reached. If this field is 255, then the song does not loop. | ||
+ | |- class="row5" | ||
+ | ! class="col0" | Total Size: | ||
+ | | class="col1 rightalign" colspan="4" | 5 bytes | ||
+ | |} | ||
+ | |||
+ | :<h4>PlayLevelLoopSource 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" | 0x?? | ||
+ | (??) | ||
+ | | class="col1 centeralign" | LoopID | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>0</code> | ||
+ | | class="col4 centeralign" | LoopID must be previously defined. If a different loop was playing at a position defined by PositionX, -Y, and -Z, then the client must replace that loop with this one. | ||
+ | |- class="row2" | ||
+ | | class="col1 centeralign" | Volume | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>100</code> | ||
+ | | class="col4 centeralign" | From 0-200, the volume at which to play the sound effect. If the volume is set to 0, the client must not play any loops at that position, especially if one was playing there before. | ||
+ | |- class="row3" | ||
+ | | class="col1 centeralign" | PositionX | ||
+ | | class="col2 centeralign" | short | ||
+ | | class="col3 centeralign" | <code>20</code> | ||
+ | | class="col4 centeralign" | The X-coordinate of the position of the source of the loop on the level (in player coordinates). | ||
+ | |- class="row4" | ||
+ | | class="col1 centeralign" | PositionY | ||
+ | | class="col2 centeralign" | short | ||
+ | | class="col3 centeralign" | <code>20</code> | ||
+ | | class="col4 centeralign" | The Y-coordinate of the position of the source of the loop on the level (in player coordinates). | ||
+ | |- class="row5" | ||
+ | | class="col1 centeralign" | PositionZ | ||
+ | | class="col2 centeralign" | short | ||
+ | | class="col3 centeralign" | <code>20</code> | ||
+ | | class="col4 centeralign" | The Z-coordinate of the position of the source of the loop on the level (in player coordinates). | ||
+ | |- class="row6" | ||
+ | ! class="col0" | Total Size: | ||
+ | | class="col1 rightalign" colspan="4" | 9 bytes | ||
+ | |} | ||
+ | :<h4>PlayEntityLoopSource 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" | 0x?? | ||
+ | (??) | ||
+ | | class="col1 centeralign" | LoopID | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>0</code> | ||
+ | | class="col4 centeralign" | LoopID must be previously defined. If a different loop was playing from an entity with ID EntityID, the client must replace that loop with this one. | ||
+ | |- class="row2" | ||
+ | | class="col1 centeralign" | Volume | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>100</code> | ||
+ | | class="col4 centeralign" | From 0-200, the volume at which to play the sound effect. If the volume is set to 0, the client must not play any loops from that entity, especially if one was playing there before. | ||
+ | |- class="row3" | ||
+ | | class="col1 centeralign" | EntityID | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>1</code> | ||
+ | | class="col4 centeralign" | The ID of the entity from which the loop should be played. | ||
+ | |- class="row4" | ||
+ | ! class="col0" | Total Size: | ||
+ | | class="col1 rightalign" colspan="4" | 4 bytes | ||
+ | |} | ||
+ | :<h4>PlaySFX 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" | 0x?? | ||
+ | (??) | ||
+ | | class="col1 centeralign" | SFXID | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>0</code> | ||
+ | | class="col4 centeralign" | SFXID must be defined. | ||
+ | |- class="row2" | ||
+ | | class="col1 centeralign" | Volume | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>100</code> | ||
+ | | class="col4 centeralign" | From 0-200, the volume at which to play the sound effect. | ||
+ | |- class="row3" | ||
+ | ! class="col0" | Total Size: | ||
+ | | class="col1 rightalign" colspan="4" | 3 bytes | ||
+ | |} | ||
+ | :<h4>PlayLevelSFX 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" | 0x?? | ||
+ | (??) | ||
+ | | class="col1 centeralign" | SFXID | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>0</code> | ||
+ | | class="col4 centeralign" | SFXID must be defined. | ||
+ | |- class="row2" | ||
+ | | class="col1 centeralign" | Volume | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>100</code> | ||
+ | | class="col4 centeralign" | From 0-200, the volume at which to play the sound effect. | ||
+ | |- class="row3" | ||
+ | | class="col1 centeralign" | PositionX | ||
+ | | class="col2 centeralign" | short | ||
+ | | class="col3 centeralign" | <code>100</code> | ||
+ | | class="col4 centeralign" | The X-coordinate of the position of the source of the loop on the level (in player coordinates). | ||
+ | |- class="row4" | ||
+ | | class="col1 centeralign" | PositionY | ||
+ | | class="col2 centeralign" | short | ||
+ | | class="col3 centeralign" | <code>100</code> | ||
+ | | class="col4 centeralign" | The Y-coordinate of the position of the source of the loop on the level (in player coordinates). | ||
+ | |- class="row5" | ||
+ | | class="col1 centeralign" | PositionZ | ||
+ | | class="col2 centeralign" | short | ||
+ | | class="col3 centeralign" | <code>100</code> | ||
+ | | class="col4 centeralign" | The Z-coordinate of the position of the source of the loop on the level (in player coordinates). | ||
+ | |- class="row6" | ||
+ | ! class="col0" | Total Size: | ||
+ | | class="col1 rightalign" colspan="4" | 9 bytes | ||
+ | |} | ||
+ | :<h4>PlayEntitySFX 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" | 0x?? | ||
+ | (??) | ||
+ | | class="col1 centeralign" | SFXID | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>0</code> | ||
+ | | class="col4 centeralign" | SFXID must be defined. | ||
+ | |- class="row2" | ||
+ | | class="col1 centeralign" | Volume | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>100</code> | ||
+ | | class="col4 centeralign" | From 0-200, the volume at which to play the sound effect. | ||
+ | |- class="row3" | ||
+ | | class="col1 centeralign" | EntityID | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | <code>3</code> | ||
+ | | class="col4 centeralign" | The ID of the entity from which the sound effect should be played. | ||
+ | |- class="row4" | ||
+ | ! class="col0" | Total Size: | ||
+ | | class="col1 rightalign" colspan="4" | 4 bytes | ||
+ | |} | ||
+ | |||
:(Comments go here, please sign them) | :(Comments go here, please sign them) | ||
− | === | + | ===WebSocketsSupport=== |
− | :Proposed by | + | :Proposed by [[User:Maxouf0x|Maxouf0x]] ([[User talk:Maxouf0x|talk]]) 06:18, 3 August 2017 (UTC) |
− | : | + | :Add websocket support to the minecraft classic protocol. |
− | :'''Motivation''': | + | :'''Motivation''': Make web clients without having to use webtcp. |
− | :'''Client Behavior''': | + | :'''Client Behavior''': Clients that use web socket must send a normal HTTP GET request to http://<server IP>:<server port>/connect, When the client recive the redirect, it must open a websocket connection to the recived URL, and continue with the normal protocol, wrapped in a websocket. |
− | + | ||
− | :''' | + | :'''Server Behavior''': Server supporting websockets must check if the client has sent an HTTP GET request before sending the Server Identification package. If the client has sent an HTTP GET request to /connect, the web socket integration is disabled, but implemented, the server must respond with a 503 error code. If the websocket integration is enabled, the server must respond with a 302 code, redirecting to http://<server IP>:<server Port/Other port>/game. When the server recives a websocket connection to http://<server IP>:<server Port/Other port>/game, it must continue with the normal protocol, wrapped in a websocket. |
− | : | + | :The port used to request /connect is the same as the game port, so that this doesn't break the current heartbeat system. |
− | : | + | This extension does not define any new packets. |
+ | :(Comments go here, please sign them) | ||
− | :< | + | what? WebSockets are already supported. |
− | :'' | + | |
+ | [[User:TheAwesome98|TheAwesome98]] ([[User talk:TheAwesome98|talk]]) 17:23, 6 November 2021 (UTC) | ||
+ | |||
+ | ===ExtDirection=== | ||
+ | :Proposed by Cheesse | ||
+ | :Increases the precision of direction data sent in all player position/orientation packets. | ||
+ | :'''Motivation''': Improve the precision of player rotation for servers that require high precision. | ||
+ | :'''Client Behavior''': The client must write unsigned shorts instead of bytes for the Yaw and Pitch fields of the '''''[[Classic_Protocol#Client_.E2.86.92_Server_packets|PositionAndOrientation]]''''' packet and any other packet that contains entity direction data. | ||
+ | :'''Server Behavior''': The server must write unsigned shorts instead of bytes for the Yaw and Pitch fields of the '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|SpawnPlayer]]''''', '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|PositionAndOrientation]]''''', '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|PositionAndOrientationUpdate]]''''', and '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|OrientationUpdate]]''''' packets and any other packet that contains entity direction data. | ||
+ | |||
+ | :This extension does not define any new packets. | ||
+ | |||
+ | ===ClientRedirection r2=== | ||
+ | :Proposed by [[User:Galaxtone|Galaxtone]] ([[User talk:Galaxtone|talk]]) 05:32, 21 January 2019 (UTC) | ||
+ | :The extensions allows servers to redirect clients to other servers. | ||
+ | :'''Motivation''': Allowing servers to redirect clients to other trusted sub-servers or a completly different server, Useful for hub servers leading to smaller sub-servers and even for sudden creation of private servers to connect to, and for the proxies themselves implement extension support. | ||
+ | :'''Client Behavior''': After extension negotiation, the client must send a '''Redirection''' packet (Specifies the redirecting server, blank if directly connected) to the server, afterwards the client must be able to receive a '''Redirection''' packet at any time, upon receiving the packet (Ignoring if blank), the client may deny the redirection by doing nothing, otherwise the client must disconnect from the server and reconnect to the specified server. | ||
+ | :'''Server Behavior''': After extension negotiation, the server must wait for a '''Redirection''' packet from compatible clients before sending level data, afterwards the server may then send the '''Redirection''' packet at any time. | ||
+ | :<h4>Redirection packet</h4> | ||
+ | :''Bidirectional'' | ||
:{| class="wikitable" | :{| class="wikitable" | ||
|- | |- | ||
Line 187: | Line 1,103: | ||
! Notes | ! Notes | ||
|- | |- | ||
− | | class="centeralign" rowspan=" | + | | 0x?? |
+ | (??) | ||
+ | | Server Hash | ||
+ | | String | ||
+ | | <code>226fb815f216daf4d0ef653bc32c6b89</code> | ||
+ | | 32 base-36 characters. | ||
+ | |- | ||
+ | ! Total Size: | ||
+ | | class="col0" colspan="4" | 65 bytes | ||
+ | |} | ||
+ | :'''Note:''' This is the second revision of this extension proposal, not the second version of the extension. | ||
+ | |||
+ | ===DefineQuad=== | ||
+ | :Proposed by Cybertoon | ||
+ | :This extension allows you to define extra quads for a block. | ||
+ | :'''Motivation''': This would allow blocks that have more than one quad. So-called "block model". | ||
+ | :'''Client Behavior''': The client would render the extra quads given by this packet for a block, with the textures defined by this packet. Requires support for BlockDefinitionsExt. If the block is discarded with '''''RemoveBlockDefinition''''', all Quads defined by this packet must also be discarded. If the client supports multiple collisions, if this packet defines collisions, use those instead. If client doesn't, or if none are defined, use the bounds defined in BlockDefinition. If "render" is set to false, this quad will only be used for bounds. If both are false, do nothing. If client doesn't support multiple collisions in a block, do nothing if render is set to false. | ||
+ | :'''Server Behavior''': If client supports extension, send the client the quads, starting with the second quad, then the next, so forth and so forth. This packet must be sent after the block has already been defined. | ||
+ | :'''DefineQuad packet''' | ||
+ | |||
+ | {| class="wikitable" | ||
+ | |- | ||
+ | | Packet ID | ||
+ | ! Field Name | ||
+ | ! Field Type | ||
+ | ! Example | ||
+ | ! Notes | ||
+ | |- | ||
+ | | class="centeralign" rowspan="20" | 0x?? | ||
+ | (??) | ||
| class="centeralign" | BlockID | | class="centeralign" | BlockID | ||
| class="centeralign" | byte | | class="centeralign" | byte | ||
− | | class="centeralign" | <code> | + | | class="centeralign" | <code>0</code> |
− | | Between | + | | The ID of the block this Quad belongs to. Between 1 and 255. |
|- | |- | ||
− | | class="centeralign" | | + | | class="centeralign" | QuadID |
| class="centeralign" | byte | | class="centeralign" | byte | ||
| class="centeralign" | <code>0</code> | | class="centeralign" | <code>0</code> | ||
− | | | + | |Refers to a terrain.png tile. |
− | + | Between 0 and 255 (unsigned). The ID of the extra quad being defined. Changing Quad 0 will change the quad defined in the BlockDefinition, and the bounds defined there will be the bounding box unless multiple bounding boxes are supported by client. | |
− | |||
− | |||
|- | |- | ||
− | | class="centeralign" | | + | | class="centeralign" | TopTextureId |
− | |||
− | |||
− | |||
− | |||
− | |||
| class="centeralign" | byte | | class="centeralign" | byte | ||
− | | class="centeralign" | <code> | + | | class="centeralign" | <code>0</code> |
− | | | + | |Refers to a terrain.png tile. |
− | + | Between 0 and 255 (unsigned). Can be same as other texture IDs. This is the texture ID for the Y = 1 face. | |
− | |||
− | |||
− | |||
|- | |- | ||
− | | class="centeralign" | | + | | class="centeralign" | LeftTextureId |
| class="centeralign" | byte | | class="centeralign" | byte | ||
− | | class="centeralign" | <code> | + | | class="centeralign" | <code>0</code> |
− | | | + | |Refers to a terrain.png tile. |
− | + | Between 0 and 255 (unsigned). Can be same as other texture IDs. This is the texture ID for the X = 0 face. | |
− | |||
− | |||
− | |||
− | |||
|- | |- | ||
− | | class="centeralign" | | + | | class="centeralign" | RightTextureId |
| class="centeralign" | byte | | class="centeralign" | byte | ||
− | | class="centeralign" | <code> | + | | class="centeralign" | <code>0</code> |
− | | Refers to a | + | |Refers to a terrain.png tile. |
− | Between 0 and 255 (unsigned). | + | Between 0 and 255 (unsigned). Can be same as other texture IDs. This is the texture ID for the X = 1 face. |
− | Can be same as other texture IDs. | ||
|- | |- | ||
− | | class="centeralign" | | + | | class="centeralign" | FrontTextureId |
| class="centeralign" | byte | | class="centeralign" | byte | ||
− | | class="centeralign" | <code> | + | | class="centeralign" | <code>0</code> |
− | | Refers to a | + | |Refers to a terrain.png tile. |
− | Between 0 and 255 (unsigned). | + | Between 0 and 255 (unsigned). Can be same as other texture IDs. This is the texture ID for the Z = 0 face. |
− | Can be same as other texture IDs. | ||
|- | |- | ||
− | | class="centeralign" | | + | | class="centeralign" | BackTextureId |
| class="centeralign" | byte | | class="centeralign" | byte | ||
− | | class="centeralign" | <code> | + | | class="centeralign" | <code>0</code> |
− | | Refers to a | + | |Refers to a terrain.png tile. |
− | Between 0 and 255 (unsigned). | + | Between 0 and 255 (unsigned). Can be same as other texture IDs. This is the texture ID for the Z = 1 face. |
− | Can be same as other texture IDs. | ||
|- | |- | ||
− | | class="centeralign" | | + | | class="centeralign" | BottomTextureId |
| class="centeralign" | byte | | class="centeralign" | byte | ||
| class="centeralign" | <code>0</code> | | class="centeralign" | <code>0</code> | ||
− | | | + | |Refers to a terrain.png tile. |
− | + | Between 0 and 255 (unsigned). Can be same as other texture IDs. This is the texture ID for the Y = 0 face. | |
|- | |- | ||
− | | class="centeralign" | | + | | class="centeralign" | MinX |
| class="centeralign" | byte | | class="centeralign" | byte | ||
− | | class="centeralign" | <code> | + | | class="centeralign" | <code>0</code> |
− | | | + | | Minimum X coordinate in pixels. Min allowed is 0, max allowed is 15. |
|- | |- | ||
− | | class="centeralign" | | + | | class="centeralign" | MinY |
| class="centeralign" | byte | | class="centeralign" | byte | ||
| class="centeralign" | <code>0</code> | | class="centeralign" | <code>0</code> | ||
− | | | + | | Minimum Y coordinate in pixels. Min allowed is 0, max allowed is 15. |
|- | |- | ||
− | | class="centeralign" | | + | | class="centeralign" | MinZ |
| class="centeralign" | byte | | class="centeralign" | byte | ||
| class="centeralign" | <code>0</code> | | class="centeralign" | <code>0</code> | ||
− | | | + | | Minimum Z coordinate in pixels. Min allowed is 0, max allowed is 15. |
− | + | |- | |
+ | | class="centeralign" | MaxX | ||
+ | | class="centeralign" | byte | ||
+ | | class="centeralign" | <code>16</code> | ||
+ | | Maximum X coordinate in pixels. Min allowed is 1, max allowed is 16. | ||
+ | |- | ||
+ | | class="centeralign" | MaxY | ||
+ | | class="centeralign" | byte | ||
+ | | class="centeralign" | <code>16</code> | ||
+ | | Maximum Y coordinate in pixels. Min allowed is 1, max allowed is 16. | ||
+ | |- | ||
+ | | class="centeralign" | MaxZ | ||
+ | | class="centeralign" | byte | ||
+ | | class="centeralign" | <code>16</code> | ||
+ | | Maximum Z coordinate in pixels. Min allowed is 1, max allowed is 16. | ||
|- | |- | ||
− | | class="centeralign" | | + | | class="centeralign" | ColR |
| class="centeralign" | byte | | class="centeralign" | byte | ||
− | | class="centeralign" | <code> | + | | class="centeralign" | <code>255</code> |
− | | | + | | Red color to filter with. |
− | + | |- | |
+ | | class="centeralign" | ColG | ||
+ | | class="centeralign" | byte | ||
+ | | class="centeralign" | <code>255</code> | ||
+ | | Green color to filter with. | ||
+ | |- | ||
+ | | class="centeralign" | ColB | ||
+ | | class="centeralign" | byte | ||
+ | | class="centeralign" | <code>255</code> | ||
+ | | Blue color to filter with. | ||
+ | |- | ||
+ | | class="centeralign" | Collide | ||
+ | | class="centeralign" | bool | ||
+ | | class="centeralign" | <code>true</code> | ||
+ | | Whether this quad can collide with this quad. If set to false, this quad will be ignored by colision. If multiple collisions are not supported by the client, use bounds defined in the BlockDefinition. | ||
+ | |- | ||
+ | | class="centeralign" | Render | ||
+ | | class="centeralign" | bool | ||
+ | | class="centeralign" | <code>true</code> | ||
+ | | Whether this quad will render. If set to false, this quad will not render, and will only be used for collision. | ||
|- | |- | ||
! Total Size: | ! Total Size: | ||
− | | class="rightalign" colspan="4" | | + | | class="rightalign" colspan="4" | 18 bytes |
|} | |} | ||
− | :< | + | :(Comments go here, please sign them) |
+ | |||
+ | ===TexturePackExt=== | ||
+ | :Proposed by [[User:Galaxtone|Galaxtone]] ([[User talk:Galaxtone|talk]]) 00:59, 27 February 2020 (UTC) | ||
+ | :This extension adds hierarchical texture packs where multiple may be loaded per map and override each other in a distinct order. | ||
+ | :'''Motivation:''' Creating texture packs that modify a few assets without having to copy the server's global texture pack assets which would be bulky, impractical and non-portable between servers. | ||
+ | :'''Client behavior:''' This extension must be mutually supported along with '''EnvMapAspect'''. The client must combine all texture packs, resolving file conflicts between multiple texture packs by using the file from the texture pack with the highest order. The client must treat '''''SetMapEnvUrl''''' packets as texture packs with an order of -1. The client must be able to receive '''''SetMapEnvUrlExt''''' packets at any time appropriate to receive '''''SetMapEnvUrl''''' packets. The '''''EnvMapEnvUrl''''' packet must be used to clear all texture packs as the '''''EnvMapEnvUrlExt''''' packet will set or clear the texture pack at the specified order. | ||
+ | :'''Server behavior:''' Server may send '''''SetMapEnvUrlExt''''' packets at any time appropriate to send '''''SetMapEnvUrl''''' packets. To reset all texture packs to the client's default, server has to use the '''''SetMapEnvUrl''''' packet instead. | ||
+ | :<h4>SetMapEnvUrlExt packet</h4> | ||
:''Server to Client'' | :''Server to Client'' | ||
:{| class="wikitable" | :{| class="wikitable" | ||
Line 288: | Line 1,257: | ||
! Notes | ! Notes | ||
|- | |- | ||
− | | class="centeralign" rowspan=" | + | | class="centeralign" rowspan="2" | 0x?? |
− | | class="centeralign" | | + | (??) |
+ | | class="leftalign" colspan="4" | Following field from SetMapEnvUrl packet: TexturePackURL | ||
+ | |- | ||
+ | | class="centeralign" | TexturePackOrder | ||
| class="centeralign" | byte | | class="centeralign" | byte | ||
− | | class="centeralign" | <code> | + | | class="centeralign" | <code>6</code> |
− | | | + | |The order of the texture pack. |
+ | |- | ||
+ | ! Total Size: | ||
+ | | class="rightalign" colspan="4" | 66 bytes | ||
+ | |} | ||
+ | |||
+ | :(Comments go here, please sign them) | ||
+ | |||
+ | ===BlockDefinitions v2=== | ||
+ | :Proposed by [[User:Jshtab|Jshtab]] ([[User talk:Jshtab|talk]]) 19:10, 11 January 2022 (UTC) | ||
+ | :Functionally equal to supporting BlockDefinitionsExt v2. Superceeds BlockDefinitionsExt v2 and BlockDefinitions v1. | ||
+ | :'''Motivation''': Prevent dependency hell, promote consistency. | ||
+ | :'''Client Behavior''': Functionally equal to supporting BlockDefinitionsExt v2. | ||
+ | :'''Server Behavior''': Functionally equal to supporting BlockDefinitionsExt v2. If a client supports BlockDefinitions v1 and BlockDefinitionsExt v2, they support BlockDefinitions v2 | ||
+ | :(Comments go here, please sign them) | ||
+ | |||
+ | ===ScreenElements=== | ||
+ | :Proposed by [[User:DT|DT]] | ||
+ | :This extension allows the server to define and undefine 2d elements on the client's screen. | ||
+ | :'''Motivation''': It would allow for advanced UI elements and sprites to be drawn to the screen, such as a textured health bar above the hotbar, or a timer at the top of the screen. | ||
+ | :'''Client Behavior''': Clients should be able to define and undefine image and text elements. Client should use sprites.png in the texture pack zip for textured sprites. Client must be able to receive and send all packets. Screen elements should not persist between maps. | ||
+ | :'''Server Behavior''': Servers should be able to send and receive packets to define and undefine image and text elements. | ||
+ | |||
+ | :<h4>DefineImgElem</h4> | ||
+ | :''Server to Client'' | ||
+ | :{| class="wikitable" | ||
|- | |- | ||
− | + | ! Packet ID | |
− | + | ! Field Name | |
− | + | ! Field Type | |
− | + | ! Example | |
+ | ! Notes | ||
|- | |- | ||
− | | class="centeralign" | | + | | class="centeralign" rowspan="7" | 0x?? |
+ | (??) | ||
+ | |- | ||
+ | | class="centeralign" | ElemID | ||
| class="centeralign" | byte | | class="centeralign" | byte | ||
− | | class="centeralign" | <code> | + | | class="centeralign" | <code>0</code> |
− | | | + | |Element ID |
− | |||
|- | |- | ||
− | | class="centeralign" | | + | | class="centeralign" | AnchorX |
| class="centeralign" | byte | | class="centeralign" | byte | ||
| class="centeralign" | <code>1</code> | | class="centeralign" | <code>1</code> | ||
− | | | + | |The screen anchor along the X axis |
− | + | *0 = Left | |
− | + | *1 = Center | |
− | + | *2 = Right | |
− | * | ||
− | * | ||
− | |||
|- | |- | ||
− | | class="centeralign" | | + | | class="centeralign" | AnchorY |
| class="centeralign" | byte | | class="centeralign" | byte | ||
| class="centeralign" | <code>1</code> | | class="centeralign" | <code>1</code> | ||
− | | | + | |The screen anchor along the Y axis |
− | + | *0 = Top | |
− | + | *1 = Center | |
+ | *2 = Bottom | ||
|- | |- | ||
− | | class="centeralign" | | + | | class="centeralign" | OffsetX |
− | | class="centeralign" | | + | | class="centeralign" | short |
− | | class="centeralign" | <code> | + | | class="centeralign" | <code>24</code> |
− | | | + | |The X offset from AnchorX |
− | + | |- | |
− | + | | class="centeralign" | OffsetY | |
+ | | class="centeralign" | short | ||
+ | | class="centeralign" | <code>-712</code> | ||
+ | |The Y offset from AnchorY | ||
+ | |- | ||
+ | | class="centeralign" | Source | ||
+ | | class="centeralign" | UVCoords | ||
+ | | class="centeralign" | <code>(0,5, 10,15)</code> | ||
+ | |UV Coords of sprites.png to display | ||
+ | |- | ||
+ | ! Total Size: | ||
+ | | class="rightalign" colspan="4" | 16 bytes | ||
+ | |} | ||
+ | |||
+ | :<h4>DefineTextElem</h4> | ||
+ | :''Server to Client'' | ||
+ | :{| class="wikitable" | ||
|- | |- | ||
− | + | ! Packet ID | |
− | + | ! Field Name | |
− | + | ! Field Type | |
− | + | ! Example | |
− | + | ! Notes | |
− | |||
|- | |- | ||
− | | class="centeralign" | + | | class="centeralign" rowspan="8" | 0x?? |
− | + | (??) | |
− | |||
− | |||
|- | |- | ||
− | | class="centeralign" | | + | | class="centeralign" | ElemID |
| class="centeralign" | byte | | class="centeralign" | byte | ||
| class="centeralign" | <code>0</code> | | class="centeralign" | <code>0</code> | ||
− | | | + | |Element ID |
|- | |- | ||
− | | class="centeralign" | | + | | class="centeralign" | AnchorX |
| class="centeralign" | byte | | class="centeralign" | byte | ||
− | | class="centeralign" | <code> | + | | class="centeralign" | <code>1</code> |
− | | | + | |The screen anchor along the X axis |
− | + | *0 = Left | |
− | + | *1 = Center | |
− | + | *2 = Right | |
− | |||
− | |||
− | |||
|- | |- | ||
− | | class="centeralign" | | + | | class="centeralign" | AnchorY |
| class="centeralign" | byte | | class="centeralign" | byte | ||
− | | class="centeralign" | <code> | + | | class="centeralign" | <code>1</code> |
− | | | + | |The screen anchor along the Y axis |
+ | *0 = Top | ||
+ | *1 = Center | ||
+ | *2 = Bottom | ||
+ | |- | ||
+ | | class="centeralign" | OffsetX | ||
+ | | class="centeralign" | short | ||
+ | | class="centeralign" | <code>24</code> | ||
+ | |The X offset from AnchorX | ||
|- | |- | ||
− | | class="centeralign" | | + | | class="centeralign" | OffsetY |
− | | class="centeralign" | | + | | class="centeralign" | short |
− | | class="centeralign" | <code> | + | | class="centeralign" | <code>-712</code> |
− | | | + | |The Y offset from AnchorY |
|- | |- | ||
− | | class="centeralign" | | + | | class="centeralign" | Text |
− | | class="centeralign" | | + | | class="centeralign" | string |
− | | class="centeralign" | <code> | + | | class="centeralign" | <code>""</code> |
− | | | + | |Text to display |
|- | |- | ||
− | | class="centeralign" | | + | | class="centeralign" | Scale |
| class="centeralign" | byte | | class="centeralign" | byte | ||
| class="centeralign" | <code>0</code> | | class="centeralign" | <code>0</code> | ||
− | | | + | |Scale of text being displayed (0 for small, 1 for big) |
− | |||
|- | |- | ||
! Total Size: | ! Total Size: | ||
− | | class="rightalign" colspan="4" | | + | | class="rightalign" colspan="4" | 72 bytes |
|} | |} | ||
− | :< | + | :<h4>UndefineElem</h4> |
:''Server to Client'' | :''Server to Client'' | ||
:{| class="wikitable" | :{| class="wikitable" | ||
Line 393: | Line 1,408: | ||
! Notes | ! Notes | ||
|- | |- | ||
− | | class="centeralign" | ??? | + | | class="centeralign" rowspan="2" | 0x?? |
− | | class="centeralign" | | + | (??) |
+ | |- | ||
+ | | class="centeralign" | ElemID | ||
| class="centeralign" | byte | | class="centeralign" | byte | ||
− | | class="centeralign" | <code> | + | | class="centeralign" | <code>0</code> |
− | | | + | |Element ID to undefine |
|- | |- | ||
! Total Size: | ! Total Size: | ||
Line 403: | Line 1,420: | ||
|} | |} | ||
− | :''' | + | :(Comments go here, please sign them) |
− | :''' | + | |
− | :''' | + | |
− | :''' | + | ===ExtendedBlocks v2=== |
+ | :Proposed by [[User:Infernity|Infernity]] ([[User talk:Infernity|talk]]) 17:19, 15 June 2022 (UTC) | ||
+ | :Allows using more than 768 blocks. | ||
+ | :'''Motivation''': Allows for ever-more-detailed maps by sending up to 65,536 blocks. | ||
+ | :'''Client Behavior''': Clients must adjust how they read the map as described in the '''Affect on map sending''' section. Clients must also adjust how they read and write several fields of the packets described in the '''Affect on other packets''' section. When a client detects that the secondary map blocks array is used, it must switch from accessing blocks via <code>map.blocks[index]</code> to <code>map1.blocks[index] | (map2.blocks[index] << 8)</code> instead. | ||
+ | :'''Server Behavior''': Servers must adjust how they write the map as described in the '''Affect on map sending''' section. Servers must also adjust how they read and write several fields of the packets described in the '''Affect on other packets''' section. Ideally, servers should avoid sending a secondary map blocks array when possible to minimise client memory usage. | ||
+ | |||
+ | :<h4>Affect on map sending</h4> | ||
+ | Essentially, instead of '''LevelDataChunk''' packets just being used to send the compressed form of the map blocks array, it is repurposed to send both the compressed form of the 'main' map blocks array and optionally a secondary map blocks array. | ||
+ | To accomplish this, the '''Percent Complete''' field in the '''LevelDataChunk''' packet is repurposed. A value of ''0'' indicates that this LevelDataChunk packet contains part of the compressed data for the 'main' map blocks array, while a value of ''1'' indicates this LevelDataChunk packet contains part of the compressed data for the optional secondary map blocks array. | ||
+ | |||
+ | The client and server should treat the '''LevelDataChunk''' packets used for the 'main' map blocks array as completely separate from the secondary map blocks array, i.e. the 'main' map blocks array should be compressed and decompressed completely independently of the optional secondary map blocks array. | ||
+ | |||
+ | '''Note:''' Even if the server only sends a 'main' map blocks array, the client must still be prepared to allocate a secondary map blocks array at any time after map load. For example: | ||
+ | * Client A goes to map XYZ | ||
+ | * Server sends client A just a main blocks array for map XYZ | ||
+ | * A minute later, client B places a block with ID 510 on map XYZ | ||
+ | * Server then broadcasts this block change to all clients on map XYZ | ||
+ | Since a secondary map blocks array was not sent during map load by the server, Client A must now allocate a secondary map blocks array. | ||
+ | |||
+ | :<h4>Affect on other packets</h4> | ||
+ | Several fields in some packets are expanded in size. These are: | ||
+ | :{| class="wikitable" | ||
+ | |- class="row0" | ||
+ | ! class="col0" | Packet | ||
+ | ! class="col1" | Field Name | ||
+ | ! class="col2" | New Type | ||
+ | ! class="col3" | Direction | ||
+ | |- class="row1" | ||
+ | | class="col0 centeralign" | Set Block (0x05) | ||
+ | | class="col1 centeralign" | Block type | ||
+ | | class="col2 centeralign" | short | ||
+ | | class="col3 centeralign" | Client -> Server | ||
+ | |- class="row2" | ||
+ | | class="col0 centeralign" | Set Block (0x06) | ||
+ | | class="col1 centeralign" | Block Type | ||
+ | | class="col2 centeralign" | short | ||
+ | | class="col3 centeralign" | Server -> Client | ||
+ | |- class="row3" | ||
+ | | class="col0 centeralign" | Position and Orientation (0x08) | ||
+ | | class="col1 centeralign" | Player ID | ||
+ | | class="col2 centeralign" | short | ||
+ | | class="col3 centeralign" | Client -> Server | ||
+ | |- class="row4" | ||
+ | | class="col0 centeralign" | HoldThis (0x14) | ||
+ | | class="col1 centeralign" | BlockToHold | ||
+ | | class="col2 centeralign" | short | ||
+ | | class="col3 centeralign" | Server -> Client | ||
+ | |- class="row5" | ||
+ | | class="col0 centeralign" | SetBlockPermission (0x1C) | ||
+ | | class="col1 centeralign" | BlockType | ||
+ | | class="col2 centeralign" | short | ||
+ | | class="col3 centeralign" | Server -> Client | ||
+ | |- class="row6" | ||
+ | | class="col0 centeralign" | DefineBlock (0x23) | ||
+ | | class="col1 centeralign" | BlockID | ||
+ | | class="col2 centeralign" | short | ||
+ | | class="col3 centeralign" | Server -> Client | ||
+ | |- class="row7" | ||
+ | | class="col0 centeralign" | UndefineBlock (0x24) | ||
+ | | class="col1 centeralign" | BlockID | ||
+ | | class="col2 centeralign" | short | ||
+ | | class="col3 centeralign" | Server -> Client | ||
+ | |- class="row8" | ||
+ | | class="col0 centeralign" | DefineBlockExt (0x25) | ||
+ | | class="col1 centeralign" | BlockID | ||
+ | | class="col2 centeralign" | short | ||
+ | | class="col3 centeralign" | Server -> Client | ||
+ | |- class="row9" | ||
+ | | class="col0 centeralign" | BulkBlockUpdate (0x28) | ||
+ | | class="col1 centeralign" | Blocks | ||
+ | | class="col2 centeralign" | byte[512] | ||
+ | | class="col3 centeralign" | Server -> Client | ||
+ | |- class="row10" | ||
+ | | class="col0 centeralign" | SetInventoryOrder (0x2C) | ||
+ | | class="col1 centeralign" | Order | ||
+ | | class="col2 centeralign" | short | ||
+ | | class="col3 centeralign" | Server -> Client | ||
+ | |- class="row11" | ||
+ | | class="col0 centeralign" | SetInventoryOrder (0x2C) | ||
+ | | class="col1 centeralign" | Block ID | ||
+ | | class="col2 centeralign" | short | ||
+ | | class="col3 centeralign" | Server -> Client | ||
+ | |- class="row12" | ||
+ | | class="col0 centeralign" | SetHotbar (0x2D) | ||
+ | | class="col1 centeralign" | BlockID | ||
+ | | class="col2 centeralign" | short | ||
+ | | class="col3 centeralign" | Server -> Client | ||
+ | |} | ||
+ | |||
+ | :<h5>Affect on BulkBlockUpdate</h5> | ||
+ | Although the affect on most packets is straightforward, the changes to '''BulkBlockUpdate''' requires a more thorough explanation: | ||
+ | * The first 256 bytes store the lower 8 bits of the ID for each of the 256 blocks. | ||
+ | * The remaining 256 bytes store the higher 8 bits of the ID for each of the 256 blocks. | ||
+ | :(Comments go here, please sign them) | ||
+ | Most of this is copy/pasted from ExtendedBlocks v1, though BulkBlockUpdate has been updated to support the new blocks. This probably also needs the ability for more than 512 textures, but that's a seperate packet. Also maybe a packet to say how many blocks server/client supports? Also also, feel free to edit this; just sign on the top too. [[User:Infernity|Infernity]] ([[User talk:Infernity|talk]]) 17:19, 15 June 2022 (UTC) | ||
− | === | + | ===ExtServerMessages=== |
− | :Proposed by [[User: | + | :Proposed by [[User:Rainb0wSkeppy|Rainb0wSkeppy]] ([[User talk:Rainb0wSkeppy|talk]]) 22:43, 20 June 2023 (UTC) |
− | : | + | :Allows the server to remove, insert and replace messages, set the background and foreground color of the messages, and send messages longer then 64 characters |
− | :'''Motivation''': To allow | + | :'''Motivation''': To allow the server to send messages longer then 64 characters, highlight parts of chat by changing the background color and to edit and delete messages after they have been sent (eg. a moderator removing messages that break the rules) |
− | :'''Client Behavior''': | + | :'''Client Behavior''': The client must read 2 characters after the &, the first one is the foreground and the second one is the background, When the server sends a message, the client inserts in the correct place, When the Position field is 0xff the client should not send a message until the Position field isn't 0xff, then concatenate the messages, When the server sends a DeleteMessage packet, it deletes the specified message |
− | + | :'''Server Behavior''': The server may send messages with the Position field and send DeleteMessage packets | |
− | + | :<h4>ExtServerMessage packet</h4> | |
− | + | :''Server to client'' | |
− | |||
− | |||
− | |||
− | |||
− | :'''Server Behavior''': | ||
− | <h4> | ||
− | :''Server to | ||
:{| class="wikitable" | :{| class="wikitable" | ||
|- class="row0" | |- class="row0" | ||
Line 431: | Line 1,536: | ||
! class="col4" | Notes | ! class="col4" | Notes | ||
|- class="row1" | |- class="row1" | ||
− | | class="col0 centeralign" | ?? | + | | class="col0 centeralign" rowspan="3" | 0x?? |
− | | class="col1 centeralign" | | + | (??) |
+ | | class="col1 centeralign" | Position | ||
| class="col2 centeralign" | byte | | class="col2 centeralign" | byte | ||
| class="col3 centeralign" | 0 | | class="col3 centeralign" | 0 | ||
− | | class="col4 centeralign" | 0 | + | | class="col4 centeralign" | The position of the message. 0 is after the last message, 1 is between the last and the 2nd last message, 2 is between the 2nd last and the 3nd last message, etc. Position of 255 means the message should not be shown and should be concatenated with the next ExtServerMessage packet. |
− | 1 | ||
|- class="row2" | |- class="row2" | ||
+ | | class="col1 centeralign" | Message | ||
+ | | class="col2 centeralign" | string | ||
+ | | class="col3 centeralign" | &70Rainb0wSkeppy: &f0hi | ||
+ | | class="col4 centeralign" | The message to be sent | ||
+ | |- class="row3" | ||
! class="col0" | Total Size: | ! class="col0" | Total Size: | ||
− | | class="col1 rightalign" colspan="4" | | + | | class="col1 rightalign" colspan="4" | 66 bytes |
|} | |} | ||
− | + | :<h4>DeleteMessage packet</h4> | |
− | + | :''Server to client'' | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | : | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | <h4> | ||
− | :''Server to | ||
:{| class="wikitable" | :{| class="wikitable" | ||
|- class="row0" | |- class="row0" | ||
Line 502: | Line 1,563: | ||
| class="col0 centeralign" rowspan="3" | 0x?? | | class="col0 centeralign" rowspan="3" | 0x?? | ||
(??) | (??) | ||
− | | class="col1 centeralign" | | + | | class="col1 centeralign" | Position |
| class="col2 centeralign" | byte | | class="col2 centeralign" | byte | ||
− | | class="col3 centeralign" | | + | | class="col3 centeralign" | 0 |
− | | class="col4 centeralign" | | + | | class="col4 centeralign" | The position of the message. 0 is the last message, 1 is the 2nd last message, 2 is the 3nd last message, etc. |
− | |||
− | |||
− | |||
− | |||
− | |||
|- class="row3" | |- class="row3" | ||
! class="col0" | Total Size: | ! class="col0" | Total Size: | ||
− | | class="col1 rightalign" colspan="4" | | + | | class="col1 rightalign" colspan="4" | 2 bytes |
|} | |} | ||
+ | |||
+ | :(Comments go here, please sign them) |
Latest revision as of 13:25, 14 January 2024
Contents
- 1 Template
- 2 Proposals
- 2.1 PlaySound
- 2.2 ClientRedirection
- 2.3 ColorCodeControl
- 2.4 UnicodeChat
- 2.5 SelectionCuboid v2
- 2.6 Player Animation
- 2.7 PlayerHealth
- 2.8 ExtPlayerList v3
- 2.9 HackControl v2
- 2.10 MessageTypes v2
- 2.11 ExtMapInfo
- 2.12 BlockDefinitionsExt2
- 2.13 SoundControl
- 2.14 WebSocketsSupport
- 2.15 ExtDirection
- 2.16 ClientRedirection r2
- 2.17 DefineQuad
- 2.18 TexturePackExt
- 2.19 BlockDefinitions v2
- 2.20 ScreenElements
- 2.21 ExtendedBlocks v2
- 2.22 ExtServerMessages
Template
Add your proposal at the end of the page. Please use existing extensions as your guide to formatting. Please sign your proposals and comments by ending it with ~~~~
.
===ExtensionName=== :Proposed by ~~~~ :Brief summary of the extension. :'''Motivation''': Explain why this is needed or how it is useful. :'''Client Behavior''': Detailed description of all new behavior that game clients need to implement in order to support this extension. Consider interaction with other extensions. :'''Server Behavior''': Detailed description of all new behavior that game servers need to implement in order to support this extension. Consider interaction with other extensions. :(Packet definitions, remarks, illustrations, and data tables go here) :(Comments go here, please sign them)
Proposals
PlaySound
- Proposed by !!!WARLOCK!!!
- This extension allows server to play custom sound and musics on client.
- Motivation: Servers can play custom musics or sound effects just in time or when something changes. Useful for gamemodes such as zombie survival, Servers can play zombie moaning sound while zombies are close to players. Player join and leave sounds, Kill streak sounds for games such as CTF, Radio and DJ class for players and sound effects for explosions and player deaths.
- Client Behavior: Client must download and load, or load the sound directly from the URL with the ID. Client must be able to download any time after MapFinalize has sent. If the URL is empty then the Client must unload the sound with that ID. Client must unload the sound and load a new one if there's a sound with existing ID. Client must be able to play the sound right after receiving the PlaySound packet. The last playing sound can not be ignored or stopped when a new sound is going to be played. Files type must be in .WAV, otherwise they're ignored. Client must ignore downloading the existing files from Server if they're saved in drive. Client must not change the volume of all environments (Place/Destroy, Walk sounds) on SetVolume packet. Client must change a local variable for volume of next playing sound on SetVolume packet.
- Server Behavior: Server must ignore sending the same url multiple times. Server can not send quick loops of sound due to network speed and client crash possibility. It's better to load all of required sounds after map load for better performance. Server must not send high sized file cause of time and speed it takes for download. Files type must be in .WAV, otherwise they're ignored. Server can change the volume before playing a sound. For a better networking, It's suggested to not send PlaySound instead of changing volume to zero.
LoadSound packet
- Server to client
Packet ID Field Name Field Type Example Notes 0x?? (??)
ID byte 143 Gives the URL an ID. URL string http://site.com/firstblood.wav Address to a .WAV file, put this empty for unload. Total Size: 66 bytes
PlaySound packet
- Server to client
Packet ID Field Name Field Type Example Notes 0x?? (??)
ID byte 125 Plays the sound saved as ID. Total Size: 2 bytes
SetVolume packet
- Server to client
Packet ID Field Name Field Type Example Notes 0x?? (??)
Percent byte 87 Set the next playing sound(s) volume to a Percentage. Total Size: 2 bytes
ClientRedirection
- Proposed by Sysr q (talk) 10:17, 12 May 2014 (UTC)
- This extension allows servers to give clients a redirection to a separate, possibly "private" server.
- Motivation: Allowing servers to redirect clients would be useful in several cases. Allowing a singular "hub" server to redirect players to various external (but related) servers depending on the gamemode they wish to play would allow tightly integrated networks. If servers are using an external "balancer" or some sort of Minecraft-aware proxy, the server could signal the proxy move its connection on the client's behalf to another server.
- Client Behavior: Clients should be ready to receive a ClientRedirection packet any time after they receive a LevelFinalize packet. When clients receive a ClientRedirection packet, they should prompt the user with a message indicating the server they're being redirected too, and allow the user to continue or quit. Non-player clients (e.g., proxies) have the option of silently reconnecting on the client's behalf. Clients should then open a new connection to the newly redirected server, and begin standard negotiation protocol.
- Server Behavior: Servers should only send a ClientRedirection packet after the they have sent a LevelFinalize packet. They should ensure the new server the client is being redirected to exists, and preferably is online and available.
ClientRedirection packet
- Server to client
Packet ID Field Name Field Type Example Notes 0x?? (??)
Address string mc.example.org Can be an IP address (IPv4/IPv6) or a hostname. Port int 25565 Name string Joe Blogg's Freebuild (optional) User-friendly name to be displayed in user prompt. Total Size: 133 bytes
ColorCodeControl
- Proposed by F (talk) 22:00, 28 August 2014 (UTC)
- Gives servers an option to allow players to type in color codes, and a way to render
&
character in chat. - Motivation: Allow players to type in color codes and to use & in chat.
- Client Behavior: When this extension is mutually supported, treat character sequence
&&
as meaning "draw an&
character", without modifying current color. Do not allow&
to be typed or pasted into chat unless ColorCodeControl packet has been received with AllowColorCodes set to1
. - Server Behavior: When this extension is mutually supported, server may send ColorCodeControl packet to allow client to type or paste color codes. Server should treat
&&
as described above.
ColorCodeControl packet
- Server to Client
Packet ID Field Name Field Type Example Notes ?? AllowColorCodes byte 0 0 = disallow 1 = allow
Total Size: 2 bytes
UnicodeChat
- Proposed by F (talk) 22:48, 28 August 2014 (UTC)
- Expands character encoding beyond ASCII. There are three ways to go about this:
- Expand charset to 256 characters using Win-1252.
- Pro: Easiest to implement in clients (few changes to FontRenderer needed) and servers (no multibyte character support needed).
- Pro: No new packets needed.
- Pro: Easy to create custom fonts.
- Pro: Easy for servers to maintain compatibility with legacy clients, since only 128 characters need to be remapped, most of which have decent ASCII matches.
- Pro: Low resource use (low RAM and VRAM use, no additional CPU use, small font file).
- Con: Still only 256 characters. Only covers Latin-derived (English and Western/Central European) languages and common symbols.
- Expand charset to Unicode Basic Multilingual Plane (BMP) with UCS-2 fixed-length encoding.
- Pro: Lots of characters (~65k) covering most languages and symbols.
- Pro: Not too hard to implement (characters still fixed-width, native support in WinAPI / Java / C#).
- Pro: Free fonts available that covers all characters.
- Con: New renderer (possibly third-party library) needed for rendering.
- Con: Higher resource use (higher RAM and VRAM use, more CPU use, large font file).
- Con: Very hard to create custom fonts.
- Con: Still does not cover all characters.
- Con: Hard for servers to maintain compatibility with legacy clients.
- Con: Always uses 2 bytes per character for transmission (twice as much as ASCII/CP-1252).
- Expand charset to Unicode Basic Multilingual Plane (BMP) with UTF-8 variable-length encoding.
- Pro: Lots of characters (~65k) covering most languages and symbols.
- Pro: Not too hard to implement (characters can be freely converted to/from UCS-2, which is natively support in WinAPI / C#).
- Pro: Free fonts available that covers all characters.
- Pro: Uses 1 byte per character for transmission, most of the time.
- Con: New renderer (possibly third-party library) needed for rendering.
- Con: Higher resource use (higher RAM and VRAM use, more CPU use, large font file).
- Con: Hard to create custom fonts (unless some fallback rules are implemented).
- Con: Still does not cover all characters.
- Con: Hard for servers to maintain compatibility with legacy clients.
- Expand charset to full Unicode with UTF-8 variable-length encoding. Includes all the supplemental Unicode planes.
- Pro: Widely used in other software.
- Pro: Theoretically covers all languages and symbols.
- Pro: Uses 1 byte per character for transmission, most of the time.
- Con: Does not actually cover all languages and symbols due to non-existence of 100% fonts.
- Con: Hard to find free fonts that extend beyond the BMP.
- Con: Harder to work with strings (due to variable-width characters).
- Con: Third-party library needed for rendering.
- Con: Highest resource use (highest RAM and VRAM use, most CPU use, largest font files).
- Con: Hardest to implement (no native support in WinAPI / C#).
- Con: Hard to create custom fonts (unless some fallback rules are implemented).
- Con: Hard for servers to maintain compatibility with legacy clients.
- Expand charset to 256 characters using Win-1252.
SelectionCuboid v2
- Proposed by FabTheZen, classic1234 and Rayne
- Motivation: Allows the server to not only highlight parts of a world, but also determine whether those regions are walk through or not. This could be used to disallow players to walk inside restricted areas or zones which they are not allowed to build in. It could also be used as a jail when accompanied with the '-hax' option.
- Client behavior: The client must receive the SelectionCuboid extension with version 2. It must also determine whether any selections on the map walk through or not.
- Server behavior: The server behaves the same way SelectionCuboid v1 does.
MakeSelection packet v2
- Server to Client
Packet ID Field Name Field Type Example Notes 0x?? (??)
SelectionID byte 0
Numeric ID of the selection. Between 0 and 127. Label string SomeZone
Text label associated with the selection StartX short 1
X coordinate of the starting point StartY short 2
Y coordinate of the starting point StartZ short 3
Z coordinate of the starting point EndX short 5
X coordinate of the ending point EndY short 6
Y coordinate of the ending point EndZ short 7
Z coordinate of the ending point Red short 255
Between 0 and 255. Green short 34
Between 0 and 255. Blue short 128
Between 0 and 255. Opacity short 255
0 = fully transparent 255 = fully opaque
Walkthrough byte 0
0 = Not walkthrough 1 = Walkthrough
Total Size: 87 bytes
Player Animation
- Proposed by ByteBit
- Let the player to do certain actions/animations on the client
- Motivation: Other players will be able to see the block another is holding or whether one placed a block or not. It makes the game's feel more realistic, because blocks don't pop out a no where.
- Client Behavior: On recieve the client should perform the actions required for the animation.
- Server Behavior: The server may send the packet if needed any time after the map is send.
AnimatePlayer packet
- Server to Client
Packet ID Field Name Field Type Example Notes 0xAC (172)
Animation Type byte 1 Specifies what animation to perform (0: Hold block; 1: Set block; 2: Destroy block; 3: Player name visibility) Player ID byte 1 What player to perform this animation on Additional byte byte 49 (Obsidian) Needed for specific animations (Block type for 0,1 and 2; for 3: true(1)/false(0)) Total Size: 3 bytes
PlayerHealth
- Proposed by Apotter96 (talk) 02:29, 26 July 2015 (UTC)alex96
- Gives players life count that is controlled by the server and reflected by the client at the top left of the game screen. The server.
- Motivation: RPG and Gun games can go more extensive if they wish with lives.
- Client Behavior: Display player's lives at the top left of screen when the server sends the packet. On player connect, the server needs to tell the client the max amount of lives the player can have, in between 5 and 20. May also dictate how many lives the server is allowed to send. Both need to check with the other end so they can comply together.
- Server Behavior: At any time the server can send the packet telling the client the amount of lives the player has. Once a player connects, the server needs to tell the client how many lives the player is allowed to have, in between 5 and 20. Both need to check with the other end so they can comply together.
UpdateLives packet
- Server to client
Packet ID Field Name Field Type Example Notes 0x?? (??)
Lives int 15 How many lives the player has MaxLives int 15 The Max amount of lives Total Size: 2 bytes
UpdateLives packet
- Client to server
Packet ID Field Name Field Type Example Notes 0x?? (??)
MaxLives int 15 The Max amount of lives Total Size: 2 bytes
- (Comments go here, please sign them)
ExtPlayerList v3
- Proposed by Cheesse
- This extension builds upon the current version and adds the ability to change the visibility of name tags.
- 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 ExtAddEntity3/DespawnPlayer packets are used only to manage in-game entities.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 ExtAddEntity3/DespawnPlayer packets are used only to manage in-game entities.
- Client Behavior: When ExtAddPlayerName packet is received for an unused NameID, a new name must be added to the player-name list. When receiving ExtAddPlayerName packet for an already-listed NameID, client must update its ListName, GroupName, and GroupRank. Names on the player-name list should be grouped by GroupName in the player-name 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. Color codes may be either drawn or stripped from ListName, GroupName, and InGameName. Player-name list must persist when client changes worlds/maps.
- When an ExtAddEntity3 packet is received, it must be treated as the SpawnPlayer packet. A player model must be spawned in-game at the given location, with InGameName text drawn above it. Skin should be loaded using the given SkinName for a player name. If SkinName appears to be a player name, skin should be downloaded from the default skin server. If SkinName appears to be a full URL to a PNG image (starts with
http://
orhttps://
and ends with.png
) then skin should be downloaded from that URL. If image is correctly sized/proportioned to use as a skin for the current model, it should be used. If a blank or unrecognized value is given for SkinName, or if given image could not be downloaded or used, then the default skin should be used. The client must also set the visibility according to NameVisibility and the collision ability of the entity according to CanCollide. When client receives ExtAddEntity3 packet for an already-spawned player, a duplicate entity must not be spawned and existing entity's position must not be changed. Instead their InGameName, SkinName, NameVisibility, and CanCollide attributes must be updated. If a negative EntityID is given for ExtAddEntity3, client must update player's own spawn point, InGameName, and SkinName. If any undefined value is given in the NameVisibility or CanCollide fields, the client should ignore these fields. The client must ignore regular SpawnPlayer packets, if any are received.
- When a standard DespawnPlayer packet is received for a recognized EntityID, player model must be removed from a world. When ExtRemovePlayerName packet is received for a recognized NameID, their name must be removed from player-name list. Packets with out-of-range or unrecognized NameIDs must be ignored.
- In-game entities must never be affected by ExtAddPlayerName or ExtRemovePlayerName packets. Player name list must never be affected by ExtAddEntity3 or DespawnPlayer packets.
- Server Behavior: Unique NameID between 0 and 255 should be assigned to every online player or every player on a map for each map. When a new player connects to the server or joins a new map, 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 ExtAddEntity3 in place of standard SpawnPlayer packet. Server should re-send ExtAddPlayerName packet, using the identical NameID, when player's ListName, GroupName, or GroupRank change. Server must reliably send an ExtRemovePlayerName packet when the player disconnects. Color codes are permitted in ListName, GroupName, and InGameName.
- This extension only replaces the ExtAddEntity2 packet of the ExtPlayerList extension version 2. Thus, only the ExtAddEntity3 packet is shown here.
ExtAddEntity3 packet
- Server to client
Packet ID Field Name Field Type Example Notes 0x?? (??)
EntityID byte 5
Between 0 and 127 InGameName string &cNotch
Player name to be shown in-game hovering above the player. SkinName string Notch
Name of the skin that should be used by the client. Could also be a URL to a PNG image. SpawnX short 1
X coordinate (32 units per block) of entity's spawn location. SpawnY short 2
Y coordinate (32 units per block) of entity's spawn location. SpawnZ short 3
Z coordinate (32 units per block) of entity's spawn location. SpawnYaw byte 4
Orientation (left-right) at the entity's spawn location. SpawnPitch byte 5
Orientation (up-down) at the entity's spawn location. NameVisibility byte 6
Visibility of the InGameName of the entity. Obstacles can be blocks or other entities. - 0 = (Default) Visible only by hovering the cursor over the entity within view. Ignores any obstacles in the way.
- 1 = Visible only by hovering the cursor over the entity within view. Invisible when obstacles block the entity.
- 2 = Always visible within view (name tag shrinks over distance). Ignores any obstacles in the way.
- 3 = Always visible within view (name tag shrinks over distance). Invisible when obstacles block the entity.
- 4 = Always visible anywhere (name tag does not shrink over distance). Ignores any obstacles in the way.
- 5 = Always visible anywhere (name tag does not shrink over distance). Invisible when obstacles block the entity.
- 6 = Never visible.
CanCollide byte 0
- 0 = (default) Can collide with the player.
- 1 = Cannot collide with the player.
Opacity byte 255
From 0-255, the overall opacity of the entity model. Total Size: 140 bytes
- (Comments go here, please sign them)
HackControl v2
- Proposed by Cheesse
- This extension allows more control over the abilities of players.
- Motivation: To gain control over the movement and action abilities of players.
- Client Behavior: Client must be able to receive HackControl2 packets at any time and apply the changes defined in the packet immediately. Any value may be given in any field to allow or adjust an ability. If a negative value is given in any field, the client should set that value to its default. If
0
is given in any field, the client must deactivate that ability and prevent its use by the player unless otherwise stated. - Server Behavior: Server may send HackControl2 packets to successfully connected clients at any time.
HackControl2 packet
- Server to client
Packet ID Field Name Field Type Example Notes 0x?? (??)
FlySpeed byte 0
This value is divided by 25 and multiplied by the default speed of flight to get the custom speed of flight. A value of 255 means there are no restrictions on flight. A value of 0 means flight is not allowed. NoClip byte 0
- 0 = Prevent no-clipping
- 1 = Allow no-clipping
WalkSpeed byte 64
This value is divided by 25 and multiplied by the default walking speed to get the custom walking speed. A value of 255 means there are no restrictions on walking speed. A value of 0 means the player is not allowed to walk. RunSpeed byte 16
This sets the speedhacking capabilities of the player. This value is divided by 25, then added to 1, then multiplied by the default walking speed to get the custom running speed. A value of 255 means there are no restrictions on running speed. A value of 0 means the player is not allowed to run. AllowRespawn byte 1
- 0 = Prevent respawning
- 1 = Allow respawning
PointOfView byte 0
- 0 = First-person view
- 1 = Third-person behind view
- 2 = Third-person front view
Setting this field to a defined value will prevent the player from changing their point of view. Setting it to an undefined value will allow the player to switch points of view.
JumpHeight byte 40
Maximum height in player units of the player's normal jump. A value of 0 means the player is not allowed to jump. A value of 255 means there are no restrictions on jump height. SuperJumpHeight byte 100
Maximum height in player units of any other jump abilities the player has, like using speed to get a higher jump. A SuperJumpHeight value of 0 means the player is not allowed to superjump. A value of 255 means there are no restrictions on jump height. Total Size: 9 bytes
- (Comments go here, please sign them)
MessageTypes v2
- Proposed by Cheesse
- This extension adds new ways of presenting information to the player.
- Motivation: To allow the server to send messages in different places and for limited times.
- Client Behavior: Client must interpret the PlayerID field of the standard Message packet as the Message Type field. Certain values in this field correspond to different locations for messages on the screen. Any undefined values in this field should be ignored and presented as regular chat messages. Without mutual server-client support for this extension, this field should be ignored.
- Server Behavior: Server may use the PlayerID field of the Message packet to have that message placed at a certain location on the player's screen.
MessageType Value Meaning Message Placement 0 Chat In the chatbox. 1 Status1 At the top right of the screen. 2 Status2 At the top right of the screen below Status1. 3 Status3 At the top right of the screen below Status2. 11 BottomRight1 At the bottom right of the screen. 12 BottomRight2 At the bottom right of the screen above BottomRight1. 13 BottomRight3 At the bottom right of the screen above BottomRight2. 45 LeftHotbar On top of the hotbar aligned to the left. 54 RightHotbar On top of the hotbar aligned to the right. 100 BigAnnouncement In large font slightly above the center of the screen. 200 SmallAnnouncement Near the center of the screen below BigAnnouncement.
This extension does not define any new packets.
- (Comments go here, please sign them)
ExtMapInfo
- Proposed by Cheesse
- This extension allows the server to send the client some of the map's metadata and other information
- Motivation: To allow clients to save metadata with the maps they choose to save. This extension can also be modified to add more features to maps.
- Client Behavior: Client must be able to receive FinalMapInfo packets at any time after a LevelInitialize packet has been received and before a FinalMapInfo packet has been received. Client should store the values in these fields in memory to be used later. The metadata defined in these fields come from those defined in the ClassicWorld file definitions. Client should ignore any LevelFinalize packets recieved.
- Server Behavior: Server must send FinalMapInfo packets with the correct values after it has finished sending the client the raw block data after sending a LevelInitialize packet. The server should not send this packet at any other time. The server should never send any LevelFinalize packets to the client.
FinalMapInfo packet
- Server to client
Packet ID Field Name Field Type Example Notes 0x?? (??)
"FormatVersion byte 1
The FormatVersion is currently set to 1. "MapName" string main
The name of the map. "UUID" byte array [16] abcdefghijklmnop
The UUID of the map. "XSize" short 128
The length of the map in the X dimension. "YSize" short 128
The length of the map in the Y dimension. "ZSize" short 128
The length of the map in the Z dimension. "CreatedBy" string Cheesse
The name of the author of the map. This should be an existing Classicube username. "MapGenSoftware" string Mapbuilder
The name of the software used to generate the map. "MapGenName" string Flat
The name of the generator function used to generate the map. "TimeCreated" long 1234567890
The UTC Unix timestamp of the time the map was generated. "TimeLastModified" long 1234567890
The UTC Unix timestamp of the time the map was last modified. Total Size: 298 bytes
- (Comments go here, please sign them)
BlockDefinitionsExt2
- Proposed by Goodly.
- This extension allows servers to define more properties for the custom blocks provided by BlockDefinitions.
- Motivation: To allow for better custom blocks to be created.
- Client Behavior: This extension depends on BlockDefinitions extension and BlockDefinitionsExt extension, and must only be enabled if BOTH extensions are mutually supported. Client should be able receive any number of DefineBlockExt2 packets during the level loading process (after receiving LevelInitialize and until receiving LevelFinalize packets). However, dependent on client, this can be sent after level loading (Some clients might just find it more extensible than others).
- Client must be able to accept and render blocks as specified in DefineBlockExt2 packets. Clients must accept any valid definitions with BlockID between 1 and 254, inclusive. If a new definition is accepted for an already-defined BlockID, the old definition should be replaced.
DefineBlockExt2 Packet
- Server to Client
Field Name Field Type Example Notes RandomOffset byte 1
Whether or not the block is randomly offset. - 0 = Not offset (No change).
- 1 = Randomly offset on the X and Z axis from -3/16 to 3/16.
- 2 = Randomly offset on the Y axis from -3/16 to 3/16.
- 3 = Randomly offset on the Y axis from -3/16 to 0.
- 4 = Randomly offset on the X, Y and Z axis from -3/16 to 3/16
- 5 = Randomly offset on the X and Z axis from -3/16 to 3/16 and randomly offset on the Y axis from -3/16 to 0.
Note: This only effects blocks which have the "Shape" as 0 (sprite)
FatSprite byte 1
Whether or not the sprite is stretched closer to the edge of the block, similar to premium. - 0 = Not fat (No change).
- 1 = The corners of the sprite are stretched from 0.8 to 15.2. (Instead of the original values of 2.50 to 13.5.)
Note: This only effects blocks which have the "Shape" as 0 (sprite)
Selectable byte 0
Whether or not the block/liquid becomes highlighted when pointed at it (Like how liquids are not breakable or selectable by default). - 0 = Not select-able.
- 1 = Selectable. (No change)
Replaceable byte 1
Whether or not the client is able to reach through and place blocks inside of the the block/liquid. - 0 = No change from original behavior
- 1 = The block can be reached through when placing blocks and can be overwritten if a block is placed inside of it. (Similar to liquid)
Red byte 255
Red component that the block is multiplied by. Green byte 109
Green component that the block is multiplied by. Blue byte 255
Blue component that the block is multiplied by. Total Size: 8 bytes
SoundControl
- Proposed by Cheesse
- This extension allows the client to play music and sounds defined by the server.
- Motivation: To create a more stimulating experience by adding custom sounds and music to the game.
- Client Behavior: The client must be able to receive any packets defined by this extension at any time. It must not play any music unless ordered by the server. It must dispose of any unloaded custom audio or store it in an unusable format. Loops must be played on a loop. Defined BlockSounds must be available for use by custom block types, and any local placement or deletion of a block or any local footsteps on that block that uses custom BlockSounds should have the custom sound played simultaneously. Sounds being played by the PlayEntityLoopSource and PlayEntitySFX must have their sources move with the entity. The client should play SFX ordered by the server immediately after receiving any PlaySFX, PlayLevelSFX, or PlayEntitySFX packet. If the client receives an undefined value for any packet, that packet should be ignored. When a custom audio file is defined within a default slot, the client should return the default audio to that slot when it becomes undefined.
- Server Behavior: The server may send any packets defined by this extension at any time, however, it is recommended that the server defines all sounds during the level loading phase. All audio defined only for a specific level must be unloaded by the server upon client leaving the level. Defined custom BlockSounds must be available for use by custom blocks. The PlayEntityLoopSource and PlayEntitySFX packets allow servers to attach the source of a sound to an entity. This makes it easier for servers to play "moving" sounds without having to send too much data. All audio files linked by the server must be in .ogg format. All loops MUST have a length longer than 10 seconds. The server is responsible for not infringing upon copyright and licensing.
DefineMusic packet
- Server to client
Packet ID Field Name Field Type Example Notes 0x?? (??)
SongID byte 0
Valid IDs are from 0-255. IDs for default music are as follows: 0=calm1, 1=calm2, 2=calm3, 3=hal1, 4=hal2, 5=hal3, 6=hal4. Default music may be redefined by the server. SongSource string http://www.abc.com/song.ogg
The location of the music file online. The link must lead to a .ogg file. If this field contains only "X" (case-sensitive), the music of the SongID within the SongCategory must be unloaded. If this field contains only "A" (case-sensitive), all music defined within the SongCategory must be unloaded. Otherwise, the client should do nothing. Total Size: 66 bytes
DefineBlockSound packet
- Server to client
Packet ID Field Name Field Type Example Notes 0x?? (??)
BlockSoundID byte 8
This is a bitfield where the 14 most significant bits represent the "block type" (such as wood, metal, grass) and the 2 least significant bits represent IDs for each individual sound (think of the different sounds for stone blocks). BlockSoundSource string http://www.abc.com/water.ogg
The location of the loop file online. The link must lead to a .ogg file. If this field contains only "X" (case-sensitive), the audio for that specific BlockSoundID must be unloaded. If this field contains only "A" (case-sensitive), all sounds with the same "block type" must be unloaded. Otherwise, the client should do nothing. Total Size: 66 bytes
DefineLoop packet
- Server to client
Packet ID Field Name Field Type Example Notes 0x?? (??)
LoopID byte 3
Valid IDs are from 0-255. LoopSource string http://www.abc.com/cavenoise.ogg
The location of the loop file online. The link must lead to a .ogg file. If this field contains only "X" (case-sensitive), the audio for the LoopID must be unloaded. Otherwise, the client should do nothing. Total Size: 66 bytes
DefineSFX packet
- Server to client
Packet ID Field Name Field Type Example Notes 0x?? (??)
SFXID byte 0
Valid IDs are from 0-255. SFXSource string http://www.abc.com/killstreak.ogg
The location of the music file online. The link must lead to a .ogg file. If this field contains only "X", the sound of the SFXID must be unloaded. Otherwise, the client should do nothing. Total Size: 66 bytes
PlayMusic packet
- Server to client
Packet ID Field Name Field Type Example Notes 0x?? (??)
SongID byte 0
SongID must be defined. Volume byte 100
From 0-200, the volume at which to play the music. Fade byte 0
This is a bitfield from 0-7 with 7 being the most significant bit. Bits 0-3 are for the period taken for the song to fade in. Valid values for this are from 0-15 (in seconds). Bits 4-7 are for are for the fade out, and the values for this are from 0-15 (in seconds). Loop byte 0
From 0-254, the position from the start, in tenths of a second, at which the music should return after the end is reached. If this field is 255, then the song does not loop. Total Size: 5 bytes
PlayLevelLoopSource packet
- Server to client
Packet ID Field Name Field Type Example Notes 0x?? (??)
LoopID byte 0
LoopID must be previously defined. If a different loop was playing at a position defined by PositionX, -Y, and -Z, then the client must replace that loop with this one. Volume byte 100
From 0-200, the volume at which to play the sound effect. If the volume is set to 0, the client must not play any loops at that position, especially if one was playing there before. PositionX short 20
The X-coordinate of the position of the source of the loop on the level (in player coordinates). PositionY short 20
The Y-coordinate of the position of the source of the loop on the level (in player coordinates). PositionZ short 20
The Z-coordinate of the position of the source of the loop on the level (in player coordinates). Total Size: 9 bytes
PlayEntityLoopSource packet
- Server to client
Packet ID Field Name Field Type Example Notes 0x?? (??)
LoopID byte 0
LoopID must be previously defined. If a different loop was playing from an entity with ID EntityID, the client must replace that loop with this one. Volume byte 100
From 0-200, the volume at which to play the sound effect. If the volume is set to 0, the client must not play any loops from that entity, especially if one was playing there before. EntityID byte 1
The ID of the entity from which the loop should be played. Total Size: 4 bytes
PlaySFX packet
- Server to client
Packet ID Field Name Field Type Example Notes 0x?? (??)
SFXID byte 0
SFXID must be defined. Volume byte 100
From 0-200, the volume at which to play the sound effect. Total Size: 3 bytes
PlayLevelSFX packet
- Server to client
Packet ID Field Name Field Type Example Notes 0x?? (??)
SFXID byte 0
SFXID must be defined. Volume byte 100
From 0-200, the volume at which to play the sound effect. PositionX short 100
The X-coordinate of the position of the source of the loop on the level (in player coordinates). PositionY short 100
The Y-coordinate of the position of the source of the loop on the level (in player coordinates). PositionZ short 100
The Z-coordinate of the position of the source of the loop on the level (in player coordinates). Total Size: 9 bytes
PlayEntitySFX packet
- Server to client
Packet ID Field Name Field Type Example Notes 0x?? (??)
SFXID byte 0
SFXID must be defined. Volume byte 100
From 0-200, the volume at which to play the sound effect. EntityID byte 3
The ID of the entity from which the sound effect should be played. Total Size: 4 bytes
- (Comments go here, please sign them)
WebSocketsSupport
- Proposed by Maxouf0x (talk) 06:18, 3 August 2017 (UTC)
- Add websocket support to the minecraft classic protocol.
- Motivation: Make web clients without having to use webtcp.
- Client Behavior: Clients that use web socket must send a normal HTTP GET request to http://<server IP>:<server port>/connect, When the client recive the redirect, it must open a websocket connection to the recived URL, and continue with the normal protocol, wrapped in a websocket.
- Server Behavior: Server supporting websockets must check if the client has sent an HTTP GET request before sending the Server Identification package. If the client has sent an HTTP GET request to /connect, the web socket integration is disabled, but implemented, the server must respond with a 503 error code. If the websocket integration is enabled, the server must respond with a 302 code, redirecting to http://<server IP>:<server Port/Other port>/game. When the server recives a websocket connection to http://<server IP>:<server Port/Other port>/game, it must continue with the normal protocol, wrapped in a websocket.
- The port used to request /connect is the same as the game port, so that this doesn't break the current heartbeat system.
This extension does not define any new packets.
- (Comments go here, please sign them)
what? WebSockets are already supported.
TheAwesome98 (talk) 17:23, 6 November 2021 (UTC)
ExtDirection
- Proposed by Cheesse
- Increases the precision of direction data sent in all player position/orientation packets.
- Motivation: Improve the precision of player rotation for servers that require high precision.
- Client Behavior: The client must write unsigned shorts instead of bytes for the Yaw and Pitch fields of the PositionAndOrientation packet and any other packet that contains entity direction data.
- Server Behavior: The server must write unsigned shorts instead of bytes for the Yaw and Pitch fields of the SpawnPlayer, PositionAndOrientation, PositionAndOrientationUpdate, and OrientationUpdate packets and any other packet that contains entity direction data.
- This extension does not define any new packets.
ClientRedirection r2
- Proposed by Galaxtone (talk) 05:32, 21 January 2019 (UTC)
- The extensions allows servers to redirect clients to other servers.
- Motivation: Allowing servers to redirect clients to other trusted sub-servers or a completly different server, Useful for hub servers leading to smaller sub-servers and even for sudden creation of private servers to connect to, and for the proxies themselves implement extension support.
- Client Behavior: After extension negotiation, the client must send a Redirection packet (Specifies the redirecting server, blank if directly connected) to the server, afterwards the client must be able to receive a Redirection packet at any time, upon receiving the packet (Ignoring if blank), the client may deny the redirection by doing nothing, otherwise the client must disconnect from the server and reconnect to the specified server.
- Server Behavior: After extension negotiation, the server must wait for a Redirection packet from compatible clients before sending level data, afterwards the server may then send the Redirection packet at any time.
Redirection packet
- Bidirectional
Packet ID Field Name Field Type Example Notes 0x?? (??)
Server Hash String 226fb815f216daf4d0ef653bc32c6b89
32 base-36 characters. Total Size: 65 bytes
- Note: This is the second revision of this extension proposal, not the second version of the extension.
DefineQuad
- Proposed by Cybertoon
- This extension allows you to define extra quads for a block.
- Motivation: This would allow blocks that have more than one quad. So-called "block model".
- Client Behavior: The client would render the extra quads given by this packet for a block, with the textures defined by this packet. Requires support for BlockDefinitionsExt. If the block is discarded with RemoveBlockDefinition, all Quads defined by this packet must also be discarded. If the client supports multiple collisions, if this packet defines collisions, use those instead. If client doesn't, or if none are defined, use the bounds defined in BlockDefinition. If "render" is set to false, this quad will only be used for bounds. If both are false, do nothing. If client doesn't support multiple collisions in a block, do nothing if render is set to false.
- Server Behavior: If client supports extension, send the client the quads, starting with the second quad, then the next, so forth and so forth. This packet must be sent after the block has already been defined.
- DefineQuad packet
Packet ID | Field Name | Field Type | Example | Notes |
---|---|---|---|---|
0x??
(??) |
BlockID | byte | 0
|
The ID of the block this Quad belongs to. Between 1 and 255. |
QuadID | byte | 0
|
Refers to a terrain.png tile.
Between 0 and 255 (unsigned). The ID of the extra quad being defined. Changing Quad 0 will change the quad defined in the BlockDefinition, and the bounds defined there will be the bounding box unless multiple bounding boxes are supported by client. | |
TopTextureId | byte | 0
|
Refers to a terrain.png tile.
Between 0 and 255 (unsigned). Can be same as other texture IDs. This is the texture ID for the Y = 1 face. | |
LeftTextureId | byte | 0
|
Refers to a terrain.png tile.
Between 0 and 255 (unsigned). Can be same as other texture IDs. This is the texture ID for the X = 0 face. | |
RightTextureId | byte | 0
|
Refers to a terrain.png tile.
Between 0 and 255 (unsigned). Can be same as other texture IDs. This is the texture ID for the X = 1 face. | |
FrontTextureId | byte | 0
|
Refers to a terrain.png tile.
Between 0 and 255 (unsigned). Can be same as other texture IDs. This is the texture ID for the Z = 0 face. | |
BackTextureId | byte | 0
|
Refers to a terrain.png tile.
Between 0 and 255 (unsigned). Can be same as other texture IDs. This is the texture ID for the Z = 1 face. | |
BottomTextureId | byte | 0
|
Refers to a terrain.png tile.
Between 0 and 255 (unsigned). Can be same as other texture IDs. This is the texture ID for the Y = 0 face. | |
MinX | byte | 0
|
Minimum X coordinate in pixels. Min allowed is 0, max allowed is 15. | |
MinY | byte | 0
|
Minimum Y coordinate in pixels. Min allowed is 0, max allowed is 15. | |
MinZ | byte | 0
|
Minimum Z coordinate in pixels. Min allowed is 0, max allowed is 15. | |
MaxX | byte | 16
|
Maximum X coordinate in pixels. Min allowed is 1, max allowed is 16. | |
MaxY | byte | 16
|
Maximum Y coordinate in pixels. Min allowed is 1, max allowed is 16. | |
MaxZ | byte | 16
|
Maximum Z coordinate in pixels. Min allowed is 1, max allowed is 16. | |
ColR | byte | 255
|
Red color to filter with. | |
ColG | byte | 255
|
Green color to filter with. | |
ColB | byte | 255
|
Blue color to filter with. | |
Collide | bool | true
|
Whether this quad can collide with this quad. If set to false, this quad will be ignored by colision. If multiple collisions are not supported by the client, use bounds defined in the BlockDefinition. | |
Render | bool | true
|
Whether this quad will render. If set to false, this quad will not render, and will only be used for collision. | |
Total Size: | 18 bytes |
- (Comments go here, please sign them)
TexturePackExt
- Proposed by Galaxtone (talk) 00:59, 27 February 2020 (UTC)
- This extension adds hierarchical texture packs where multiple may be loaded per map and override each other in a distinct order.
- Motivation: Creating texture packs that modify a few assets without having to copy the server's global texture pack assets which would be bulky, impractical and non-portable between servers.
- Client behavior: This extension must be mutually supported along with EnvMapAspect. The client must combine all texture packs, resolving file conflicts between multiple texture packs by using the file from the texture pack with the highest order. The client must treat SetMapEnvUrl packets as texture packs with an order of -1. The client must be able to receive SetMapEnvUrlExt packets at any time appropriate to receive SetMapEnvUrl packets. The EnvMapEnvUrl packet must be used to clear all texture packs as the EnvMapEnvUrlExt packet will set or clear the texture pack at the specified order.
- Server behavior: Server may send SetMapEnvUrlExt packets at any time appropriate to send SetMapEnvUrl packets. To reset all texture packs to the client's default, server has to use the SetMapEnvUrl packet instead.
SetMapEnvUrlExt packet
- Server to Client
Packet ID Field Name Field Type Example Notes 0x?? (??)
Following field from SetMapEnvUrl packet: TexturePackURL TexturePackOrder byte 6
The order of the texture pack. Total Size: 66 bytes
- (Comments go here, please sign them)
BlockDefinitions v2
- Proposed by Jshtab (talk) 19:10, 11 January 2022 (UTC)
- Functionally equal to supporting BlockDefinitionsExt v2. Superceeds BlockDefinitionsExt v2 and BlockDefinitions v1.
- Motivation: Prevent dependency hell, promote consistency.
- Client Behavior: Functionally equal to supporting BlockDefinitionsExt v2.
- Server Behavior: Functionally equal to supporting BlockDefinitionsExt v2. If a client supports BlockDefinitions v1 and BlockDefinitionsExt v2, they support BlockDefinitions v2
- (Comments go here, please sign them)
ScreenElements
- Proposed by DT
- This extension allows the server to define and undefine 2d elements on the client's screen.
- Motivation: It would allow for advanced UI elements and sprites to be drawn to the screen, such as a textured health bar above the hotbar, or a timer at the top of the screen.
- Client Behavior: Clients should be able to define and undefine image and text elements. Client should use sprites.png in the texture pack zip for textured sprites. Client must be able to receive and send all packets. Screen elements should not persist between maps.
- Server Behavior: Servers should be able to send and receive packets to define and undefine image and text elements.
DefineImgElem
- Server to Client
Packet ID Field Name Field Type Example Notes 0x?? (??)
ElemID byte 0
Element ID AnchorX byte 1
The screen anchor along the X axis - 0 = Left
- 1 = Center
- 2 = Right
AnchorY byte 1
The screen anchor along the Y axis - 0 = Top
- 1 = Center
- 2 = Bottom
OffsetX short 24
The X offset from AnchorX OffsetY short -712
The Y offset from AnchorY Source UVCoords (0,5, 10,15)
UV Coords of sprites.png to display Total Size: 16 bytes
DefineTextElem
- Server to Client
Packet ID Field Name Field Type Example Notes 0x?? (??)
ElemID byte 0
Element ID AnchorX byte 1
The screen anchor along the X axis - 0 = Left
- 1 = Center
- 2 = Right
AnchorY byte 1
The screen anchor along the Y axis - 0 = Top
- 1 = Center
- 2 = Bottom
OffsetX short 24
The X offset from AnchorX OffsetY short -712
The Y offset from AnchorY Text string ""
Text to display Scale byte 0
Scale of text being displayed (0 for small, 1 for big) Total Size: 72 bytes
UndefineElem
- Server to Client
Packet ID Field Name Field Type Example Notes 0x?? (??)
ElemID byte 0
Element ID to undefine Total Size: 2 bytes
- (Comments go here, please sign them)
ExtendedBlocks v2
- Proposed by Infernity (talk) 17:19, 15 June 2022 (UTC)
- Allows using more than 768 blocks.
- Motivation: Allows for ever-more-detailed maps by sending up to 65,536 blocks.
- Client Behavior: Clients must adjust how they read the map as described in the Affect on map sending section. Clients must also adjust how they read and write several fields of the packets described in the Affect on other packets section. When a client detects that the secondary map blocks array is used, it must switch from accessing blocks via
map.blocks[index]
tomap1.blocks[index] | (map2.blocks[index] << 8)
instead. - Server Behavior: Servers must adjust how they write the map as described in the Affect on map sending section. Servers must also adjust how they read and write several fields of the packets described in the Affect on other packets section. Ideally, servers should avoid sending a secondary map blocks array when possible to minimise client memory usage.
Affect on map sending
Essentially, instead of LevelDataChunk packets just being used to send the compressed form of the map blocks array, it is repurposed to send both the compressed form of the 'main' map blocks array and optionally a secondary map blocks array. To accomplish this, the Percent Complete field in the LevelDataChunk packet is repurposed. A value of 0 indicates that this LevelDataChunk packet contains part of the compressed data for the 'main' map blocks array, while a value of 1 indicates this LevelDataChunk packet contains part of the compressed data for the optional secondary map blocks array.
The client and server should treat the LevelDataChunk packets used for the 'main' map blocks array as completely separate from the secondary map blocks array, i.e. the 'main' map blocks array should be compressed and decompressed completely independently of the optional secondary map blocks array.
Note: Even if the server only sends a 'main' map blocks array, the client must still be prepared to allocate a secondary map blocks array at any time after map load. For example:
- Client A goes to map XYZ
- Server sends client A just a main blocks array for map XYZ
- A minute later, client B places a block with ID 510 on map XYZ
- Server then broadcasts this block change to all clients on map XYZ
Since a secondary map blocks array was not sent during map load by the server, Client A must now allocate a secondary map blocks array.
Affect on other packets
Several fields in some packets are expanded in size. These are:
Packet Field Name New Type Direction Set Block (0x05) Block type short Client -> Server Set Block (0x06) Block Type short Server -> Client Position and Orientation (0x08) Player ID short Client -> Server HoldThis (0x14) BlockToHold short Server -> Client SetBlockPermission (0x1C) BlockType short Server -> Client DefineBlock (0x23) BlockID short Server -> Client UndefineBlock (0x24) BlockID short Server -> Client DefineBlockExt (0x25) BlockID short Server -> Client BulkBlockUpdate (0x28) Blocks byte[512] Server -> Client SetInventoryOrder (0x2C) Order short Server -> Client SetInventoryOrder (0x2C) Block ID short Server -> Client SetHotbar (0x2D) BlockID short Server -> Client
Affect on BulkBlockUpdate
Although the affect on most packets is straightforward, the changes to BulkBlockUpdate requires a more thorough explanation:
- The first 256 bytes store the lower 8 bits of the ID for each of the 256 blocks.
- The remaining 256 bytes store the higher 8 bits of the ID for each of the 256 blocks.
- (Comments go here, please sign them)
Most of this is copy/pasted from ExtendedBlocks v1, though BulkBlockUpdate has been updated to support the new blocks. This probably also needs the ability for more than 512 textures, but that's a seperate packet. Also maybe a packet to say how many blocks server/client supports? Also also, feel free to edit this; just sign on the top too. Infernity (talk) 17:19, 15 June 2022 (UTC)
ExtServerMessages
- Proposed by Rainb0wSkeppy (talk) 22:43, 20 June 2023 (UTC)
- Allows the server to remove, insert and replace messages, set the background and foreground color of the messages, and send messages longer then 64 characters
- Motivation: To allow the server to send messages longer then 64 characters, highlight parts of chat by changing the background color and to edit and delete messages after they have been sent (eg. a moderator removing messages that break the rules)
- Client Behavior: The client must read 2 characters after the &, the first one is the foreground and the second one is the background, When the server sends a message, the client inserts in the correct place, When the Position field is 0xff the client should not send a message until the Position field isn't 0xff, then concatenate the messages, When the server sends a DeleteMessage packet, it deletes the specified message
- Server Behavior: The server may send messages with the Position field and send DeleteMessage packets
ExtServerMessage packet
- Server to client
Packet ID Field Name Field Type Example Notes 0x?? (??)
Position byte 0 The position of the message. 0 is after the last message, 1 is between the last and the 2nd last message, 2 is between the 2nd last and the 3nd last message, etc. Position of 255 means the message should not be shown and should be concatenated with the next ExtServerMessage packet. Message string &70Rainb0wSkeppy: &f0hi The message to be sent Total Size: 66 bytes
DeleteMessage packet
- Server to client
Packet ID Field Name Field Type Example Notes 0x?? (??)
Position byte 0 The position of the message. 0 is the last message, 1 is the 2nd last message, 2 is the 3nd last message, etc. Total Size: 2 bytes
- (Comments go here, please sign them)