Classic Protocol Extension/Proposals

From wiki.vg
< Classic Protocol Extension
Revision as of 03:33, 22 August 2014 by Umby24 (talk | contribs) (Proposed PlayerClick)
Jump to navigation Jump to search

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)