Classic Protocol Extension/Proposals

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

PlayerClick

Proposed by umby24

This extension is used to alert server owners that a player has clicked on something.

Motivation: The motivation for this extension is to allow for the creation of more interactive maps.

Client Behavior: Whenever a client clicks on something (right, middle or left click) the client should send a PlayerClicked packet to the server.

Server Behavior: Server should be ready to accept PlayerClicked packet at any time after level sending has completed. At which point, handling of this packet is entirely up to the server developer.

PlayerClicked packet

Client to Server

Packet ID	Field Name	Field Type	Example	Notes
0x?? (??)	Button	byte	0	0 = Left click, 1 = Middle click, 2 = Right Click
	Total Size:	2 bytes

(Comments go here, please sign them)

CustomWorld

Proposed by Rayne

This extension is used to customize the world by allowing the server to assign different textures to mobs and blocks

Motivation: The motivation for this extension is to allow the server to create their own custom mobs and blocks without needing to modify the client. This means hosts could improve their minigames by adding skins to easily recognize the two different teams and creating skins to represent different entities in a role-playing server.

Client Behavior: The client must receive the URL of the skin and the entity to assign it to, to be ready to download the resource and give the skin to the entity. If the resource isn't found nothing else happens

Server Behavior: The server should send a valid URL which locates the source and the ID of the entity to assign the skin to.

SetSkin packet

Client to Server

Packet ID	Field Name	Field Type	Example	Notes
0x?? (??)	EntityID	byte	0	The id of the entity
	SkinURL	string	"http://www.example.com/image.png"	The URL to download the resource from
	Total Size:	66 bytes

Custom Blocks v2

Proposed by Rayne

This extension gives support for extra blocks

Motivation: The motivation of this extension is to give the server a use of "extra building material". For example extra wool for a pixel art, or an medieval themed map which both classic/cpe blocks and extra blocks

Client Behavior: First of all the client sends the CustomBlocks packet with support level 2. Then the client will define block all possible block ids and link them to a position to the terrain.png (Preferably the id + 1).

Server Behavior: The server will receive the custom blocks packet version 2 and start allowing use of the extra blocks. The textures of these blocks can be changed by simply using the EnvSetMapAppearance packet.

No new packets are defined

LongerMessages

Proposed by F (talk) 21:43, 28 August 2014 (UTC)

This extension allows clients to accept messages longer than 64 characters, and send them to the server in parts.

Motivation: To allow players to write longer messages!

Client Behavior: When a regular-length message is sent, a single Message packet is sent, with the unused PlayerID (aka MessageType) byte set to 0. When an extra-long message is sent, multiple Message packets are sent. All packets except the last one should have the unused byte set to 1, meaning "this message continues in the next Message packet".

Server Behavior: Server should check the unused PlayerID (aka MessageType) byte of every incoming Message packet. If the value is non-zero, it should treat it as a partial message. Partial messages should be stored and prepended to the next message received from this player, until a message with a 0 byte is received.

No new packets are defined, but treatment of Message packet is altered.

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 to 1.

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:

1. 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.
2. 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.
3. Expand charset to full Unicode with UTF-8 encoding. Includes all the supplemental Unicode planes.
   • Pro: Theoretically covers all languages and symbols.
   • 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: Harder to implement (no native support in WinAPI / Java / C#).
   • Con: Impossible to create custom fonts.
   • Con: Very hard for servers to maintain compatibility with legacy clients.