Difference between revisions of "Classic Protocol Extension/Proposals"
Jump to navigation
Jump to search
m |
|||
Line 10: | Line 10: | ||
:(Comments go here, please sign them) | :(Comments go here, please sign them) | ||
</nowiki></pre> | </nowiki></pre> | ||
− | + | =Proposals= | |
===PlaySound=== | ===PlaySound=== | ||
:Proposed by !!!WARLOCK!!! | :Proposed by !!!WARLOCK!!! |
Revision as of 05:17, 13 June 2014
Contents
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