Difference between revisions of "Classic Protocol Extension/Proposals"
Jump to navigation
Jump to search
(Proposed PlayerClick) |
|||
Line 147: | Line 147: | ||
|} | |} | ||
:(Comments go here, please sign them) | :(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. | ||
+ | <h4>SetSkin 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="3" | 0x?? | ||
+ | (??) | ||
+ | | class="col1 centeralign" | EntityID | ||
+ | | class="col2 centeralign" | byte | ||
+ | | class="col3 centeralign" | 0 | ||
+ | | class="col4 centeralign" | The id of the entity | ||
+ | |- class="row2" | ||
+ | | class="col1 centeralign" | SkinURL | ||
+ | | class="col2 centeralign" | string | ||
+ | | class="col3 centeralign" | "http://www.example.com/image.png" | ||
+ | | class="col4 centeralign" | The URL to download the resource from | ||
+ | |- class="row3" | ||
+ | ! class="col0" | Total Size: | ||
+ | | class="col1 rightalign" colspan="4" | 66 bytes | ||
+ | |} |
Revision as of 12:55, 27 August 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
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