https://wiki.vg/api.php?action=feedcontributions&user=Aragas&feedformat=atomwiki.vg - User contributions [en]2024-03-28T19:16:31ZUser contributionsMediaWiki 1.34.4https://wiki.vg/index.php?title=User:Aragas&diff=6701User:Aragas2015-07-10T23:38:58Z<p>Aragas: Created page with "[https://github.com/Aragas My GitHub]"</p>
<hr />
<div>[https://github.com/Aragas My GitHub]</div>Aragashttps://wiki.vg/index.php?title=Library_List&diff=6700Library List2015-07-10T23:36:07Z<p>Aragas: Updated MineLib.Network link, removed Modular, can't really serve for now as a library.</p>
<hr />
<div>{{ToolsNavbox}}<br />
This is a rather incomplete list of Minecraft related libraries currently in development.<br />
{| class="wikitable sortable" style="width: auto; text-align: center;"<br />
|-style="background:#eee"<br />
!Name<br />
!class="unsortable"|Description<br />
!Author(s)<br />
!Language<br />
!License<br />
!Last Version Supported<br />
|-<br />
! [https://github.com/SirCmpwn/Craft.Net Craft.Net]<br />
| .NET Minecraft client, server, and data manipulation library<br />
| Drew DeVault (SirCmpwn)<br />
| {{C sharp}}<br />
| {{MIT}}<br />
| {{yes|1.7.5}}<br />
|-<br />
! [https://github.com/dividuum/fastmc fastmc]<br />
| Python packet parser/writer & utility library<br />
| [http://dividuum.de Florian Wesch (dividuum)]<br />
| {{Python}}<br />
| {{MIT}}<br />
| {{yes|1.7/1.8}}<br />
|-<br />
! [https://github.com/PrismarineJS/node-minecraft-protocol node-minecraft-protocol]<br />
| npm install minecraft-protocol<br />
| [https://github.com/andrewrk andrewrk]<br />
| [http://nodejs.org/ node.js]<br />
| {{BSD}}<br />
| {{yes|1.7.10/1.8}}<br />
|-<br />
! [https://github.com/ammaraskar/pyCraft pyCraft]<br />
| Python minecraft client library<br />
| [http://ammaraskar.com/ Ammar Askar (ammaraskar)], [https://github.com/dkkline Jeppe Klitgaard (Dkkline)]<br />
| {{Python}}<br />
| {{Apache}}<br />
| {{yes|1.8}}<br />
|-<br />
! [http://github.com/Steveice10/MCProtocolLib MCProtocolLib]<br />
| Java implementation of the Minecraft protocol.<br />
| Steveice10<br />
| {{Java}}<br />
| {{MIT}}<br />
| {{yes|1.6.4-1.8}}<br />
|-<br />
! [https://github.com/ags131/SharpMinecraftLibrary SharpMinecraftLibrary]<br />
|<br />
| ags131, electronicboy<br />
| {{C sharp}}<br />
| {{unknown}}<br />
| {{no|1.6.2 (Partial)}}<br />
|-<br />
! [https://github.com/pdelvo/Pdelvo.Minecraft Pdelvos Protocol Implementation]<br />
| .NET client/server protocol library with support for several versions.<br />
| pdelvo<br />
| {{C sharp}}<br />
| {{MIT}}<br />
| {{no|1.5.2}}<br />
|-<br />
! [https://github.com/shoghicp/Minecraft-PHP-Client-2 Minecraft PHP Client 2]<br />
| PHP client and protocol library. With events, actions and API<br />
| [https://twitter.com/shoghicp shoghicp]<br />
| {{PHP}}<br />
| {{WTFPL}}<br />
| {{no|1.5.1}}<br />
|-<br />
! [https://github.com/deoxxa/libmcnet libmcnet]<br />
| Event based, zero-copy, portable Minecraft network protocol parser<br />
| deoxxa<br />
| {{C}}<br />
| {{BSD}}<br />
| {{no|1.4}}<br />
|-<br />
! [https://github.com/deoxxa/node-mcnet node-mcnet]<br />
| Node.JS bindings to [https://github.com/deoxxa/libmcnet libmcnet]<br />
| deoxxa<br />
| {{JavaScript}}, [http://nodejs.org/ node.js]<br />
| {{BSD}}<br />
| {{no|1.3.2}}<br />
|-<br />
! [https://github.com/Maincraft/MCPackets MCPackets]<br />
| Java Minecraft protocol library<br />
| main()<br />
| {{Java}}<br />
| {{unknown}}<br />
| {{no|1.2.5}}<br />
|-<br />
! [https://github.com/axus/libmc--c libmc--c]<br />
| World representation data structures and OpenGL drawing functions.<br />
| axus<br />
| {{C++}}, {{OpenGL}}<br />
| {{GPLv3}}<br />
| {{no|1.1}}<br />
|-<br />
! [https://github.com/mave/mcproxy mcproxy]<br />
| Minecraft Proxy (and bot) framework in C++<br />
| mave<br />
| {{C++}}<br />
| {{GPLv3}}<br />
| {{no|1.1}}<br />
|-<br />
! [https://github.com/fragmer/fNbt fNbt]<br />
| Reading, writing, and manipulating NBT files and streams, for .NET<br />
| [http://matvei.org/ Matvei Stefarov (fragmer)]<br />
| {{C sharp}}<br />
| {{BSD}}<br />
| n/a<br />
|-<br />
! [https://gist.github.com/Jckf/7872337 Yggdrasil.php]<br />
| Interfacing with Mojang's Yggdrasil authentication system.<br />
| [http://www.jckf.no/ Jim C K Flaten (Jckf)]<br />
| {{PHP}}<br />
| {{unknown}}<br />
| n/a<br />
|-<br />
! [https://github.com/umby24/libMC.NET libMC.Net]<br />
| .NET Minecraft interaction library<br />
| [http://umby.d3s.co/ umby24]<br />
| {{C sharp}}<br />
| {{MIT}}<br />
| {{yes|1.7.4}}<br />
|-<br />
! [https://github.com/MineLib/MineLib.Network MineLib.Network]<br />
| .NET Minecraft network client interaction library.<br />
| [https://github.com/Aragas Aragas (Aragasas)]<br />
| {{C sharp}}<br />
| {{MIT}}<br />
| {{yes|1.8}}<br />
|-<br />
! [https://github.com/Evil-Co/NBT-Lib NBT-Lib]<br />
| Allows reading, writing and modification of NBT files and streams.<br />
| [http://www.evil-co.org Evil-Co]<br />
| {{Java}}<br />
| {{Apache}}<br />
| n/a<br />
|-<br />
! [https://github.com/DarkStorm652/DarkBot DarkBot]<br />
| Minecraft client, automation (AI) platform, and modular protocol library<br />
| [https://github.com/DarkStorm652 DarkStorm]<br />
| {{Java}}<br />
| {{BSD}}<br />
| {{yes|1.5.2-1.7.9}}<br />
|-<br />
! [https://bitbucket.org/socolin/nbtfield/ NBTField]<br />
| Another NBT library in C++<br />
| [https://bitbucket.org/socolin/ Socolin]<br />
| {{C++}}<br />
| {{MIT}}<br />
| n/a<br />
|-<br />
|}<br />
<br />
[[Category:Minecraft Modern]]</div>Aragashttps://wiki.vg/index.php?title=Library_List&diff=6285Library List2014-11-29T18:50:46Z<p>Aragas: Added second library</p>
<hr />
<div>{{ToolsNavbox}}<br />
This is a rather incomplete list of Minecraft related libraries currently in development.<br />
{| class="wikitable sortable" style="width: auto; text-align: center;"<br />
|-style="background:#eee"<br />
!Name<br />
!class="unsortable"|Description<br />
!Author(s)<br />
!Language<br />
!License<br />
!Last Version Supported<br />
|-<br />
! [https://github.com/SirCmpwn/Craft.Net Craft.Net]<br />
| .NET Minecraft client, server, and data manipulation library<br />
| Drew DeVault (SirCmpwn)<br />
| {{C sharp}}<br />
| {{MIT}}<br />
| {{yes|1.7.5}}<br />
|-<br />
! [https://github.com/dividuum/fastmc fastmc]<br />
| Python packet parser/writer & utility library<br />
| [http://dividuum.de Florian Wesch (dividuum)]<br />
| {{Python}}<br />
| {{MIT}}<br />
| {{yes|1.7/1.8}}<br />
|-<br />
! [https://github.com/superjoe30/node-minecraft-protocol node-minecraft-protocol]<br />
| npm install minecraft-protocol<br />
| [https://github.com/superjoe30 superjoe]<br />
| [http://nodejs.org/ node.js]<br />
| {{BSD}}<br />
| {{yes|1.7.6}}<br />
|-<br />
! [https://github.com/ags131/SharpMinecraftLibrary SharpMinecraftLibrary]<br />
|<br />
| ags131, electronicboy<br />
| {{C sharp}}<br />
| {{unknown}}<br />
| {{no|1.6.2 (Partial)}}<br />
|-<br />
! [http://github.com/Steveice10/MCProtocolLib MCProtocolLib]<br />
| Java implementation of the Minecraft protocol.<br />
| Steveice10<br />
| {{Java}}<br />
| {{MIT}}<br />
| {{yes|1.7.4-1.7.9}}<br />
|-<br />
! [https://github.com/dkkline/McClientLib McClientLib]<br />
| Python MineCraft client protocol.<br />
| [https://github.com/dkkline Jeppe Klitgaard (Dkkline)]<br />
| {{Python}}<br />
| {{MIT}}<br />
| {{no|1.5.2}}<br />
|-<br />
! [https://github.com/pdelvo/Pdelvo.Minecraft Pdelvos Protocol Implementation]<br />
| .NET client/server protocol library with support for several versions.<br />
| pdelvo<br />
| {{C sharp}}<br />
| {{MIT}}<br />
| {{no|1.5.2}}<br />
|-<br />
! [https://github.com/shoghicp/Minecraft-PHP-Client-2 Minecraft PHP Client 2]<br />
| PHP client and protocol library. With events, actions and API<br />
| [https://twitter.com/shoghicp shoghicp]<br />
| {{PHP}}<br />
| {{WTFPL}}<br />
| {{no|1.5.1}}<br />
|-<br />
! [https://github.com/deoxxa/libmcnet libmcnet]<br />
| Event based, zero-copy, portable Minecraft network protocol parser<br />
| deoxxa<br />
| {{C}}<br />
| {{BSD}}<br />
| {{no|1.4}}<br />
|-<br />
! [https://github.com/deoxxa/node-mcnet node-mcnet]<br />
| Node.JS bindings to [https://github.com/deoxxa/libmcnet libmcnet]<br />
| deoxxa<br />
| {{JavaScript}}, [http://nodejs.org/ node.js]<br />
| {{BSD}}<br />
| {{no|1.3.2}}<br />
|-<br />
! [https://github.com/Maincraft/MCPackets MCPackets]<br />
| Java Minecraft protocol library<br />
| main()<br />
| {{Java}}<br />
| {{unknown}}<br />
| {{no|1.2.5}}<br />
|-<br />
! [https://github.com/axus/libmc--c libmc--c]<br />
| World representation data structures and OpenGL drawing functions.<br />
| axus<br />
| {{C++}}, {{OpenGL}}<br />
| {{GPLv3}}<br />
| {{no|1.1}}<br />
|-<br />
! [https://github.com/mave/mcproxy mcproxy]<br />
| Minecraft Proxy (and bot) framework in C++<br />
| mave<br />
| {{C++}}<br />
| {{GPLv3}}<br />
| {{no|1.1}}<br />
|-<br />
! [https://github.com/fragmer/fNbt fNbt]<br />
| Reading, writing, and manipulating NBT files and streams, for .NET<br />
| [http://matvei.org/ Matvei Stefarov (fragmer)]<br />
| {{C sharp}}<br />
| {{BSD}}<br />
| n/a<br />
|-<br />
! [https://gist.github.com/Jckf/7872337 Yggdrasil.php]<br />
| Interfacing with Mojang's Yggdrasil authentication system.<br />
| [http://www.jckf.no/ Jim C K Flaten (Jckf)]<br />
| {{PHP}}<br />
| {{unknown}}<br />
| n/a<br />
|-<br />
! [https://github.com/umby24/libMC.NET libMC.Net]<br />
| .NET Minecraft interaction library<br />
| [http://umby.d3s.co/ umby24]<br />
| {{C sharp}}<br />
| {{MIT}}<br />
| {{yes|1.7.4}}<br />
|-<br />
! [https://github.com/Aragas/MineLib.Network MineLib.Network]<br />
[https://github.com/Aragas/MineLib.Network.Modular MineLib.Network.Modular]<br />
| .NET Minecraft network client interaction library.<br />
| [https://github.com/Aragas Aragas (Aragasas)]<br />
| {{C sharp}}<br />
| {{MIT}}<br />
| {{yes|1.8}}<br />
|-<br />
! [https://github.com/Evil-Co/NBT-Lib NBT-Lib]<br />
| Allows reading, writing and modification of NBT files and streams.<br />
| [http://www.evil-co.org Evil-Co]<br />
| {{Java}}<br />
| {{Apache}}<br />
| n/a<br />
|-<br />
! [https://github.com/DarkStorm652/DarkBot DarkBot]<br />
| Minecraft client, automation (AI) platform, and modular protocol library<br />
| [https://github.com/DarkStorm652 DarkStorm]<br />
| {{Java}}<br />
| {{BSD}}<br />
| {{yes|1.5.2-1.7.9}}<br />
|-<br />
! [https://bitbucket.org/socolin/nbtfield/ NBTField]<br />
| Another NBT library in C++<br />
| [https://bitbucket.org/socolin/ Socolin]<br />
| {{C++}}<br />
| {{MIT}}<br />
| n/a<br />
|-<br />
|}<br />
<br />
[[Category:Minecraft Modern]]</div>Aragashttps://wiki.vg/index.php?title=Classic_Library_List&diff=6179Classic Library List2014-10-12T09:08:45Z<p>Aragas: Added MineLib.Network, looks like modern list now</p>
<hr />
<div>{{navboxclassic}}<br /><br />
This is a rather incomplete list of Minecraft Classic related libraries currently in development.<br />
<br />
{| class="wikitable sortable" style="width: auto; text-align: center;"<br />
|-style="background:#eee"<br />
!Name<br />
!class="unsortable"|Description<br />
!Author(s)<br />
!Language<br />
!License<br />
|-<br />
! [http://sourceforge.net/projects/libminecraft/ LibMinecraft]<br />
| Classic Client API, Remote Connections, Map/Player/Entity Tracking, Session Abstraction<br />
| Yuri Sevatz<br />
| {{C++}}<br />
| {{GPLv3}}<br />
|-<br />
! [https://github.com/Aragas/MineLib.Network MineLib.Network]<br />
| .NET Minecraft network client interaction library. (Online mode and chunks WIP)<br />
| [https://github.com/Aragas Aragas (Aragasas)]<br />
| {{C sharp}}<br />
| {{MIT}}<br />
|}<br />
<br />
[[Category:Minecraft Classic]]</div>Aragashttps://wiki.vg/index.php?title=Main_Page&diff=6178Main Page2014-10-12T07:41:21Z<p>Aragas: Added Classic Extension</p>
<hr />
<div>__NOTOC____NOEDITSECTION__<br />
{{Box|<br />
BORDER = #9999FF|<br />
BACKGROUND = #99CCFF|<br />
WIDTH = 100%|<br />
ICON = |<br />
HEADING = Minecraft Modern |<br />
CONTENT = <br />
[[File:Banner beta.png|link=Category:Minecraft Modern]]<br />
<br />
Minecraft Modern is the latest (and only updated) version of Minecraft which requires a paid account to download, update and play. Most of the new development projects focus on either creating entirely new programs from scratch that interoperate with Minecraft (such as a bot or server) or modding projects that wrap the client or server and provide bug fixes, new features and enhancements to existing features.<br />
<br />
=== Documentation ===<br />
There are ongoing efforts to keep reverse engineered documentation updated, but it isn't as easy as it sounds. The protocol generally changes with each release, and both the Client and Server classes get rearranged on each release. Below are links to the current documentation segments, which '''may or may not be up to date'''.<br />
<br />
* [[Protocol FAQ]]<br />
* [[Protocol|Current Protocol Specification]]<br />
** [[Protocol Encryption]]<br />
** [[Server_List_Ping|Server list ping]] documentation<br />
** [[Protocol_version_numbers|Protocol version numbers]]<br />
** [[Plugin_channel|Plugin channels]]<br />
* [[Pre-release protocol|Pre-release Protocol Specificaton]]<br />
* [[Authentication|Authentication Scheme]]<br />
* [[Mojang_API|Mojang API]]<br />
* [[Game Files|Location of Game Files]]<br />
* [[Map Format]] (See also: mirror of the old [[NBT]].txt)<br />
* [[Snoop|Snoop Mechanism]]<br />
* [[Realms API]]<br />
* [[Rcon]] and [[Query]] protocol specifications<br />
* [[Debugging]]<br />
<br />
=== Tools & Mods ===<br />
* [[Client List|Clients]] - third-party Minecraft clients.<br />
* [[Server List|Servers]] - third-party Minecraft servers.<br />
* [[Library List|Libraries]] - libraries to interface with Minecraft data files or network protocols.<br />
* [[Utility List|Utilities]] - tools that interface with a client, server, or data files, such as proxies, bots, or inventory editors.<br />
* [[Wrapper List|Wrappers]] - mods that override features in the client or server<br />
* [http://b.wiki.vg/ Burger Vitrine] shows differences in data and protocol between arbitrary versions.<br />
* [[:Code Snippets]]<br />
<br />
=== Tutorials & Guides ===<br />
* [[How to Write a Client]]<br />
* [[Chat|How Chat Works]]<br />
<br />
For more info, check out [[:Category:Minecraft Modern|Minecraft Modern]].<br />
}}<br />
<br />
{{Box|<br />
BORDER = #9999FF|<br />
BACKGROUND = #99CCFF|<br />
WIDTH = 100%|<br />
ICON = |<br />
HEADING = Minecraft Classic |<br />
CONTENT = <br />
[[File:Banner classic.png|link=Category:Minecraft Classic]]<br />
<br />
Minecraft Classic is the original version of Minecraft, available for free to the public. It's still available off of the main website today and is still played by many people, with an active development community. As it's been around since 2010, and because it's so simplistic, there are many, many programs made to work with Classic - there are over '''18+''' servers alone, written in everything from C++ to PureBasic to Perl. It's highly recommend if you're planning to do a development project at this point to instead look into the Minecraft Modern specifications.<br />
<br />
=== Documentation ===<br />
As there is no longer any work being done on classic, the documentation for it is stable. If you create something that works with it, it probably always will.<br />
* [[Classic Protocol|Protocol Specification]]<br />
* [[Classic Protocol Extension|Extension Protocol Specification]]<br />
* [[Classic DAT Format|Server Map Format (.dat)]]<br />
* [[MCLevel Format|Saved Level Format (.mclevel)]]<br />
<br />
=== Source Code Snippets ===<br />
Source code snippets provide insight into how specific features work or can be accomplished, and by themselves are generally free to use in your own program.<br />
* Deserializing the level.dat file format ([[deserialize.c|C]], [https://gist.github.com/324122945a569a513bae C#])<br />
* [[:Category:Code Snippets|More...]]<br />
<br />
=== Tools and Mods ===<br />
Useful information & links<br />
* [[Classic Client List|Clients]] - third-party Classic clients.<br />
* [[Classic Server List|Servers]] - third-party Classic servers.<br />
* [[Classic Library List|Libraries]] - libraries to interface with Minecraft data files or network protocols.<br />
* [[Classic Utility List|Utilities]] - tools that interface with a client, server, or data files, such as proxies or bots.<br />
* [[Classic Wrapper List|Wrappers]] - mods that override features in the client or server.<br />
<br />
For more info, check out [[:Category:Minecraft Classic|Minecraft Classic]].<br />
}}<br />
<br />
{{Box|<br />
BORDER = #9999FF|<br />
BACKGROUND = #99CCFF|<br />
WIDTH = 100%|<br />
ICON = |<br />
HEADING = Minecraft Pocket Edition |<br />
CONTENT = <br />
[[File:Banner pocket.png|link=Category:Pocket Minecraft]]<br />
<br />
Pocket Minecraft is the version of Minecraft for portable systems such as Android or iOS devices. It currently has very little documentation.<br />
<br />
=== Documentation ===<br />
The documentation for Pocket Minecraft is currently lacking and needs improvement.<br />
* [[Pocket Minecraft Protocol|Protocol Specification]]<br />
* [[Pocket Edition FAQ|FAQ]]<br />
* [[Pocket Editon Login|Login Procedure]]<br />
* [[Pocket Realms|Pocket Realms]]<br />
* [[Pocket Minecraft Map Format|Map Format]]<br />
<br />
=== Tools ===<br />
Useful information & links<br />
* [[Pocket Edition Program List|Program list]] - third-party PE programs<br />
<br />
For more info, check out [[:Category:Pocket Minecraft|Pocket Minecraft]].<br />
<br />
}}</div>Aragashttps://wiki.vg/index.php?title=Classic_Protocol_Extension&diff=6174Classic Protocol Extension2014-10-11T13:49:35Z<p>Aragas: Added to Classic Category</p>
<hr />
<div>'''Classic Protocol Extension''' (CPE) is a project to augment the Minecraft Classic network protocol with new and improved functionality.<br />
<br />
Extensions are designed to keep extended clients and servers compatible with standard clients and servers. Standard clients and extended clients can play on the same server side-by-side. Extensions are designed to be modular: custom clients and servers can selectively implement any subset of extensions, and only mutually-supported extensions will be used.<br />
<br />
{| class="wikitable" style="margin:10px 10%;border: 1px solid #aaa;border-left:10px solid #f28500;background:#fbfbfb;width:80%;font-size:110%"<br />
|style="padding:10px"|'''This specification has not yet been finalized, and is subject to change.'''<br />
Last revision: 28 August 2014.<br />
See [[Classic Protocol Extension/History|the history subpage]] for a chronology of changes.<br />
|}<br />
{| class="wikitable" style="margin:10px 10%;border: 1px solid #aaa;border-left:10px solid #3dc238;background:#fbfbfb;width:80%;font-size:110%"<br />
|style="padding:10px"|'''Do you have an idea for an extension? Please post it on the [[Classic_Protocol_Extension/Proposals|Proposals]] subpage.'''<br />
|}<br />
<br />
==Support==<br />
:''See [[Classic Protocol Extension/Support|support subpage]] for a detailed table.''<br />
Custom servers that already support CPE: [http://femto.fcraft.net/ FemtoCraft], [http://umby.d3s.co/CCD3/ D3], [http://github.com/LeChosenOne/LegendCraft/ LegendCraft], [http://GemsCraftMC.weebly.com/ GemsCraft], [https://github.com/umby24/Hypercube Hypercube], [https://github.com/123DMWM/ProCraft ProCraft]<br />
<br />
Custom servers that plan to add support: [http://800craft.net/ 800Craft], [http://github.com/tyteen4a03/cloudBox cloudBox], [http://www.fcraft.net/ fCraft], [https://github.com/GamezGalaxy/GGS/tree/Classic-Extension GGS] <br />
<br />
Custom clients that already support CPE: [http://classicube.net ClassiCube Client]<br />
<br />
Custom clients that plan to add support: [http://charged-miners.com/ Charged Miners]<br />
<br />
==Negotiation==<br />
When CPE-capable client connects to a CPE-capable server, a brief negotiation needs to happen before any extensions are used. Client and server declare their capabilities and determine which extensions are mutually supported. '''All CPE-capable software is required to support this.'''<br />
<br />
[[File:CPE_Negotiation.png|frame|right]]<br />
'''Client behavior''': Extended clients must use magic number of <code>0x42</code> (<code>66</code> decimal) for the padding byte of the [[Classic_Protocol#Client_.E2.86.92_Server_packets|'''''ClientIdentification''''']] packet. It must then await a response. If server responds with any packet other than '''''ExtInfo''''', client must assume that the server does NOT support CPE. If the server responds with an '''''ExtInfo''''' packet, client must parse it and any '''''ExtEntry''''' packets that follow. Client must then compare its locally-supported set of extensions with the list of extensions provided by the server, and find an intersection of these sets. These are the mutually-supported extensions. Client must now send '''''ExtInfo''''' packet of its own, followed by a list of zero or more client-supported extensions. After sending the last of '''''ExtEntry''''' packets, client should activate all mutually-supported extensions and resume normal login procedure.<br />
<br />
'''Server behavior''': When a client connects, server must read the [[Classic_Protocol#Client_.E2.86.92_Server_packets|'''''ClientIdentification''''']] packet and check its padding byte. If this byte is set to <code>0x42</code> (<code>66</code> decimal), assume that the client supports CPE. If this byte is set to any other value, assume that the client does NOT support CPE.<br />
<br />
Server must immediately reply to CPE clients with an '''''ExtInfo''''' packet, followed by zero or more '''''ExtEntry''''' packets, and await a response from the client. Client will respond with one '''''ExtInfo''''' and zero or more '''''ExtEntry''''' packets. Server must then compare its locally-supported set of extensions with the list of extensions provided by the client, and find an intersection of these sets. These are the mutually-supported extensions. After receiving the last of '''''ExtEntry''''' packets, server should activate all mutually-supported extensions and resume normal login procedure. <br />
<br />
'''Note 1''': All standard/non-extended clients use <code>0x00</code> for the padding byte. All standard servers ignore this padding byte. Therefore, this negotiation process does not affect compatibility with standard software.<br />
<br />
'''Note 2''': Do not make any assumptions about supported functionality based on the ''AppName'' field of '''''ExtInfo''''' packet. It's for logging purposes only.<br />
<br />
'''Note 3''': Do not declare support for an extension until it is FULLY implemented, except for debugging.<br />
<br />
:<h4>ExtInfo Packet</h4><br />
:{| class="wikitable"<br />
|- class="row0"<br />
! class="col0" | Packet ID<br />
! class="col1" | Field Name<br />
! class="col2" | Field Type<br />
! class="col3" | Example<br />
! class="col4" | Notes<br />
|- class="row1"<br />
| class="col0 centeralign" rowspan="2" | 0x10<br />
(16)<br />
| class="col1 centeralign" | AppName<br />
| class="col2 centeralign" | string<br />
| class="col3 centeralign" | <code>MyServer</code><br />
| class="col4" | Client or server software name<br />
|- class="row2"<br />
| class="col0 centeralign" | ExtensionCount<br />
| class="col1 centeralign" | short<br />
| class="col2 centeralign" | 1<br />
| class="col3" | Between 0 and 32767<br />
|- class="row3"<br />
! class="col0" | Total Size:<br />
| class="col1 rightalign" colspan="4" | 67 bytes<br />
|}<br />
<br />
:<h4>ExtEntry Packet</h4><br />
:{| class="wikitable"<br />
|- class="row0"<br />
! class="col0" | Packet ID<br />
! class="col1" | Field Name<br />
! class="col2" | Field Type<br />
! class="col3" | Example<br />
! class="col4" | Notes<br />
|- class="row1"<br />
| class="col0 centeralign" rowspan="2" | 0x11<br />
(17)<br />
| class="col1 centeralign" | ExtName<br />
| class="col2 centeralign" | string<br />
| class="col3 centeralign" | <code>MyExtension</code><br />
| class="col4" | Name of a supported extension<br />
|- class="row2"<br />
| class="col0 centeralign" | Version<br />
| class="col1 centeralign" | int<br />
| class="col2 centeralign" | 1<br />
| class="col3" | Only extensions with identical version numbers should be considered compatible.<br />
|- class="row3"<br />
! class="col0" | Total Size:<br />
| class="col1 rightalign" colspan="4" | 69 bytes<br />
|}<br />
<br />
==Extensions==<br />
'''''Note:''''' The section heading is the name of the extension. Packet names are not same as extension names. For example, the first extension listed here is named "ClickDistance" and not "SetClickDistance".<br />
{| class="wikitable" style="margin:10px 10%;border: 1px solid #aaa;border-left:10px solid #3dc238;background:#fbfbfb;width:80%;font-size:110%"<br />
|style="padding:10px"|'''Do you have an idea for an extension? Please post it on the [[Classic_Protocol_Extension/Proposals|Proposals]] subpage.'''<br />
|}<br />
<br />
===ClickDistance===<br />
:Used to extend or restrict the distance at which client may click blocks, controlled by the server. Click range is given in player-space units (32 units per block). In Minecraft Classic, the default range is 160.<br />
:'''Motivation''': This extension allows trusted players to have a wider or virtually-unlimited reach. It may simplify operation of certain bots. Restricting the reach may allow new games/mini-games.<br />
:'''Client Behavior''': Upon receiving a '''''SetClickDistance''''' packet, client should immediately apply the change. ''Distance'' should persist between worlds/maps.<br />
:'''Server Behavior''': Server should send '''''SetClickDistance''''' packet when the server connects, or whenever their permitted click distance changes. Server should allow for some margin-of-error (+/- 1 block) when enforcing click distance restrictions.<br />
:<h4>SetClickDistance packet</h4><br />
:''Server to Client''<br />
:{| class="wikitable"<br />
|- class="row0"<br />
! class="col0" | Packet ID<br />
! class="col1" | Field Name<br />
! class="col2" | Field Type<br />
! class="col3" | Example<br />
! class="col4" | Notes<br />
|- class="row1"<br />
| class="col0 centeralign" | 0x12<br />
(18)<br />
| class="col1 centeralign" | Distance<br />
| class="col2 centeralign" | short<br />
| class="col3 centeralign" | 160<br />
| class="col4" |<br />
|- class="row2"<br />
! class="col0" | Total Size:<br />
| class="col1 rightalign" colspan="4" | 3 bytes<br />
|}<br />
<br />
===CustomBlocks===<br />
:Used to add support for custom block types. Custom block IDs start at 50 (0x32). New block types will be added in batches, a few at a time. Both client and server declare which batch they support, and use the lower of the two versions. Claiming to supporting a batch implies fully implementing all the batches that came before it. If either server or client do not support this extension, only the standard 50 block types should be used.<br />
:'''Motivation''': Adding new visually distinct blocks, to enhance Classic players' experience.<br />
:'''Client behavior''': Client must expect a '''''CustomBlockSupportLevel''''' packet from a compatible server immediately after sending the last '''''ExtEntry''''' packet. It should then reply with its own '''''CustomBlockSupportLevel''''' packet, containing its actual support level. Client must then use the lower of the two levels in operation. Client must not send any block types that are not defined by the current support level. Client should expect [[Classic_Protocol#Client_.E2.86.92_Server_packets|'''''ServerIdentification''''']] packet only AFTER sending its '''''CustomBlockSupportLevel''''' packet.<br />
:'''Server behavior''': Server must send a '''''CustomBlockSupportLevel''''' packet to compatible clients immediately after receiving the last '''''ExtEntry''''' packet from the client. It should then wait to receive a '''''CustomBlockSupportLevel''''' packet from the client before sending the [[Classic_Protocol#Client_.E2.86.92_Server_packets|'''''ServerIdentification''''']] packet. Server must then use the lower of the two levels in operation. If this level is lower than the server's, it has to filter data sent to the client, to make sure that the client never receives any block types that it does not support. Each level will define what substitutions to use.<br />
<br />
:<h4>CustomBlockSupportLevel packet</h4><br />
:''Server to Client''<br />
:{| class="wikitable"<br />
|- class="row0"<br />
! class="col0" | Packet ID<br />
! class="col1" | Field Name<br />
! class="col2" | Field Type<br />
! class="col3" | Example<br />
! class="col4" | Notes<br />
|- class="row1"<br />
| class="col0 centeralign" | 0x13<br />
(19)<br />
| class="col1 centeralign" | SupportLevel<br />
| class="col2 centeralign" | byte<br />
| class="col3 centeralign" | 1<br />
| class="col4" |<br />
|- class="row2"<br />
! class="col0" | Total Size:<br />
| class="col1 rightalign" colspan="4" | 2<br />
|}<br />
<br />
:<h4>Blocks in support level 1</h4><br />
:Client must be able to receive/render all 16 custom blocks to claim support. Server must be able to receive/store all 16 custom blocks to claim support.<br />
:[[File:CPE_CustomBlocks_Level1.png]]<br />
:{| class="wikitable"<br />
!Block name<br />
!Block ID<br />
!Fallback name<br />
!Fallback ID<br />
|-<br />
|'''CobblestoneSlab'''<br />
|0x32 (50)<br />
|Slab<br />
|0x2C (44)<br />
|-<br />
|'''Rope'''<br />
|0x33 (51)<br />
|BrownMushroom<br />
|0x27 (39)<br />
|-<br />
|'''Sandstone'''<br />
|0x34 (52)<br />
|Sand<br />
|0x0C (12)<br />
|-<br />
|'''Snow'''<br />
|0x35 (53)<br />
|Air<br />
|0x00 (0)<br />
|-<br />
|'''Fire'''<br />
|0x36 (54)<br />
|Lava<br />
|0x0A (10)<br />
|-<br />
|'''LightPinkWool'''<br />
|0x37 (55)<br />
|Pink<br />
|0x21 (33)<br />
|-<br />
|'''ForestGreenWool'''<br />
|0x38 (56)<br />
|Green<br />
|0x19 (25)<br />
|-<br />
|'''BrownWool'''<br />
|0x39 (57)<br />
|Dirt<br />
|0x03 (3)<br />
|-<br />
|'''DeepBlue'''<br />
|0x3A (58)<br />
|Blue<br />
|0x1d (29)<br />
|-<br />
|'''Turquoise'''<br />
|0x3B (59)<br />
|Cyan<br />
|0x1c (28)<br />
|-<br />
|'''Ice'''<br />
|0x3C (60)<br />
|Glass<br />
|0x14 (20)<br />
|-<br />
|'''CeramicTile'''<br />
|0x3D (61)<br />
|Iron<br />
|0x2a (42)<br />
|-<br />
|'''Magma'''<br />
|0x3E (62)<br />
|Obsidian<br />
|0x31 (49)<br />
|-<br />
|'''Pillar'''<br />
|0x3F (63)<br />
|White<br />
|0x24 (36)<br />
|-<br />
|'''Crate'''<br />
|0x40 (64)<br />
|WoodenPlanks<br />
|0x05 (5)<br />
|-<br />
|'''StoneBrick'''<br />
|0x41 (65)<br />
|Stone<br />
|0x01 (1)<br />
|}<br />
<br />
:Block IDs for future support levels are guaranteed to be assigned monotonically, incrementally, and permanently.<br />
<br />
===HeldBlock===<br />
:Provides a way for the client to notify the server about the blocktype that it is currently holding, and for the server to change the currently-held block type. <br />
:'''Motivation''': This allows server to know which block player is holding, for example for drawing commands, without needing to wait for the player's click. it also allows for features like [http://www.fcraft.net/wiki//Spectate /Spectate] to show what block a spectated player is holding.<br />
:'''Client behavior''': When this extension is mutually supported, client should use the ''PlayerID'' field of the '''''[[Classic_Protocol#Client_.E2.86.92_Server_packets|PositionAndOrientation]]''''' packet (currently unused) to indicate which blocktype the client is currently holding. It should be ready to accept '''''HoldThis''''' packets to change the block that the player is holding. If <code>0</code> is given for ''BlockToHold'', client should hide the hand/block from the screen, and should not be able to click blocks, until they switch to a different blocktype. If an unrecognized blocktype is given, no action is needed.<br />
:'''Server behavior''': The server can use '''''HoldThis''''' packet to force the client to hold the desired block type. It should be done sparingly.<br />
<br />
:<h4>HoldThis packet</h4><br />
:''Server to Client''<br />
:{| class="wikitable"<br />
|- class="row0"<br />
! class="col0" | Packet ID<br />
! class="col1" | Field Name<br />
! class="col2" | Field Type<br />
! class="col3" | Example<br />
! class="col4" | Notes<br />
|- class="row1"<br />
| class="col0 centeralign" rowspan="2" | 0x14<br />
(20)<br />
| class="col1 centeralign" | BlockToHold<br />
| class="col2 centeralign" | byte<br />
| class="col3 centeralign" | <code>49</code><br />
| class="col4" | Standard block type<br />
|- class="row2"<br />
| class="col1 centeralign" | PreventChange<br />
| class="col2 centeralign" | byte<br />
| class="col3 centeralign" | 0<br />
| class="col4" |0 = Allow player to change blocktype<br />
1 = Prevent player from changing blocktype<br />
|- class="row3"<br />
! class="col0" | Total Size:<br />
| class="col1 rightalign" colspan="4" | 3 bytes<br />
|}<br />
<br />
===EmoteFix===<br />
:This extension indicates that the client can render [http://fcraft.net/wiki/Emotes emotes] (ASCII control characters) in chat properly, without padding or suffixes that are required for vanilla client. This extension does not define any new packets.<br />
:'''Motivation''': To improve appearance of emotes in chat.<br />
:'''Client behavior''': Client should not emulate vanilla client's quirks.<br />
:'''Server behavior''': Server should not pad or suffix emotes in chat.<br />
<br />
===TextHotKey===<br />
:This extension allows the server to define "hotkeys" for certain commands.<br />
:'''Motivation''': To speed up and simplify access to commonly-used commands and command macros by providing server-defined client-side hotkeys.<br />
:'''Client behavior:''' Client should not try to persist previously-defined hotkeys between sessions. When a defined hotkey is activated by the user, client should open up a text prompt and type in contents of the ''Action'' field. A newline character (<code>\n</code>) in the ''Action'' field indicates that whatever is currently typed-in should be sent to the server. If ''Action'' does not end with a newline, text prompt should be left open, for the user to complete. Client may provide a way for the user to see a list of currently-defined hotkeys, and a way to notify the user when a hotkey was activated.<br />
:'''Server behavior:''' The server should send a definition of each hotkey ('''''SetTextHotKey''''' packet) once per connection.<br />
<br />
:<h4>SetTextHotKey packet</h4><br />
:''Server to Client''<br />
:{| class="wikitable"<br />
|- class="row0"<br />
! class="col0" | Packet ID<br />
! class="col1" | Field Name<br />
! class="col2" | Field Type<br />
! class="col3" | Example<br />
! class="col4" | Notes<br />
|- class="row1"<br />
| class="col0 centeralign" rowspan="4" | 0x15<br />
(21)<br />
| class="col1 centeralign" | Label<br />
| class="col2 centeralign" | string<br />
| class="col3 centeralign" | <code>Copy</code><br />
| class="col4" | Readable name of the hotkey<br />
|- class="row2"<br />
| class="col1 centeralign" | Action<br />
| class="col2 centeralign" | string<br />
| class="col3 centeralign" | <code>/Copy </code><br />
| class="col4" | Text to type in<br />
|- class="row2"<br />
| class="col1 centeralign" | KeyCode<br />
| class="col2 centeralign" | int<br />
| class="col3 centeralign" | <code>113</code><br />
| class="col4" | [http://www.minecraftwiki.net/wiki/Key_Codes LWJGL keycode] of the key<br />
|- class="row3"<br />
| class="col1 centeralign" | KeyMods<br />
| class="col2 centeralign" | byte<br />
| class="col3 centeralign" | <code>0</code><br />
| class="col4" | Key modifier [http://en.wikipedia.org/wiki/Flag_word flags], may be combined:<br />
* 0 = None<br />
* 1 = Ctrl<br />
* 2 = Shift<br />
* 4 = Alt<br />
|- class="row4"<br />
! class="col0" | Total Size:<br />
| class="col1 rightalign" colspan="4" | 134 bytes<br />
|}<br />
<br />
===ExtPlayerList===<br />
:'''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 '''''ExtAddEntity2'''''/'''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|DespawnPlayer]]''''' packets are used only to manage in-game entities.<br />
<br />
====Version 1 (Deprecated since 28 August 2014)====<br />
:This version of the extension has been deprecated and replaced with version 2. See [[Classic Protocol Extension/Old Extensions|old extensions subpage]].<br />
<br />
====Version 2====<br />
Version 2 of this extension replaces '''''ExtAddEntity''''' packet with '''''ExtAddEntity2''''', allows using full URLs for ''SkinName'', and clarifies interaction with [[#ChangeModel|'''ChangeModel''']] extension.<br />
:<h5>Client Behavior</h5><br />
:When '''''ExtAddPlayerName''''' packet is received for an unrecognized ''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''. Player-name list must persist when client changes worlds/maps.<br />
<br />
:When an '''''ExtAddEntity2''''' 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. When client receives '''''ExtAddEntity2''''' 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'' and ''SkinName'' must be updated. If a negative ''EntityID'' is given for '''''ExtAddEntity2''''', client must update player's own spawn point, ''InGameName'', and ''SkinName''. The client must ignore regular '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|SpawnPlayer]]''''' packets, if any are received.<br />
<br />
:Player entity's skin should be loaded using the given ''SkinName''. 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.<br />
<br />
: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''.<br />
<br />
: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.<br />
<br />
:In-game entities must never be affected by '''''ExtAddPlayerName''''' or '''''ExtRemovePlayerName''''' packets. Player name list must never be affected by '''''ExtAddEntity2''''' or '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|DespawnPlayer]]''''' packets.<br />
<br />
:<h5>Server Behavior</h5><br />
{| class="wikitable" style="float:right"<br />
!Event<br />
!Packet to send<br />
|-<br />
|Player connects to server<br />
|'''''ExtAddPlayerName'''''<br />
|-<br />
|Player enters map<br />
|'''''ExtAddEntity2'''''<br />
|-<br />
|Player leaves map<br />
|'''''DespawnPlayer'''''<br />
|-<br />
|Player disconnects from server<br />
|'''''ExtRemovePlayerName'''''<br />
|}<br />
:Unique ''NameID'' between 0 and 255 should be assigned to every online player. When a new player connects to the server, '''''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 '''''ExtAddEntity2''''' 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''.<br />
<br />
:<h5>ExtAddPlayerName Packet</h5><br />
:''Server to Client''<br />
:{| class="wikitable"<br />
|- class="row0"<br />
! class="col0" | Packet ID<br />
! class="col1" | Field Name<br />
! class="col2" | Field Type<br />
! class="col3" | Example<br />
! class="col4" | Notes<br />
|- class="row1"<br />
| class="col0 centeralign" rowspan="5" | 0x16<br />
(22)<br />
| class="col1 centeralign" | NameID<br />
| class="col2 centeralign" | short<br />
| class="col3 centeralign" | <code>5</code><br />
| class="col4" | Between 0 and 255<br />
|- class="row2"<br />
| class="col1 centeralign" | PlayerName<br />
| class="col2 centeralign" | string<br />
| class="col3 centeralign" | <code>Notch</code><br />
| class="col4" | Player name used for autocompletion.<br />
May be left empty (to exclude from autocompletion).<br />
|- class="row3"<br />
| class="col1 centeralign" | ListName<br />
| class="col2 centeralign" | string<br />
| class="col3 centeralign" | <code>&c[Op]Notch</code><br />
| class="col4" |Name displayed in the in-game list.<br />
|- class="row4"<br />
| class="col1 centeralign" | GroupName<br />
| class="col2 centeralign" | string<br />
| class="col3 centeralign" | <code>Staff</code><br />
| class="col4" |May be left blank.<br />
|- class="row5"<br />
| class="col1 centeralign" | GroupRank<br />
| class="col2 centeralign" | byte<br />
| class="col3 centeralign" | <code>0</code><br />
| class="col4" | Rank of a player within the group.<br />
Lower-number ranks are listed before higher-number ranks.<br />
|- class="row6"<br />
! class="col0" | Total Size:<br />
| class="col1 rightalign" colspan="4" | 196 bytes<br />
|}<br />
<br />
:<h5>ExtAddEntity2 Packet</h5><br />
:''Server to Client''<br />
:{| class="wikitable"<br />
|- class="row0"<br />
! class="col0" | Packet ID<br />
! class="col1" | Field Name<br />
! class="col2" | Field Type<br />
! class="col3" | Example<br />
! class="col4" | Notes<br />
|- class="row1"<br />
| class="col0 centeralign" rowspan="8" | 0x21<br />
(33)<br />
| class="col1 centeralign" | EntityID<br />
| class="col2 centeralign" | byte<br />
| class="col3 centeralign" | <code>5</code><br />
| class="col4" | Between 0 and 127<br />
|- class="row2"<br />
| class="col1 centeralign" | InGameName<br />
| class="col2 centeralign" | string<br />
| class="col3 centeralign" | <code>&cNotch</code><br />
| class="col4" | Player name to be shown in-game, hovering above player model.<br />
|- class="row3"<br />
| class="col1 centeralign" | SkinName<br />
| class="col2 centeralign" | string<br />
| class="col3 centeralign" | <code>Notch</code><br />
| class="col4" | Player name whose skin should be used by the client.<br />
|- class="row4"<br />
| class="col1 centeralign" | SpawnX<br />
| class="col2 centeralign" | short<br />
| class="col3 centeralign" | <code>1</code><br />
| class="col4" | X coordinate (32 units per block) of entity's spawn location.<br />
|- class="row5"<br />
| class="col1 centeralign" | SpawnY<br />
| class="col2 centeralign" | short<br />
| class="col3 centeralign" | <code>2</code><br />
| class="col4" | Y coordinate (32 units per block) of entity's spawn location.<br />
|- class="row6"<br />
| class="col1 centeralign" | SpawnZ<br />
| class="col2 centeralign" | short<br />
| class="col3 centeralign" | <code>3</code><br />
| class="col4" | Z coordinate (32 units per block) of entity's spawn location.<br />
|- class="row7"<br />
| class="col1 centeralign" | SpawnYaw<br />
| class="col2 centeralign" | byte<br />
| class="col3 centeralign" | <code>4</code><br />
| class="col4" | Orientation (left-right) at the entity's spawn location.<br />
|- class="row8"<br />
| class="col1 centeralign" | SpawnPitch<br />
| class="col2 centeralign" | byte<br />
| class="col3 centeralign" | <code>5</code><br />
| class="col4" | Orientation (up-down) at the entity's spawn location.<br />
|- class="row9"<br />
! class="col0" | Total Size:<br />
| class="col1 rightalign" colspan="4" | 138 bytes<br />
|}<br />
<br />
:<h5>ExtRemovePlayerName Packet</h5><br />
:''Server to Client''<br />
:{| class="wikitable"<br />
|- class="row0"<br />
! class="col0" | Packet ID<br />
! class="col1" | Field Name<br />
! class="col2" | Field Type<br />
! class="col3" | Example<br />
! class="col4" | Notes<br />
|- class="row1"<br />
| class="col0 centeralign" | 0x18<br />
(24)<br />
| class="col1 centeralign" | NameID<br />
| class="col2 centeralign" | short<br />
| class="col3 centeralign" | <code>5</code><br />
| class="col4" | Between 0 and 255<br />
Matches NameID of the ExtAddPlayerName packet<br />
|- class="row2"<br />
! class="col0" | Total Size:<br />
| class="col1 rightalign" colspan="4" | 3 bytes<br />
|}<br />
<br />
===EnvColors===<br />
:This extension allows server to alter some of the colors used by the client in environment rendering.<br />
:'''Motivation''': To allow the server to give worlds/maps a unique feel: time-of-day, weather/climate, lighting effect, etc.<br />
:'''Client behavior''': Client must check for '''''EnvSetColor''''' packets right before '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|LevelFinalize]]''''' packet, and apply these changes before the map is displayed. Client must be able to read this packet at other times, but it is not required to then apply the changes immediately. If an unrecognized or unsupported ''Variable'' field is given, no action is needed. If an out-of-range color is given by the server (i.e. if any of ''Red'', ''Green'', or ''Blue'' is less than <code>0</code> or greater than <code>255</code>), then the specified ''Variable'' should be reset to its default value.<br />
:'''Server behavior''': Server should normally only use '''''EnvSetColor''''' packets right before the '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|LevelFinalize]]''''' packet. To reset a variable to its default value, the server should send a packet with value <code>-1</code> for ''Red'', ''Green'', and ''Blue''.<br />
<br />
:<h4>EnvSetColor Packet</h4><br />
:''Server to Client''<br />
:{| class="wikitable"<br />
|- class="row0"<br />
! class="col0" | Packet ID<br />
! class="col1" | Field Name<br />
! class="col2" | Field Type<br />
! class="col3" | Example<br />
! class="col4" | Notes<br />
|- class="row1"<br />
| class="col0 centeralign" rowspan="4" | 0x19<br />
(25)<br />
| class="col1 centeralign" | Variable<br />
| class="col2 centeralign" | byte<br />
| class="col3 centeralign" | <code>1</code><br />
| class="col4" | Enumeration of environmental variables<br />
*0 = sky color<br />
*1 = cloud color<br />
*2 = fog color<br />
*3 = ambient light (blocks in shadow) color<br />
*4 = diffuse light (sunlight) color<br />
|- class="row2"<br />
| class="col1 centeralign" | Red<br />
| class="col2 centeralign" | short<br />
| class="col3 centeralign" | <code>25</code><br />
| class="col4" | Between 0 and 255<br />
|- class="row3"<br />
| class="col1 centeralign" | Green<br />
| class="col2 centeralign" | short<br />
| class="col3 centeralign" | <code>128</code><br />
| class="col4" | Between 0 and 255<br />
|- class="row4"<br />
| class="col1 centeralign" | Blue<br />
| class="col2 centeralign" | short<br />
| class="col3 centeralign" | <code>0</code><br />
| class="col4" | Between 0 and 255<br />
|- class="row5"<br />
! class="col0" | Total Size:<br />
| class="col1 rightalign" colspan="4" | 8 bytes<br />
|}<br />
<br />
===SelectionCuboid===<br />
:'''Motivation''': Allows the server to highlight parts of a world. Applications include zoning, previewing draw commands, previewing undo commands.<br />
:'''Coordinates''': {''StartX'',''StartY'',''StartZ''} are coordinates of the block inside the selection that is closest to the map origin. {''EndX'',''EndY'',''EndZ''} are coordinates of the block inside the selection that is furthest from the map origin. Therefore, the resulting selection has dimensions {''EndX''-''StartX''+1, ''EndY''-''StartY''+1, ''EndZ''-''StartZ''+1).<br />
:'''Client behavior''': Client should be ready to receive '''''MakeSelection''''' packets any time after '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|LevelFinalize]]''''' packet. Upon receiving the packet, a translucent cuboid should appear in the world. The cuboid may feature a plain or "grid" texture. Selections that extend outside the map may be either ignored or clipped to fit. Selections with inconsistent coordinates (e.g. where ''StartX''<''EndX'') may either be ignored or re-ordered. Out-of-range values for ''Red'', ''Green'', ''Blue'', and ''Opacity'' should be clipped to fit the valid range. Supporting ''Opacity'' is optional: the client may opt to provide fixed opacity instead. When map changes (i.e. when '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|LevelInitialize]]''''' packet is received), all existing selections should be removed. '''''RemoveSelection''''' packets that refer to non-existent ''SelectionID''s should be ignored.<br />
:'''Server behavior''': All given coordinates must be contained within the map. End coordinates should be higher or equal than start coordinates.<br />
<br />
:<h4>MakeSelection packet</h4><br />
:''Server to Client''<br />
:{| class="wikitable"<br />
|- class="row0"<br />
! class="col0" | Packet ID<br />
! class="col1" | Field Name<br />
! class="col2" | Field Type<br />
! class="col3" | Example<br />
! class="col4" | Notes<br />
|- class="row1"<br />
| class="col0 centeralign" rowspan="12" | 0x1A<br />
(26)<br />
| class="col1 centeralign" | SelectionID<br />
| class="col2 centeralign" | byte<br />
| class="col3 centeralign" | <code>0</code><br />
| class="col4" | Numeric ID of the selection. Between 0 and 127.<br />
|- class="row2"<br />
| class="col1 centeralign" | Label<br />
| class="col2 centeralign" | string<br />
| class="col3 centeralign" | <code>SomeZone</code><br />
| class="col4" | Text label associated with the selection<br />
|- class="row3"<br />
| class="col1 centeralign" | StartX<br />
| class="col2 centeralign" | short<br />
| class="col3 centeralign" | <code>1</code><br />
| class="col4" | X coordinate of the starting point<br />
|- class="row4"<br />
| class="col1 centeralign" | StartY<br />
| class="col2 centeralign" | short<br />
| class="col3 centeralign" | <code>2</code><br />
| class="col4" | Y coordinate of the starting point<br />
|- class="row5"<br />
| class="col1 centeralign" | StartZ<br />
| class="col2 centeralign" | short<br />
| class="col3 centeralign" | <code>3</code><br />
| class="col4" | Z coordinate of the starting point<br />
|- class="row6"<br />
| class="col1 centeralign" | EndX<br />
| class="col2 centeralign" | short<br />
| class="col3 centeralign" | <code>5</code><br />
| class="col4" | X coordinate of the ending point<br />
|- class="row7"<br />
| class="col1 centeralign" | EndY<br />
| class="col2 centeralign" | short<br />
| class="col3 centeralign" | <code>6</code><br />
| class="col4" | Y coordinate of the ending point<br />
|- class="row8"<br />
| class="col1 centeralign" | EndZ<br />
| class="col2 centeralign" | short<br />
| class="col3 centeralign" | <code>7</code><br />
| class="col4" | Z coordinate of the ending point<br />
|- class="row9"<br />
| class="col1 centeralign" | Red<br />
| class="col2 centeralign" | short<br />
| class="col3 centeralign" | <code>255</code><br />
| class="col4" |Between 0 and 255.<br />
|- class="row10"<br />
| class="col1 centeralign" | Green<br />
| class="col2 centeralign" | short<br />
| class="col3 centeralign" | <code>34</code><br />
| class="col4" |Between 0 and 255.<br />
|- class="row11"<br />
| class="col1 centeralign" | Blue<br />
| class="col2 centeralign" | short<br />
| class="col3 centeralign" | <code>128</code><br />
| class="col4" |Between 0 and 255.<br />
|- class="row12"<br />
| class="col1 centeralign" | Opacity<br />
| class="col2 centeralign" | short<br />
| class="col3 centeralign" | <code>255</code><br />
| class="col4" | 0 = fully transparent<br />
255 = fully opaque<br />
|- class="row4"<br />
! class="col0" | Total Size:<br />
| class="col1 rightalign" colspan="4" | 86 bytes<br />
|}<br />
<br />
:<h4>RemoveSelection packet</h4><br />
:''Server to Client''<br />
:{| class="wikitable"<br />
|- class="row0"<br />
! class="col0" | Packet ID<br />
! class="col1" | Field Name<br />
! class="col2" | Field Type<br />
! class="col3" | Example<br />
! class="col4" | Notes<br />
|- class="row1"<br />
| class="col0 centeralign" | 0x1B<br />
(27)<br />
| class="col1 centeralign" | SelectionID<br />
| class="col2 centeralign" | byte<br />
| class="col3 centeralign" | <code>0</code><br />
| class="col4" |<br />
|- class="row2"<br />
! class="col0" | Total Size:<br />
| class="col1 rightalign" colspan="4" | 2 bytes<br />
|}<br />
<br />
===BlockPermissions===<br />
:This extension allows the server to instruct the player that certain block types are allowed/disallowed to be placed or deleted.<br />
:'''Motivation''': To prevent players from inadvertently placing or removing prohibited block types (e.g. water, lava, grass, admincrete), before it even reaches the server.<br />
:'''Client behavior:''' Client should prevent placement of prohibited block types (by graying out or hiding blocks in block-selection screen, or any other effective means). Client should prevent player from deleting prohibited block types. Client must be ready to receive '''''SetBlockPermission''''' packet after map load ('''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|LevelFinalize]]''''' packet). Permission changes should take effect as soon as packet is received. Admincrete (solid block) permissions set by '''''SetBlockPermission''''' must always override permission set by '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|ServerIdentification]]''''' and '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|UpdateUserType]]''''' packets. If ''BlockType'' is set to <code>0</code>, given permissions should affect ALL block types at once, overriding permissions set by any earlier packets. Permissions must persist between map changes. Client may optionally warn the player attempting to place/delete prohibited blocks via sound effect, visual effect, chat message, etc.<br />
:'''Server behavior:''' Server may send '''''SetBlockPermission''''' packets any time after map load ('''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|LevelFinalize]]''''' packet). Any valid block ID may be specified for ''BlockType'', including custom blocks (if [[#CustomBlocks|CustomBlocks extension]] is mutually supported). ''BlockType'' may be set to <code>0</code> to set permissions for ALL block types at once. Server must not assume that client is compliant/obedient, and server must still verify each '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|SetBlock]]''''' packet coming from the client. What to do with non-complying clients (kick or warn) is up to you.<br />
<br />
:<h4>SetBlockPermission packet</h4><br />
:''Server to Client''<br />
:{| class="wikitable"<br />
|- class="row0"<br />
! class="col0" | Packet ID<br />
! class="col1" | Field Name<br />
! class="col2" | Field Type<br />
! class="col3" | Example<br />
! class="col4" | Notes<br />
|- class="row1"<br />
| class="col0 centeralign" rowspan="4" | 0x1C<br />
(28)<br />
| class="col1 centeralign" | BlockType<br />
| class="col2 centeralign" | byte<br />
| class="col3 centeralign" | <code>8</code><br />
| class="col4" | Block's numeric ID (anything between 1 and max defined block).<br />
|- class="row2"<br />
| class="col1 centeralign" | AllowPlacement<br />
| class="col2 centeralign" | byte<br />
| class="col3 centeralign" | <code>0</code><br />
| class="col4" | 0 = Prohibited<br />
1 or any other value = Allowed<br />
|- class="row2"<br />
| class="col1 centeralign" | AllowDeletion<br />
| class="col2 centeralign" | byte<br />
| class="col3 centeralign" | <code>0</code><br />
| class="col4" | 0 = Prohibited<br />
1 or any other value = Allowed<br />
|- class="row4"<br />
! class="col0" | Total Size:<br />
| class="col1 rightalign" colspan="4" | 4 bytes<br />
|}<br />
<br />
===ChangeModel===<br />
:Allows changing appearance of player models in supporting clients.<br />
:'''Client behavior''': The client will receive a ''EntityID'' and a string value containing the model name. The client will then change the model of the player whose ID is the same as the received '''''AddEntity''''', '''''ExtAddEntity''''', or '''''ExtAddEntity2''''' packet. The model name will be parsed by the model manager and the model changed in game. If the model does not exists in the model manager or is 0-length, change the model back to humanoid. Alternatively, you can send the client an int converted to a string which represents a valid Block ID. An ''EntityID'' of -1 (255 unsigned) indicates the player's own model.<br />
:'''Server behavior''': The server will send a ''EntityID'' and then a ''ModelName'' to the client for a desired player. The model name must exist in the client and not be 0-length or default (humanoid) will be used instead. <br />
<br />
:<h4>ChangeModel Packet</h4><br />
:{| class="wikitable"<br />
|- class="row0"<br />
! class="col0" | Packet ID<br />
! class="col1" | Field Name<br />
! class="col2" | Field Type<br />
! class="col3" | Example<br />
! class="col4" | Notes<br />
|- class="row1"<br />
| class="col0 centeralign" rowspan="2" | 0x1D<br />
(29)<br />
| class="col0 centeralign" | EntityID<br />
| class="col1 centeralign" | byte<br />
| class="col2 centeralign" | 5<br />
| class="col3" | Between 0 and 127. <br />
|- class="row2"<br />
| class="col1 centeralign" | ModelName<br />
| class="col2 centeralign" | string<br />
| class="col3 centeralign" | <code>spider</code><br />
| class="col4" | The name of the model to be used OR a valid Block ID as a string.<br />
|- class="row3"<br />
! class="col0" | Total Size:<br />
| class="col1 rightalign" colspan="4" | 66 bytes<br />
|}<br />
<br />
:<h4>Available models</h4><br />
:Client can render any or none of the below, but it is down to the client to handle what can and cannot be rendered if the packet is recieved<br />
:{| class="wikitable"<br />
!Model Name<br />
!Model String<br />
|-<br />
|'''Chicken'''<br />
|<code>chicken</code><br />
|-<br />
|'''Block Model'''<br />
|A valid block ID as a string<br />
|-<br />
|'''Creeper'''<br />
|<code>creeper</code><br />
|-<br />
|'''Crocodile'''<br />
|<code>croc</code><br />
|-<br />
|'''Humanoid'''<br />
|<code>humanoid</code> (or an invalid model name)<br />
|-<br />
|'''Pig'''<br />
|<code>pig</code><br />
|-<br />
|'''Printer'''<br />
|<code>printer</code><br />
|-<br />
|'''Sheep'''<br />
|<code>sheep</code><br />
|-<br />
|'''Skeleton Archer'''<br />
|<code>skeleton</code><br />
|-<br />
|'''Spider'''<br />
|<code>spider</code><br />
|-<br />
|'''Zombie'''<br />
|<code>zombie</code><br />
|-<br />
|}<br />
<br />
===EnvMapAppearance===<br />
:This extension allows the server to specify custom terrain textures, and tweak appearance of map edges.<br />
:'''Motivation''': To provide more ways to customize map appearance, including functionality that's currently provided by [http://files.worldofminecraft.com/texturing/ World of Minecraft's scheme].<br />
:'''Client behavior:''' Client must be able to receive '''''EnvSetMapAppearance''''' packets any time during level load (after the first '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|LevelDataChunk]]''''' packet is received and until the '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|LevelFinalize]]''''' packet is received). If the ''TextureURL'' field is blank or if the given file could not be loaded for any reason, then the texture pack should be reset to client's default. If an unsupported block ID is given for ''SideBlock'' or ''EdgeBlock'', it should be ignored. Given ''SideLevel'' value should be adjusted to fit between <code>0</code> and <code>MapDepth</code>, if necessary. Client should keep using these appearance parameters for future maps, unless specified otherwise by the server.<br />
:'''Server behavior:''' Server may send '''''EnvSetMapAppearance''''' packets after the last '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|LevelDataChunk]]''''' packet is sent for a level. Server should not use any custom block IDs unless the client declared the appropriate [[#CustomBlocks|CustomBlocks]] support level. To reset the texture pack to default value, server should send an '''''EnvMapAppearance''''' packet with empty string for ''TextureURL''. To reset other fields, server should simply use the default values (listed below).<br />
:'''Block type restrictions:''' Only solid blocks are allowed to be used for ''SideBlock'' and ''EdgeBlock''. Sprites (Sapling, Dandelion, Rose, BrownMushroom, RedMushroom, Rope, Fire) partial-height blocks (Slab, CobblestoneSlab, Snow), and transparent blocks (Air, Leaves, Glass) cannot be used for those fields.<br />
<br />
:<h4>EnvSetMapAppearance packet</h4><br />
:''Server to Client''<br />
:{| class="wikitable"<br />
|- class="row0"<br />
! class="col0" | Packet ID<br />
! class="col1" | Field Name<br />
! class="col2" | Field Type<br />
! class="col3" | Example<br />
! class="col4" | Notes<br />
|- class="row1"<br />
| class="col0 centeralign" rowspan="4" | 0x1E<br />
(30)<br />
| class="col1 centeralign" | TextureURL<br />
| class="col2 centeralign" | string<br />
| class="col3 centeralign" | <code>http://somesite.net/terrain.png</code><br />
| class="col4" | Skin's full URL.<br />
Must be an HTTP URL, ending with .png, and served with <code>image/png</code> mime type.<br />
|- class="row2"<br />
| class="col1 centeralign" | SideBlock<br />
| class="col2 centeralign" | byte<br />
| class="col3 centeralign" | <code>7</code><br />
| class="col4" | Block ID. Default value is 7 (Admincrete).<br />
|- class="row3"<br />
| class="col1 centeralign" | EdgeBlock<br />
| class="col2 centeralign" | byte<br />
| class="col3 centeralign" | <code>8</code><br />
| class="col4" | Block ID. Default value is 8 (Water).<br />
|- class="row4"<br />
| class="col1 centeralign" | SideLevel<br />
| class="col2 centeralign" | short<br />
| class="col3 centeralign" | <code>31</code><br />
| class="col4" | Elevation from bottom of the map, in blocks.<br />
Value should be between <code>0</code> and <code>MapDepth</code>.<br />
Default value is <code>MapDepth/2</code>.<br />
|- class="row5"<br />
! class="col0" | Total Size:<br />
| class="col1 rightalign" colspan="4" | 69 bytes<br />
|}<br />
<br />
===EnvWeatherType===<br />
:This extension allows the server to trigger special weather conditions (like rain and snow) on demand.<br />
:'''Motivation''': To allow the server to give worlds/maps a unique feel with weather effects, e.g. for adventure maps.<br />
:'''Client behavior''': Client must be able to receive '''''EnvWeather''''' packets at any time after the first '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|LevelDataChunk]]''''' packet is received, and apply these changes immediately. If an unrecognized or unsupported ''WeatherType'' field is given, no action is needed.<br />
:'''Server behavior''': Server may send '''''EnvSetColor''''' packets to connected clients at any time after the first '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|LevelDataChunk]]''''' packet is sent.<br />
<br />
:<h4>EnvSetWeatherType Packet</h4><br />
:''Server to Client''<br />
:{| class="wikitable"<br />
|- class="row0"<br />
! class="col0" | Packet ID<br />
! class="col1" | Field Name<br />
! class="col2" | Field Type<br />
! class="col3" | Example<br />
! class="col4" | Notes<br />
|- class="row1"<br />
| class="col0 centeralign" rowspan="4" | 0x1F<br />
(31)<br />
| class="col1 centeralign" | WeatherType<br />
| class="col2 centeralign" | byte<br />
| class="col3 centeralign" | <code>1</code><br />
| class="col4" | Enumeration of weather types<br />
*0 = sunny<br />
*1 = raining<br />
*2 = snowing<br />
|- class="row2"<br />
! class="col0" | Total Size:<br />
| class="col1 rightalign" colspan="4" | 2 bytes<br />
|}<br />
<br />
===HackControl===<br />
:This extension allows the server to control cheats/hacks in the client.<br />
:'''Motivation''': To allow fine-grained control over cheats/hacks on multi-world servers.<br />
:'''Client behavior''': Client must be able to receive '''''HackControl''''' packets at any time after the first '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|LevelDataChunk]]''''' packet is received, and apply these changes immediately. Unrecognized or unsupported values for any field should be ignored. Clients may approximate ''JumpHeight'' by rounding down to the nearest half-block (i.e. nearest multiple of 16), if needed. If a negative value is given for ''JumpHeight'', client should reset jump height to its default setting (around <code>40</code> in vanilla Minecraft).<br />
:'''Server behavior''': Server may send '''''HackControl''''' packets to connected clients at any time after the first '''''[[Classic_Protocol#Server_.E2.86.92_Client_packets|LevelDataChunk]]''''' packet is sent.<br />
<br />
:<h4>HackControl Packet</h4><br />
:''Server to Client''<br />
:{| class="wikitable"<br />
|- class="row0"<br />
! class="col0" | Packet ID<br />
! class="col1" | Field Name<br />
! class="col2" | Field Type<br />
! class="col3" | Example<br />
! class="col4" | Notes<br />
|- class="row1"<br />
| class="col0 centeralign" rowspan="6" | 0x20<br />
(32)<br />
| class="col1 centeralign" | Flying<br />
| class="col2 centeralign" | byte<br />
| class="col3 centeralign" | <code>0</code><br />
| class="col4" |<br />
*0 = Prevent player from flying<br />
*1 = Allow flying<br />
|-<br />
| class="col1 centeralign" | NoClip<br />
| class="col2 centeralign" | byte<br />
| class="col3 centeralign" | <code>0</code><br />
| class="col4" |<br />
*0 = Prevent player from no-clipping (passing through solid blocks)<br />
*1 = Allow no-clipping<br />
|-<br />
| class="col1 centeralign" | Speeding<br />
| class="col2 centeralign" | byte<br />
| class="col3 centeralign" | <code>0</code><br />
| class="col4" |<br />
*0 = Only allow normal walking speed.<br />
*1 = Allow moving at any speeds.<br />
|-<br />
| class="col1 centeralign" | SpawnControl<br />
| class="col2 centeralign" | byte<br />
| class="col3 centeralign" | <code>1</code><br />
| class="col4" |<br />
*0 = Prevent player from pressing [R] to respawn, or using [Enter] to change spawn.<br />
*1 = Allow player to respawn / change spawn.<br />
|-<br />
| class="col1 centeralign" | ThirdPersonView<br />
| class="col2 centeralign" | byte<br />
| class="col3 centeralign" | <code>1</code><br />
| class="col4" |<br />
*0 = Disallow third-person view (only first-person view allowed).<br />
*1 = Allow third-person view.<br />
|-<br />
| class="col1 centeralign" | JumpHeight<br />
| class="col2 centeralign" | short<br />
| class="col3 centeralign" | <code>40</code><br />
| class="col4" | Maximum height, in terms of player movement units (1/32<sup>nd</sup>s of a block), to which the player is allowed to jump.<br />
Negative value (e.g. <code>-1</code>) means that the client should use its default jump height.<br />
|- class="row2"<br />
! class="col0" | Total Size:<br />
| class="col1 rightalign" colspan="4" | 8 bytes<br />
|}<br />
<br />
===MessageTypes===<br />
[[Image:Messagetypes.PNG|right|700px|Examples of all possible MessageTypes.]]<br />
:This extension adds new ways of presenting messages in the client.<br />
:'''Motivation''': To enhance the display of announcements and status information, and to reduce chat clutter.<br />
:'''Client behavior''': When this extension is mutually supported, the ''PlayerID'' field of the standard server-to-client [[Classic_Protocol#Server_.E2.86.92_Client_packets|'''''Message''''']] packet should be treated as a ''MessageType'' code. Unrecognized or unsupported codes may be ignored (in which case the message should be presented as a regular chat message). When connected to non-supporting servers, this field should be ignored.<br />
:'''Server behavior''': Server may use the ''PlayerID'' field of the [[Classic_Protocol#Server_.E2.86.92_Client_packets|'''''Message''''']] packet to set a ''MessageType''. For non-supporting clients, this field should always be set to <code>0</code>.<br />
<br />
:{| class="wikitable"<br />
!MessageType<br />
!Meaning<br />
!Suggested Implementation<br />
|-<br />
|<code>0</code><br />
|Chat<br />
|Normal message, shown in the chat area.<br />
|-<br />
|<code>1</code><br />
|Status1<br />
|Shown persistently in the top-right corner of the screen, in regular font.<br />
|-<br />
|<code>2</code><br />
|Status2<br />
|Shown persistently just below Status1<br />
|-<br />
|<code>3</code><br />
|Status3<br />
|Shown persistently just below Status2<br />
|-<br />
|<code>11</code><br />
|BottomRight1<br />
|Shown persistently in the bottom-right corner of the screen, in regular font.<br />
|-<br />
|<code>12</code><br />
|BottomRight2<br />
|Shown persistently just above BottomRight1<br />
|-<br />
|<code>13</code><br />
|BottomRight3<br />
|Shown persistently just above BottomRight2<br />
|-<br />
|<code>100</code><br />
|Announcement<br />
|Pops up in larger font near the top-center of the screen. Fades out after a few seconds.<br />
|}<br />
<br />
:This extension does not define any new packets.<br />
<br />
[[Category:Minecraft Classic]]</div>Aragashttps://wiki.vg/index.php?title=Classic_DAT_Format&diff=6173Classic DAT Format2014-10-10T18:01:14Z<p>Aragas: Added to Classic Category fix</p>
<hr />
<div>The Classic level format is used by all varieties of Minecraft Classic. It is compressed with [[Wikipedia:Gzip|gzip]] and contains a short header followed by serialized Java objects. Single-player levels have the extension ".mine". Levels used by the Classic Creative server are named "server_level.dat". The file can be backed up to save content which helps to protect constructions against [[griefing|griefers]] or to use the file for [[Map Editing|map editing]].<br />
<br />
Because the format of this level depends on the way Java serializes objects, the easiest way to work with it is through the Classic server itself, <span class="plainlinks">[http://minecraft.net/servers.jsp minecraft-server.jar]</span>. [[Creation and saving class|Sample code]] is provided to show how to build an editor on top of minecraft-server.jar.<br />
<br />
=== File Format ===<br />
<br />
When uncompressed, the format of the file is as follows:<br />
<br />
{| border="1" class="wikitable"<br />
! Position<br />
! Size (bytes)<br />
! Name<br />
! Description<br />
|-<br />
| 0<br />
| 4<br />
| Magic ID<br />
| A magic ID is a constant number used to identify the Minecraft file format. The current value is '''0x271bb788'''.<br />
|-<br />
| 4<br />
| 1<br />
| Version Number<br />
| The version number represents the current format used to save the level. The current value is '''2'''.<br />
|-<br />
| 5<br />
| Variable<br />
| Serialized Java ''com.mojang.minecraft.level.Level'' Class<br />
| More information about the serialization format used by Java is available in the [http://java.sun.com/developer/technicalArticles/Programming/serialization/ manual], however, the easiest way to edit the file is to use the [[Creation and saving class|classes]] provided here with the official <span class="plainlinks">[http://minecraft.net/servers.jsp minecraft-server.jar file]</span>.<br />
|}<br />
<br />
==Accessing the array of bytes==<br />
<br />
The most interesting part of a level is the block array. Each byte in this array defines a [[Data values|block type]] at a corresponding location in the world. One generally has two options for accessing the byte array of blocks: <br />
<br />
You could deserialize the compressed .dat file directly back into an instance of a Level object inside of Java, thus having access to the instance of the Level object in exactly the same way the Minecraft Server does. This would allow you to set the blocks, dimensions, spawn point and other aspects of the map directly by calling the methods on the instantiated Level object. Manual decompression is not needed before loading, because Java can compress and decompress gzipped files on the fly. To load the datafile back into an instance of the Level class, you would need the class definition for the Level class. This is included with the minecraft-server.jar file. An example of this can be seen in the [[creation and saving class]].<br />
<br />
Others have read and modified the map's data by simply accessing the raw byte array in the datafile file. To do this, you would decompress it, make changes to the bytes where the byte array is stored, and then compress it again. Since you are editing it raw, you must keep the first 344 (14E in HEX) bytes intact. The next 256x256x64 bytes are where the byte array is stored. Additionally, it is also possible to alter the spawn location coordinates this way if you know where to look: there are 3 integer values starting at byte 284 and thus overwriting the next 12 bytes (3 integers) will allow you to change the spawn location. <br />
<br />
(Disclaimer: This is liable to change as Java changes)<br />
<br />
{{minecraft}}<br />
<br />
[[Category:Server]] [[Category:Minecraft Classic]]<br />
<br />
[[de:Classic Level Format]]<br />
[[fr:Format de carte Classique]]<br />
[[ru:Классический формат карт]]</div>Aragashttps://wiki.vg/index.php?title=Classic_DAT_Format&diff=6172Classic DAT Format2014-10-10T18:00:45Z<p>Aragas: Added to Classic Category</p>
<hr />
<div>The Classic level format is used by all varieties of Minecraft Classic. It is compressed with [[Wikipedia:Gzip|gzip]] and contains a short header followed by serialized Java objects. Single-player levels have the extension ".mine". Levels used by the Classic Creative server are named "server_level.dat". The file can be backed up to save content which helps to protect constructions against [[griefing|griefers]] or to use the file for [[Map Editing|map editing]].<br />
<br />
Because the format of this level depends on the way Java serializes objects, the easiest way to work with it is through the Classic server itself, <span class="plainlinks">[http://minecraft.net/servers.jsp minecraft-server.jar]</span>. [[Creation and saving class|Sample code]] is provided to show how to build an editor on top of minecraft-server.jar.<br />
<br />
=== File Format ===<br />
<br />
When uncompressed, the format of the file is as follows:<br />
<br />
{| border="1" class="wikitable"<br />
! Position<br />
! Size (bytes)<br />
! Name<br />
! Description<br />
|-<br />
| 0<br />
| 4<br />
| Magic ID<br />
| A magic ID is a constant number used to identify the Minecraft file format. The current value is '''0x271bb788'''.<br />
|-<br />
| 4<br />
| 1<br />
| Version Number<br />
| The version number represents the current format used to save the level. The current value is '''2'''.<br />
|-<br />
| 5<br />
| Variable<br />
| Serialized Java ''com.mojang.minecraft.level.Level'' Class<br />
| More information about the serialization format used by Java is available in the [http://java.sun.com/developer/technicalArticles/Programming/serialization/ manual], however, the easiest way to edit the file is to use the [[Creation and saving class|classes]] provided here with the official <span class="plainlinks">[http://minecraft.net/servers.jsp minecraft-server.jar file]</span>.<br />
|}<br />
<br />
==Accessing the array of bytes==<br />
<br />
The most interesting part of a level is the block array. Each byte in this array defines a [[Data values|block type]] at a corresponding location in the world. One generally has two options for accessing the byte array of blocks: <br />
<br />
You could deserialize the compressed .dat file directly back into an instance of a Level object inside of Java, thus having access to the instance of the Level object in exactly the same way the Minecraft Server does. This would allow you to set the blocks, dimensions, spawn point and other aspects of the map directly by calling the methods on the instantiated Level object. Manual decompression is not needed before loading, because Java can compress and decompress gzipped files on the fly. To load the datafile back into an instance of the Level class, you would need the class definition for the Level class. This is included with the minecraft-server.jar file. An example of this can be seen in the [[creation and saving class]].<br />
<br />
Others have read and modified the map's data by simply accessing the raw byte array in the datafile file. To do this, you would decompress it, make changes to the bytes where the byte array is stored, and then compress it again. Since you are editing it raw, you must keep the first 344 (14E in HEX) bytes intact. The next 256x256x64 bytes are where the byte array is stored. Additionally, it is also possible to alter the spawn location coordinates this way if you know where to look: there are 3 integer values starting at byte 284 and thus overwriting the next 12 bytes (3 integers) will allow you to change the spawn location. <br />
<br />
(Disclaimer: This is liable to change as Java changes)<br />
<br />
{{minecraft}}<br />
<br />
[[Category:Server|Minecraft Classic]]<br />
<br />
[[de:Classic Level Format]]<br />
[[fr:Format de carte Classique]]<br />
[[ru:Классический формат карт]]</div>Aragashttps://wiki.vg/index.php?title=Classic_Protocol&diff=6171Classic Protocol2014-10-10T17:58:02Z<p>Aragas: Added to Classic Category</p>
<hr />
<div>Documentation on the server protocol used by the [http://minecraft.net/servers.jsp Minecraft Classic Creative] server.<br />
<br />
==Minecraft.net Communication==<br />
===Heartbeats===<br />
To be able to connect to a server in Minecraft Classic from the Server List, a server must broadcast to minecraft.net a so-called "heartbeat" every few minutes.<br />
<br />
The stock server broadcasts this heartbeat every 45 seconds.<br />
<br />
A "heartbeat" takes the form of an HTTP request to http://www.minecraft.net/heartbeat.jsp.<br />
After sending a heartbeat, the URL for the server is returned.<br />
<br />
It can be a GET or POST request. A table of the required parameters is below:<br />
{| class="wikitable"<br />
!Name !!Details<br />
|-<br />
|port || Port number of the server. This is usually 25565<br />
|-<br />
|max || Maximum number of players on the server<br />
|-<br />
|name || The name of the server<br />
|-<br />
|public || Whether the server is public (i.e. appears in the lobby) or not. Can be '''True''' or '''False''', in that capitalisation.<br />
|-<br />
|version || Minecraft version, this should be 7<br />
|-<br />
|salt || A random, 16-character base-62 salt<br />
|-<br />
|users || Number of users connected to the server<br />
|}<br />
The simplest way to send a heartbeat is to open a TCP socket to port 80 on minecraft.net, and send the following (with the values changed, obviously):<br />
<br />
'''GET /heartbeat.jsp?port=25565&max=32&name=My%20Server&public=True&version=7&salt=wo6kVAHjxoJcInKx&users=0''', plus a CRLF(Carriage-return and Line feed).<br />
<br />
Make sure any strings, like name, are escaped.<br />
<br />
If everything goes well, in the response body you'll receive a URL to the server. Otherwise you'll get a nice HTML error message. There aren't an HTML headers to parse, as the HTTP version is not specified so HTTP/0.9 is used, which does not have headers.<br />
<br />
===User Authentication===<br />
The "key" provided when a user joins the server can be compared to the MD5 checksum of the server's "salt" plus the username to verify that the user is logged in to minecraft.net with that username. This is useful for establishing enough trust of the name provided to ban or op the player by name.<br />
<br />
if( player.key == md5( server.salt + player.name ) ) {<br />
// player is logged in via minecraft.net<br />
} else {<br />
// player is forging the username<br />
}<br />
<br />
Note: This means that you should make sure your "salt" is kept a secret and shared only with heartbeat.jsp. If your server's "salt" is visible anywhere to users, it is trivial for users to produce valid-looking "key"s without being logged in to minecraft.net.<br />
<br />
===Skins===<br />
Skins for a player are downloaded by the client from '''http://minecraft.net/skin/skinname.png''', where skinname is the name of the player. This means that the name for a player can be faked to give a desired skin.<br />
<br />
==Packet Protocol==<br />
<br />
Every packet starts with a byte representing the Packet ID.<br />
<br />
=== Protocol Data Types ===<br />
{| class="wikitable"<br />
!Type !! Size [bytes] !! Description<br />
|-<br />
|Byte || 1 || Single byte integer (0 to 255)<br />
|-<br />
|SByte || 1 || Single byte signed integer (-128 to 127)<br />
|-<br />
|Short || 2 || Signed integer, [http://en.wikipedia.org/wiki/Endianness#Endianness_in_networking network order] (-32768 to 32767)<br />
|-<br />
|String || 64 || US-ASCII/ISO646-US encoded string padded with spaces (0x20)<br />
|-<br />
|Byte array || 1024 || Binary data padded with null bytes (0x00)<br />
|}<br />
<br />
=== Client &rarr; Server packets ===<br />
{| class="wikitable"<br />
!width="64"| Packet ID<br />
!width="160"| Purpose<br />
!width="160"| Field Description<br />
!width="72"| Field Type<br />
! Notes<br />
|-<br />
|rowspan=5| 0x00<br />
|rowspan=5| Player Identification<br />
| Packet ID || Byte<br />
|rowspan=5| Sent by a player joining a server with relevant information. Current protocol version is 0x07.<br />
|-<br />
| Protocol version || Byte<br />
|-<br />
| Username || String<br />
|-<br />
| Verification key || String<br />
|-<br />
| Unused || Byte<br />
|-<br />
|rowspan=6| 0x05<br />
|rowspan=6| Set Block<br />
| Packet ID || Byte<br />
|rowspan=6| Sent when a user changes a block. The mode field indicates whether a block was created (0x01) or destroyed (0x00).<br />
Block type is always the type player is holding, (even when deleting).<br />
<br />
Client assumes that this command packet always succeeds, and so draws the new block immediately. To disallow block creation, server must send back Set Block packet with the old block type.<br />
<br />
The XYZ coordinates of the block are just shorts representing the coordinate of the block. (As opposed to player coordinates where the lower 5 bits are fractional coordinates)<br />
|-<br />
| X || Short<br />
|-<br />
| Y || Short<br />
|-<br />
| Z || Short<br />
|-<br />
| Mode || Byte<br />
|-<br />
| Block type || Byte<br />
|-<br />
|rowspan=7| 0x08<br />
|rowspan=7| Position and Orientation<br />
| Packet ID || Byte<br />
|rowspan=7| Sent frequently (even while not moving) by the player with the player's current location and orientation. Player ID is always 255, referring to itself. Player coordinates are fixed-point values with the lowest 5 bits representing the fractional position (i.e. divide by 32 to get actual position in terms of block coordinates). The angle parameters are scaled such that a value of 256 would correspond to 360 degrees.<br />
|-<br />
| Player ID || Byte<br />
|-<br />
| X || Short<br />
|-<br />
| Y || Short<br />
|-<br />
| Z || Short<br />
|-<br />
| Yaw (Heading) || Byte<br />
|-<br />
| Pitch || Byte<br />
|-<br />
|rowspan=3| 0x0d<br />
|rowspan=3| Message<br />
| Packet ID || Byte<br />
|rowspan=3| Contain chat messages sent by player. (See [[Chat|How chat works]])<br />
|-<br />
| Unused || Byte (0xFF)<br />
|-<br />
| Message || String<br />
|}<br />
<br />
=== Server &rarr; Client packets ===<br />
{| class="wikitable"<br />
!width="64"| Packet ID<br />
!width="160"| Purpose<br />
!width="160"| Field Description<br />
!width="72"| Field Type<br />
! Notes<br />
|-<br />
|rowspan=5| 0x00<br />
|rowspan=5| Server Identification<br />
| Packet ID || Byte<br />
|rowspan=5| Response to a joining player. The user type indicates whether a player is an op (0x64) or not (0x00) Current protocol version is 0x07.<br />
|-<br />
| Protocol version || Byte<br />
|-<br />
| Server name || String<br />
|-<br />
| Server MOTD || String<br />
|-<br />
| User type || Byte<br />
|-<br />
| 0x01<br />
| Ping<br />
| Packet ID || Byte<br />
| Sent to clients periodically. The only way a client can disconnect at the moment is to force it closed, which does not let the server know. The ping packet is used to determine if the connection is still open.<br />
|-<br />
| 0x02<br />
| Level Initialize<br />
| Packet ID || Byte<br />
| Notifies player of incoming level data.<br />
|-<br />
|rowspan=4| 0x03<br />
|rowspan=4| Level Data Chunk<br />
| Packet ID || Byte<br />
|rowspan=4| Contains a chunk of gzipped map (not level.dat file). After decompression the map consists of a big-endian int(4 bytes) containing the number of blocks, followed by a raw map array. (chunk is up to 1024 bytes, padded with 0x00s if less).<br />
|-<br />
| Chunk Length || Short<br />
|-<br />
| Chunk Data || Byte Array<br />
|-<br />
| Percent Complete || Byte<br />
|-<br />
|rowspan=4| 0x04<br />
|rowspan=4| Level Finalize<br />
| Packet ID || Byte<br />
|rowspan=4| Sent after level data is complete and gives map dimensions. The y coordinate is how tall the map is.<br />
|-<br />
| X Size || Short<br />
|-<br />
| Y Size || Short<br />
|-<br />
| Z Size || Short<br />
|-<br />
|rowspan=5| 0x06<br />
|rowspan=5| Set Block<br />
| Packet ID || Byte<br />
|rowspan=5| Sent to indicate a block change by physics or by players. In the case of a player change, the server will also echo the block change back to the player who initiated it.<br />
|-<br />
| X || Short<br />
|-<br />
| Y || Short<br />
|-<br />
| Z || Short<br />
|-<br />
| Block Type || Byte<br />
|-<br />
|rowspan=8| 0x07<br />
|rowspan=8| Spawn Player<br />
| Packet ID || Byte<br />
|rowspan=8| Sent to indicate where a new player is spawning in the world. Position and orientation are encoded the same as for packet 0x08 below. PlayerID -1 (255 unsigned) indicates the player's self. This will set the player's spawn point.<br />
|-<br />
| Player ID || SByte<br />
|-<br />
| Player Name || String<br />
|-<br />
| X || Short<br />
|-<br />
| Y || Short<br />
|-<br />
| Z || Short<br />
|-<br />
| Yaw (Heading) || Byte<br />
|-<br />
| Pitch || Byte<br />
|-<br />
|rowspan=7| 0x08<br />
|rowspan=7| Position and Orientation (Player Teleport)<br />
| Packet ID || Byte<br />
|rowspan=7| Sent with changes in player position and rotation. Teleports player it's sent to if player ID < 0 (For sending initial position in map, and /tp)<br />
|-<br />
| Player ID || SByte<br />
|-<br />
| X || Short<br />
|-<br />
| Y || Short<br />
|-<br />
| Z || Short<br />
|-<br />
| Yaw (Heading) || Byte<br />
|-<br />
| Pitch || Byte<br />
|-<br />
|rowspan=7| 0x09<br />
|rowspan=7| Position and Orientation Update<br />
| Packet ID || Byte<br />
|rowspan=7| Sent with changes in player position and rotation. Sent when both position and orientation is changed at the same time.<br />
Not required for server operation.<br />
|-<br />
| Player ID || SByte<br />
|-<br />
| Change in X || SByte<br />
|-<br />
| Change in Y || SByte<br />
|-<br />
| Change in Z || SByte<br />
|-<br />
| Yaw (Heading) || Byte<br />
|-<br />
| Pitch || Byte<br />
|-<br />
|rowspan=5| 0x0a<br />
|rowspan=5| Position Update<br />
| Packet ID || Byte<br />
|rowspan=5| Sent with changes in player position.<br />
Not required for server operation.<br />
|-<br />
| Player ID || SByte<br />
|-<br />
| Change in X || SByte<br />
|-<br />
| Change in Y || SByte<br />
|-<br />
| Change in Z || SByte<br />
|-<br />
|rowspan=4| 0x0b<br />
|rowspan=4| Orientation Update<br />
| Packet ID || Byte<br />
|rowspan=4| Sent with changes in player rotation.<br />
Not required for server operation.<br />
|-<br />
| Player ID || SByte<br />
|-<br />
| Yaw (Heading) || Byte<br />
|-<br />
| Pitch || Byte<br />
|-<br />
|rowspan=2| 0x0c<br />
|rowspan=2| Despawn Player<br />
| Packet ID || Byte<br />
|rowspan=2| Sent when player disconnects.<br />
|-<br />
| Player ID || SByte<br />
|-<br />
|rowspan=3| 0x0d<br />
|rowspan=3| Message<br />
| Packet ID || Byte<br />
|rowspan=3| Messages sent by chat or from the console. (See [[Chat|How chat works]])<br />
|-<br />
| Player ID || SByte<br />
|-<br />
| Message || String<br />
|-<br />
|rowspan=2| 0x0e<br />
|rowspan=2| Disconnect player<br />
| Packet ID || Byte<br />
|rowspan=2| Sent to a player when they're disconnected from the server.<br />
#"Cheat detected: Distance" - happens not only when setting tile too far away from the player (how far is maximum distance and how it is measured?), but also when player moves and then immediately builds.<br />
#"Cheat detected: Tile type"<br />
#"Cheat detected: Too much clicking!"<br />
#"Cheat detected: Too much lag"<br />
|-<br />
| Disconnect reason || String<br />
|-<br />
|rowspan=2| 0x0f<br />
|rowspan=2| Update user type<br />
| Packet ID || Byte<br />
|rowspan=2| Sent when a player is opped/deopped. User type is 0x64 for op, 0x00 for normal user.<br />
|-<br />
| User type || Byte<br />
|-<br />
|}<br />
<br />
==Player Position==<br />
===Fixed Point===<br />
Player position is represented via X, Y, and Z fixed-point coordinates. The fractional portion is 5 bits, so dividing the short integers received in position update packets by 32, you will have floating point coordinates for the player. This position corresponds to the center of the client viewport.<br />
===Standing On Things===<br />
The bottom of the player's feet is located 1.59375 (fixed-point: 51) units below the center of the viewport, so to position the player on top of a particular block you could send a teleport (0x08) packet specifying a Y value based on the block position as: (Y x 32 + 51)<br />
===Orientation===<br />
A yaw value of 0 means the player is facing in the Z=0 (negative Z) direction. This value increases in a clockwise direction as seen from above. If we call the negative Z direction "North", then a yaw of 64 means "East", 128 means "South", and 192 means "West".<br />
<br />
A pitch value of 0 means level and this value increases in a downward direction. 64 is down, and 192 is up. Values of 65 to 191 should never occur because the player cannot look further up or down than the 64 → 0, 255 → 192 range. However, the Minecraft Classic client does not ignore invalid values, so it is possible to make players' heads "upside-down".<br />
<br />
==Color Codes==<br />
Messages sent from the server to the client can contain color codes, which allow coloring of text for various purposes.<br />
<br />
An ampersand followed by a hex digit in the message tells the client to switch colors while displaying text.<br />
<br />
Colour coding at the start of the message will only work if the player ID byte is less than 127. If it's 127 or higher, the game automatically adds &e before the message, making it yellow. However, colour codes after the first character still work. If you use an ID below 127, it doesn't add a colour code, so the ones you use will work.<br />
<br />
It is important to note that an ampersand at the end of a message that is not followed by a hex digit will crash all clients that receive it, so it is a must to sanitize chat messages received from clients.<br />
<br />
[[File:Colors.png|thumb|Hex digit to color mapping]]<br />
<br />
{| class="wikitable" style="text-align:center;" border="1" cellpadding="5"<br />
|-<br />
! colspan="1" width="8px"| Sample<br />
! colspan="1" | Code<br />
! colspan="1" | Common Name<br />
! colspan="3" | Foreground Color<br />
! colspan="3" | Background Color<br />
|-<br />
| || ||<br />
|width="30px"|R<br />
|width="30px"|G<br />
|width="30px"|B<br />
|width="30px"|R<br />
|width="30px"|G<br />
|width="30px"|B<br />
|-<br />
| bgcolor="black" |<br />
| &0 || Black || 0 || 0 || 0 || 0 || 0 || 0<br />
|-<br />
| bgcolor=#0000BF |<br />
| &1 || Dark Blue || 0 || 0 || 191 || 0 || 0 || 47<br />
|-<br />
| bgcolor=#00BF00 |<br />
| &2 || Dark Green || 0 || 191 || 0 || 0 || 47 || 0<br />
|-<br />
| bgcolor=#00BFBF |<br />
| &3 || Dark Teal || 0 || 191 || 191 || 0 || 47 || 47<br />
|-<br />
| bgcolor=#BF0000 |<br />
| &4 || Dark Red || 191 || 0 || 0 || 47 || 0 || 0<br />
|-<br />
| bgcolor=#BF00BF |<br />
| &5 || Purple || 191 || 0 || 191 || 47 || 0 || 47<br />
|-<br />
| bgcolor=#BFBF00 |<br />
| &6 || Gold || 191 || 191 || 0 || 47 || 47 || 0<br />
|-<br />
| bgcolor=#BFBFBF |<br />
| &7 || Gray || 191 || 191 || 191 || 47 || 47 || 47<br />
|-<br />
| bgcolor=#404040 |<br />
| &8 || Dark Gray || 64 || 64 || 64 || 16 || 16 || 16<br />
|-<br />
| bgcolor=#4040FF |<br />
| &9 || Blue || 64 || 64 || 255 || 16 || 16 || 63<br />
|-<br />
| bgcolor=#49FF40 |<br />
| &a || Bright Green || 64 || 255 || 64 || 16 || 63 || 16<br />
|-<br />
| bgcolor=#40FFFF |<br />
| &b || Teal || 64 || 255 || 255 || 16 || 63 || 63<br />
|-<br />
| bgcolor=#FF4040 |<br />
| &c || Red || 255 || 64 || 64 || 63 || 16 || 16<br />
|-<br />
| bgcolor=#FF40FF |<br />
| &d || Pink || 255 || 64 || 255 || 63 || 16 || 63<br />
|-<br />
| bgcolor=#FFFF40 |<br />
| &e || Yellow || 255 || 255 || 64 || 63 || 63 || 16<br />
|-<br />
| bgcolor=#FFFFFF |<br />
| &f || White || 255 || 255 || 255 || 63 || 63 || 63<br />
|}<br />
<br />
[[Category:Minecraft Classic]]</div>Aragashttps://wiki.vg/index.php?title=Data_types&diff=6133Data types2014-09-27T11:00:31Z<p>Aragas: /* Position */ ops</p>
<hr />
<div>All data sent over the network is [http://en.wikipedia.org/wiki/Endianness#Big-endian big-endian], that is the bytes are sent from most significant byte to least significant byte. The majority of everyday computers are little-endian, therefore it may be necessary to change the endianness before sending data over the network.<br />
<br />
Other than 'String' and 'Metadata', which are decoded with a custom function, these data formats are identical to those provided by the Java classes [http://download.oracle.com/javase/1.4.2/docs/api/java/io/DataInputStream.html DataInputStream] and [http://download.oracle.com/javase/1.4.2/docs/api/java/io/DataOutputStream.html DataOutputStream].<br />
<br />
{| class="wikitable"<br />
|- class="row0"<br />
| class="col0" |<br />
! class="col1" | Size<br />
! class="col2" | Range<br />
! class="col3" | Notes<br />
|- class="row1"<br />
! class="col0 centeralign" | bool<br />
| class="col1 centeralign" | 1<br />
| class="col2" | 0 or 1<br />
| class="col3" | Value can be either true (0x01) or false (0x00)<br />
|- class="row2"<br />
! class="col0 centeralign" | byte<br />
| class="col1 centeralign" | 1<br />
| class="col2" | -128 to 127<br />
| class="col3" | Signed, two's complement<br />
|- class="row3"<br />
! class="col0 centeralign" | short<br />
| class="col1 centeralign" | 2<br />
| class="col2" | -32768 to 32767<br />
| class="col3" | Signed, two's complement<br />
|- class="row4"<br />
! class="col0 centeralign" | int<br />
| class="col1 centeralign" | 4<br />
| class="col2" | -2147483648 to 2147483647<br />
| class="col3" | Signed, two's complement<br />
|- class="row5"<br />
! class="col0 centeralign" | long<br />
| class="col1 centeralign" | 8<br />
| class="col2" | -9223372036854775808 to 9223372036854775807<br />
| class="col3" | Signed, two's complement<br />
|- class="row8"<br />
! class="col0 centeralign" | 128-bit integer<br />
| class="col1 centeralign" | 16<br />
| class="col2" | 0 to 340282366920938463463374607431768211455<br />
| class="col3" | Unsigned, two's complement<br />
<br />
Used in [http://wiki.vg/Protocol#Spawn_Global_Entity 0x2C] to transmit UUIDs.<br />
<br />
The vanilla Minecraft server internally sends this as two longs.<br />
|- class="row7"<br />
! class="col0 centeralign" | float<br />
| class="col1 centeralign" | 4<br />
| class="col2" |<br />
See [http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3 this]<br />
| class="col3" | Single-precision 32-bit IEEE 754 floating point<br />
|- class="row8"<br />
! class="col0 centeralign" | double<br />
| class="col1 centeralign" | 8<br />
| class="col2" |<br />
See [http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3 this]<br />
| class="col3" | Double-precision 64-bit IEEE 754 floating point<br />
|- class="row9"<br />
! class="col0 centeralign" | string<br />
| class="col1 centeralign" | ≥ 2 <br />≤ 240<br />
| class="col2" | N/A<br />
| class="col3" | UTF-8 String length prefixed with a VarInt<br />
|- <br />
! class="centeralign" | VarInt<br />
| class="centeralign" | Varies<br />
| [http://developers.google.com/protocol-buffers/docs/encoding#varints Protocol Buffer 32-bit Varint]<br />
|<br />
|-<br />
! VarLong<br />
| Varies<br />
| <br />
| Like VarInt but for java longs<br />
|- class="row9"<br />
! class="col0 centeralign" | metadata<br />
| class="col1 centeralign" | Varies<br />
| class="col2" | See [[Entities#Entity_Metadata_Format|this]]<br />
| class="Col3" | <br />
|- <br />
! class="centeralign" | Slot Data<br />
| class="centeralign" | Varies<br />
| See [[Slot_Data|slot data]]<br />
|<br />
|-<br />
! Position <br />
| 8<br />
| <br />
| See below<br />
|-<br />
! UUID<br />
| 16<br />
|<br />
| Encoded as two longs this.writeLong(uuid.getMostSignificantBits()); this.writeLong(uuid.getLeastSignificantBits());<br />
|}<br />
<br />
=== Position ===<br />
<br />
Encoded as followed:<br />
<br />
((x & 0x3FFFFFF) << 38) | ((y & 0xFFF) << 26) | (z & 0x3FFFFFF)<br />
<br />
<br />
And decoded as:<br />
<br />
long val; // Encoded value<br />
x = val >> 38;<br />
y = (val >> 26) & 0xFFF<br />
z = val << 38 >> 38<br />
<br />
=== Fixed-point numbers ===<br />
<br />
Some fields may be stored as [https://en.wikipedia.org/wiki/Fixed-point_arithmetic fixed-point numbers], where a certain number of bits represents the signed integer part (number to the left of the decimal point) and the rest represents the fractional part (to the right). Floating points (float and double), in contrast, keep the number itself (mantissa) in one chunk, while the location of the decimal point (exponent) is stored beside it. <br />
<br />
Essentially, while fixed-point numbers have lower range than floating points, their fractional precision is greater for higher values. This makes them ideal for representing global coordinates of an entity in Minecraft, as it's more important to store the integer part accurately than position them more precisely within a single block (or meter). <br />
<br />
Coordinates are often represented as a 32-bit integer, where 5 of the least-significant bits are dedicated to the fractional part, and the rest store the integer part.<br />
<br />
Java lacks support for fractional integers directly, but you can represent them as integers. To convert from a double to this integer representation, use the following formulas:<br />
abs_int = (int)double * 32;<br />
And back again:<br />
<br />
double = (double)abs_int / 32;<br />
<br />
[[Category:Protocol Details]]<br />
[[Category:Minecraft Modern]]</div>Aragashttps://wiki.vg/index.php?title=Data_types&diff=6132Data types2014-09-27T10:28:25Z<p>Aragas: /* Position */ decode and encode fix</p>
<hr />
<div>All data sent over the network is [http://en.wikipedia.org/wiki/Endianness#Big-endian big-endian], that is the bytes are sent from most significant byte to least significant byte. The majority of everyday computers are little-endian, therefore it may be necessary to change the endianness before sending data over the network.<br />
<br />
Other than 'String' and 'Metadata', which are decoded with a custom function, these data formats are identical to those provided by the Java classes [http://download.oracle.com/javase/1.4.2/docs/api/java/io/DataInputStream.html DataInputStream] and [http://download.oracle.com/javase/1.4.2/docs/api/java/io/DataOutputStream.html DataOutputStream].<br />
<br />
{| class="wikitable"<br />
|- class="row0"<br />
| class="col0" |<br />
! class="col1" | Size<br />
! class="col2" | Range<br />
! class="col3" | Notes<br />
|- class="row1"<br />
! class="col0 centeralign" | bool<br />
| class="col1 centeralign" | 1<br />
| class="col2" | 0 or 1<br />
| class="col3" | Value can be either true (0x01) or false (0x00)<br />
|- class="row2"<br />
! class="col0 centeralign" | byte<br />
| class="col1 centeralign" | 1<br />
| class="col2" | -128 to 127<br />
| class="col3" | Signed, two's complement<br />
|- class="row3"<br />
! class="col0 centeralign" | short<br />
| class="col1 centeralign" | 2<br />
| class="col2" | -32768 to 32767<br />
| class="col3" | Signed, two's complement<br />
|- class="row4"<br />
! class="col0 centeralign" | int<br />
| class="col1 centeralign" | 4<br />
| class="col2" | -2147483648 to 2147483647<br />
| class="col3" | Signed, two's complement<br />
|- class="row5"<br />
! class="col0 centeralign" | long<br />
| class="col1 centeralign" | 8<br />
| class="col2" | -9223372036854775808 to 9223372036854775807<br />
| class="col3" | Signed, two's complement<br />
|- class="row8"<br />
! class="col0 centeralign" | 128-bit integer<br />
| class="col1 centeralign" | 16<br />
| class="col2" | 0 to 340282366920938463463374607431768211455<br />
| class="col3" | Unsigned, two's complement<br />
<br />
Used in [http://wiki.vg/Protocol#Spawn_Global_Entity 0x2C] to transmit UUIDs.<br />
<br />
The vanilla Minecraft server internally sends this as two longs.<br />
|- class="row7"<br />
! class="col0 centeralign" | float<br />
| class="col1 centeralign" | 4<br />
| class="col2" |<br />
See [http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3 this]<br />
| class="col3" | Single-precision 32-bit IEEE 754 floating point<br />
|- class="row8"<br />
! class="col0 centeralign" | double<br />
| class="col1 centeralign" | 8<br />
| class="col2" |<br />
See [http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.2.3 this]<br />
| class="col3" | Double-precision 64-bit IEEE 754 floating point<br />
|- class="row9"<br />
! class="col0 centeralign" | string<br />
| class="col1 centeralign" | ≥ 2 <br />≤ 240<br />
| class="col2" | N/A<br />
| class="col3" | UTF-8 String length prefixed with a VarInt<br />
|- <br />
! class="centeralign" | VarInt<br />
| class="centeralign" | Varies<br />
| [http://developers.google.com/protocol-buffers/docs/encoding#varints Protocol Buffer 32-bit Varint]<br />
|<br />
|-<br />
! VarLong<br />
| Varies<br />
| <br />
| Like VarInt but for java longs<br />
|- class="row9"<br />
! class="col0 centeralign" | metadata<br />
| class="col1 centeralign" | Varies<br />
| class="col2" | See [[Entities#Entity_Metadata_Format|this]]<br />
| class="Col3" | <br />
|- <br />
! class="centeralign" | Slot Data<br />
| class="centeralign" | Varies<br />
| See [[Slot_Data|slot data]]<br />
|<br />
|-<br />
! Position <br />
| 8<br />
| <br />
| See below<br />
|-<br />
! UUID<br />
| 16<br />
|<br />
| Encoded as two longs this.writeLong(uuid.getMostSignificantBits()); this.writeLong(uuid.getLeastSignificantBits());<br />
|}<br />
<br />
=== Position ===<br />
<br />
Encoded as followed:<br />
<br />
((x & 0x3FFFFFF) << 38) | ((y & 0xFFF) << 26) | (z & 0x3FFFFFF)<br />
<br />
<br />
And decoded as:<br />
<br />
long val; // Encoded value<br />
x = val >> 38;<br />
y = (val >> 26) & 0xFFF<br />
z = (val << 38) >> 38<br />
<br />
=== Fixed-point numbers ===<br />
<br />
Some fields may be stored as [https://en.wikipedia.org/wiki/Fixed-point_arithmetic fixed-point numbers], where a certain number of bits represents the signed integer part (number to the left of the decimal point) and the rest represents the fractional part (to the right). Floating points (float and double), in contrast, keep the number itself (mantissa) in one chunk, while the location of the decimal point (exponent) is stored beside it. <br />
<br />
Essentially, while fixed-point numbers have lower range than floating points, their fractional precision is greater for higher values. This makes them ideal for representing global coordinates of an entity in Minecraft, as it's more important to store the integer part accurately than position them more precisely within a single block (or meter). <br />
<br />
Coordinates are often represented as a 32-bit integer, where 5 of the least-significant bits are dedicated to the fractional part, and the rest store the integer part.<br />
<br />
Java lacks support for fractional integers directly, but you can represent them as integers. To convert from a double to this integer representation, use the following formulas:<br />
abs_int = (int)double * 32;<br />
And back again:<br />
<br />
double = (double)abs_int / 32;<br />
<br />
[[Category:Protocol Details]]<br />
[[Category:Minecraft Modern]]</div>Aragashttps://wiki.vg/index.php?title=Library_List&diff=6115Library List2014-09-22T19:24:43Z<p>Aragas: Updated MineLib.Network to 1.8. I think it's time to set all 1.7.x version to red</p>
<hr />
<div>{{ToolsNavbox}}<br />
This is a rather incomplete list of Minecraft related libraries currently in development.<br />
{| class="wikitable sortable" style="width: auto; text-align: center;"<br />
|-style="background:#eee"<br />
!Name<br />
!class="unsortable"|Description<br />
!Author(s)<br />
!Language<br />
!License<br />
!Last Version Supported<br />
|-<br />
! [https://github.com/SirCmpwn/Craft.Net Craft.Net]<br />
| .NET Minecraft client, server, and data manipulation library<br />
| Drew DeVault (SirCmpwn)<br />
| {{C sharp}}<br />
| {{MIT}}<br />
| {{yes|1.7.5}}<br />
|-<br />
! [https://github.com/superjoe30/node-minecraft-protocol node-minecraft-protocol]<br />
| npm install minecraft-protocol<br />
| [https://github.com/superjoe30 superjoe]<br />
| [http://nodejs.org/ node.js]<br />
| {{BSD}}<br />
| {{yes|1.7.6}}<br />
|-<br />
! [https://github.com/ags131/SharpMinecraftLibrary SharpMinecraftLibrary]<br />
|<br />
| ags131, electronicboy<br />
| {{C sharp}}<br />
| {{unknown}}<br />
| {{no|1.6.2 (Partial)}}<br />
|-<br />
! [http://github.com/Steveice10/MCProtocolLib MCProtocolLib]<br />
| Java implementation of the Minecraft protocol.<br />
| Steveice10<br />
| {{Java}}<br />
| {{MIT}}<br />
| {{yes|1.7.4-1.7.9}}<br />
|-<br />
! [https://github.com/dkkline/McClientLib McClientLib]<br />
| Python MineCraft client protocol.<br />
| [https://github.com/dkkline Jeppe Klitgaard (Dkkline)]<br />
| {{Python}}<br />
| {{MIT}}<br />
| {{no|1.5.2}}<br />
|-<br />
! [https://github.com/pdelvo/Pdelvo.Minecraft Pdelvos Protocol Implementation]<br />
| .NET client/server protocol library with support for several versions.<br />
| pdelvo<br />
| {{C sharp}}<br />
| {{MIT}}<br />
| {{no|1.5.2}}<br />
|-<br />
! [https://github.com/shoghicp/Minecraft-PHP-Client-2 Minecraft PHP Client 2]<br />
| PHP client and protocol library. With events, actions and API<br />
| [https://twitter.com/shoghicp shoghicp]<br />
| {{PHP}}<br />
| {{WTFPL}}<br />
| {{no|1.5.1}}<br />
|-<br />
! [https://github.com/deoxxa/libmcnet libmcnet]<br />
| Event based, zero-copy, portable Minecraft network protocol parser<br />
| deoxxa<br />
| {{C}}<br />
| {{BSD}}<br />
| {{no|1.4}}<br />
|-<br />
! [https://github.com/deoxxa/node-mcnet node-mcnet]<br />
| Node.JS bindings to [https://github.com/deoxxa/libmcnet libmcnet]<br />
| deoxxa<br />
| {{JavaScript}}, [http://nodejs.org/ node.js]<br />
| {{BSD}}<br />
| {{no|1.3.2}}<br />
|-<br />
! [https://github.com/Maincraft/MCPackets MCPackets]<br />
| Java Minecraft protocol library<br />
| main()<br />
| {{Java}}<br />
| {{unknown}}<br />
| {{no|1.2.5}}<br />
|-<br />
! [https://github.com/axus/libmc--c libmc--c]<br />
| World representation data structures and OpenGL drawing functions.<br />
| axus<br />
| {{C++}}, {{OpenGL}}<br />
| {{GPLv3}}<br />
| {{no|1.1}}<br />
|-<br />
! [https://github.com/mave/mcproxy mcproxy]<br />
| Minecraft Proxy (and bot) framework in C++<br />
| mave<br />
| {{C++}}<br />
| {{GPLv3}}<br />
| {{no|1.1}}<br />
|-<br />
! [https://github.com/fragmer/fNbt fNbt]<br />
| Reading, writing, and manipulating NBT files and streams, for .NET<br />
| [http://matvei.org/ Matvei Stefarov (fragmer)]<br />
| {{C sharp}}<br />
| {{BSD}}<br />
| n/a<br />
|-<br />
! [https://gist.github.com/Jckf/7872337 Yggdrasil.php]<br />
| Interfacing with Mojang's Yggdrasil authentication system.<br />
| [http://www.jckf.no/ Jim C K Flaten (Jckf)]<br />
| {{PHP}}<br />
| {{unknown}}<br />
| n/a<br />
|-<br />
! [https://github.com/umby24/libMC.NET libMC.Net]<br />
| .NET Minecraft interaction library<br />
| [http://umby.d3s.co/ umby24]<br />
| {{C sharp}}<br />
| {{MIT}}<br />
| {{yes|1.7.4}}<br />
|-<br />
! [https://github.com/Aragas/MineLib.Network MineLib.Network]<br />
| .NET Minecraft network client interaction library.<br />
| [https://github.com/Aragas Aragas (Aragasas)]<br />
| {{C sharp}}<br />
| {{MIT}}<br />
| {{yes|1.8}}<br />
|-<br />
! [https://github.com/Evil-Co/NBT-Lib NBT-Lib]<br />
| Allows reading, writing and modification of NBT files and streams.<br />
| [http://www.evil-co.org Evil-Co]<br />
| {{Java}}<br />
| {{Apache}}<br />
| n/a<br />
|-<br />
! [https://github.com/DarkStorm652/DarkBot DarkBot]<br />
| Minecraft client, automation (AI) platform, and modular protocol library<br />
| [https://github.com/DarkStorm652 DarkStorm]<br />
| {{Java}}<br />
| {{BSD}}<br />
| {{yes|1.5.2-1.7.9}}<br />
|-<br />
|}<br />
<br />
[[Category:Minecraft Modern]]</div>Aragashttps://wiki.vg/index.php?title=Talk:How_to_Write_a_Client&diff=5534Talk:How to Write a Client2014-04-24T18:37:11Z<p>Aragas: </p>
<hr />
<div>==== Respawning ====<br />
<br />
I have noticed that sending a 0x09 does nothing to make a client respawn.<br />
But a 0xCD with payload to 1 does.<br />
However, the client may stay invisible from an observer logged on the server... If the observer logs out then logs in, then it can see that the client has respawned.<br />
<br />
This is very weird and means that maybe more information needs to be sent to server. (of course, I sent 0x0D regularly while testing all that, and server gave me an 0x0D to spawn (which I respected) and 0x08 Health updates).<br />
<br />
--> I (may have) found out what happens : this is (in my sense) a bug from the notchian client : from the dying client, if you stop sending your position packets 0x0D after death and stop all sends except keep-alives, the "dead body" stays visible for a notchian observer. When the dying client respawns, the dead body disappears and never reappears... So the client is invisible from an observer (but blocks are refused in his hitbox by the server, so it seems to exist through the server).<br />
If you send 0x0D after being dead (filled up with last position before dying for instance), the body disappears.<br />
And if after that you send a 0xCD to respawn, everyhing is ok, the observer can see you.<br />
<br />
So if you send 0xCD (respawn) right after dying (without sending 0x0D between time of death and 0xCD), the notchian observer has no time to delete the dead body, and when the observer receives new 0x0D, it thinks it is from a dead body and make it disappear instead of making it respawning.<br />
<br />
So the right procedure is given in the article...<br />
Thanks for reading.<br />
<br />
== PlayerPositionAndLook apologize 1.7.x ==<br />
<br />
So... what about apologize handling? We still need to apologize?<br />
<br />
With the exact packet or what? Because, you know, Packet Id conflict<br />
<br />
Or use client side PlayerPositionAndLook? How to handle HeadY and FeetY? Tried to do something, but still can't move my player.<br />
<br />
Na, ya know, noob here, can't do anything with that. Life is pain. Help me %MINECRAFT_MASTER%, you're my only hope.<br />
<br />
--[[User:Hunterbuscus 3rd|Hunterbuscus 3rd]] ([[User talk:Hunterbuscus 3rd|talk]]) 20:20, 28 March 2014 (UTC)<br />
<br />
I've had the same problem here too. Whatever I did, the player wouldn't move.<br />
My code was messy, so I rewrote it. Then, it worked fine.<br />
Are you sending the settings packet (0x15) and the plugin message packet (0x17)?<br />
Seems like it might have help in my case.<br />
I'me no expert either (joined like two weeks ago)<br />
But I would recommend creating a proxy to monitor exactly how it is normally done<br />
<br />
hope this helps...<br />
<br />
--[[User:Aragas|Aragas]] ([[User talk:Aragas|talk]]) 22:25, 24 April 2014 (UTC)<br />
<br />
Slowpoke here. Dunno what helped me, but it works. I'm sending now settings packet, but i don't think that this was the problem.</div>Aragashttps://wiki.vg/index.php?title=Library_List&diff=5522Library List2014-04-20T15:01:03Z<p>Aragas: MineLib.Network now supporting 1.7.9</p>
<hr />
<div>{{ToolsNavbox}}<br />
This is a rather incomplete list of Minecraft related libraries currently in development.<br />
{| class="wikitable sortable" style="width: auto; text-align: center;"<br />
|-style="background:#eee"<br />
!Name<br />
!class="unsortable"|Description<br />
!Author(s)<br />
!Language<br />
!License<br />
!Last Version Supported<br />
|-<br />
! [https://github.com/SirCmpwn/Craft.Net Craft.Net]<br />
| .NET Minecraft client, server, and data manipulation library<br />
| Drew DeVault (SirCmpwn)<br />
| {{C sharp}}<br />
| {{MIT}}<br />
| {{snapshot|13w38c}}<br />
|-<br />
! [https://github.com/superjoe30/node-minecraft-protocol node-minecraft-protocol]<br />
| npm install minecraft-protocol<br />
| [https://github.com/superjoe30 superjoe]<br />
| [http://nodejs.org/ node.js]<br />
| {{BSD}}<br />
| {{yes|1.7.6}}<br />
|-<br />
! [https://github.com/ags131/SharpMinecraftLibrary SharpMinecraftLibrary]<br />
|<br />
| ags131, electronicboy<br />
| {{C sharp}}<br />
| {{unknown}}<br />
| {{no|1.6.2 (Partial)}}<br />
|-<br />
! [http://github.com/Steveice10/MCProtocolLib MCProtocolLib]<br />
| Java implementation of the Minecraft protocol.<br />
| Steveice10<br />
| {{Java}}<br />
| {{MIT}}<br />
| {{yes|1.7.4}}<br />
|-<br />
! [https://github.com/dkkline/McClientLib McClientLib]<br />
| Python MineCraft client protocol.<br />
| [https://github.com/dkkline Jeppe Klitgaard (Dkkline)]<br />
| {{Python}}<br />
| {{MIT}}<br />
| {{no|1.5.2}}<br />
|-<br />
! [https://github.com/pdelvo/Pdelvo.Minecraft Pdelvos Protocol Implementation]<br />
| .NET client/server protocol library with support for several versions.<br />
| pdelvo<br />
| {{C sharp}}<br />
| {{MIT}}<br />
| {{no|1.5.2}}<br />
|-<br />
! [https://github.com/shoghicp/Minecraft-PHP-Client-2 Minecraft PHP Client 2]<br />
| PHP client and protocol library. With events, actions and API<br />
| [https://twitter.com/shoghicp shoghicp]<br />
| {{PHP}}<br />
| {{WTFPL}}<br />
| {{no|1.5.1}}<br />
|-<br />
! [https://github.com/deoxxa/libmcnet libmcnet]<br />
| Event based, zero-copy, portable Minecraft network protocol parser<br />
| deoxxa<br />
| {{C}}<br />
| {{BSD}}<br />
| {{no|1.4}}<br />
|-<br />
! [https://github.com/deoxxa/node-mcnet node-mcnet]<br />
| Node.JS bindings to [https://github.com/deoxxa/libmcnet libmcnet]<br />
| deoxxa<br />
| {{JavaScript}}, [http://nodejs.org/ node.js]<br />
| {{BSD}}<br />
| {{no|1.3.2}}<br />
|-<br />
! [https://github.com/Maincraft/MCPackets MCPackets]<br />
| Java Minecraft protocol library<br />
| main()<br />
| {{Java}}<br />
| {{unknown}}<br />
| {{no|1.2.5}}<br />
|-<br />
! [https://github.com/axus/libmc--c libmc--c]<br />
| World representation data structures and OpenGL drawing functions.<br />
| axus<br />
| {{C++}}, {{OpenGL}}<br />
| {{GPLv3}}<br />
| {{no|1.1}}<br />
|-<br />
! [https://github.com/mave/mcproxy mcproxy]<br />
| Minecraft Proxy (and bot) framework in C++<br />
| mave<br />
| {{C++}}<br />
| {{GPLv3}}<br />
| {{no|1.1}}<br />
|-<br />
! [https://github.com/fragmer/fNbt fNbt]<br />
| Reading, writing, and manipulating NBT files and streams, for .NET<br />
| [http://matvei.org/ Matvei Stefarov (fragmer)]<br />
| {{C sharp}}<br />
| {{BSD}}<br />
| n/a<br />
|-<br />
! [https://gist.github.com/Jckf/7872337 Yggdrasil.php]<br />
| Interfacing with Mojang's Yggdrasil authentication system.<br />
| [http://www.jckf.no/ Jim C K Flaten (Jckf)]<br />
| {{PHP}}<br />
| {{unknown}}<br />
| n/a<br />
|-<br />
! [https://github.com/umby24/libMC.NET libMC.Net]<br />
| .NET Minecraft interaction library<br />
| [http://umby.d3s.co/ umby24]<br />
| {{C sharp}}<br />
| {{MIT}}<br />
| {{yes|1.7.4}}<br />
|-<br />
! [https://github.com/Aragas/MineLib.Network MineLib.Network]<br />
| .NET Minecraft network client interaction library.<br />
| [https://github.com/Aragas Aragas (Aragasas)]<br />
| {{C sharp}}<br />
| {{MIT}}<br />
| {{yes|1.7.9}}<br />
|-<br />
! [https://github.com/Evil-Co/NBT-Lib NBT-Lib]<br />
| Allows reading, writing and modification of NBT files and streams.<br />
| [http://www.evil-co.org Evil-Co]<br />
| {{Java}}<br />
| {{Apache}}<br />
| n/a<br />
|-<br />
|}<br />
<br />
[[Category:Minecraft Modern]]</div>Aragashttps://wiki.vg/index.php?title=Legacy_Mojang_Authentication&diff=5481Legacy Mojang Authentication2014-03-19T05:50:01Z<p>Aragas: /* Payload */</p>
<hr />
<div>Minecraft 1.6 introduced a new authentication scheme called Yggdrasil which completely replaces the [[Legacy_Authentication|previous authentication system]]. Mojang's other game, Scrolls, uses this method of authentication as well.<br />
<br />
== Request format ==<br />
<br />
All requests to Yggdrasil are made to the following server:<br />
<br />
https://authserver.mojang.com<br />
<br />
Further, they are expected to fulfill the following rules:<br />
<br />
* Are <code>POST</code> requests<br />
* Have the <code>Content-Type</code> header set to <code>application/json</code><br />
* Contain a [http://json.org JSON]-encoded dictionary as payload<br />
<br />
If a request was successful the server will respond with:<br />
<br />
* Status code <code>200</code><br />
* A [http://json.org JSON]-encoded dictionary according to the specifications below<br />
<br />
If however a request fails, the server will respond with:<br />
<br />
* An appropriate, non-200 [http://en.wikipedia.org/wiki/List_of_HTTP_status_codes HTTP status code]<br />
* A [http://json.org JSON]-encoded dictionary following this format:<br />
<syntaxhighlight lang="javascript"><br />
{<br />
"error": "Short description of the error",<br />
"errorMessage": "Longer description which can be shown to the user",<br />
"cause": "Cause of the error" // optional<br />
}<br />
</syntaxhighlight><br />
<br />
== Errors ==<br />
These are some of the errors that can be encountered:<br />
{| class="wikitable"<br />
|-<br />
! Error<br />
! Cause<br />
! Error message<br />
! Notes<br />
|-<br />
| <code>Method Not Allowed</code><br />
|<br />
| The method specified in the request is not allowed for the resource identified by the request URI<br />
| Something other than a POST request was received.<br />
|-<br />
| <code>Not Found</code><br />
|<br />
| The server has not found anything matching the request URI<br />
| Non-existing endpoint was called.<br />
|-<br />
| <code>ForbiddenOperationException</code><br />
| <code>UserMigratedException</code><br />
| Invalid credentials. Account migrated, use e-mail as username.<br />
| <br />
|-<br />
| <code>ForbiddenOperationException</code><br />
| <br />
| Invalid credentials. Invalid username or password.<br />
| <br />
|-<br />
| <code>ForbiddenOperationException</code><br />
| <br />
| Invalid token.<br />
| <code>accessToken</code> was invalid.<br />
|-<br />
| <code>IllegalArgumentException</code><br />
| <br />
| Access token already has a profile assigned.<br />
| Selecting profiles isn't implemented yet.<br />
|-<br />
| <code>Unsupported Media Type</code><br />
| <br />
| The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method<br />
| Data was not submitted as application/json<br />
|}<br />
<br />
== Authenticate ==<br />
<br />
Authenticates a user using his password.<br />
<br />
=== Endpoint ===<br />
/authenticate<br />
<br />
=== Payload ===<br />
<syntaxhighlight lang="javascript"><br />
{<br />
"agent": { // defaults to Minecraft<br />
"name": "Minecraft", // For Mojang's other game Scrolls, "Scrolls" should be used<br />
"version": 1 // This number might be increased<br />
// by the vanilla client in the future<br />
},<br />
"username": "mojang account name", // Can be an email address or player name for<br />
// unmigrated accounts<br />
"password": "mojang account password",<br />
"clientToken": "client identifier" // optional<br />
}<br />
</syntaxhighlight><br />
<br />
The <code>clientToken</code> should be a randomly generated identifier and must be identical for each request.<br />
In case it is omitted the server will generate a random token based on Java's [http://docs.oracle.com/javase/7/docs/api/java/util/UUID.html#toString() UUID.toString()] which should then be stored by the client. This will however also invalidate all previously acquired <code>accessToken</code>s for this user across all clients.<br />
<br />
=== Response ===<br />
<syntaxhighlight lang="javascript"><br />
{<br />
"accessToken": "random access token", // hexadecimal<br />
"clientToken": "client identifier", // identical to the one received<br />
"availableProfiles": [ // only present if the agent field was received<br />
{<br />
"id": "profile identifier", // hexadecimal<br />
"name": "player name",<br />
"legacy": "true or false" // In practice, this field only appears in the response if true. Default to false.<br />
}<br />
],<br />
"selectedProfile": { // only present if the agent field was received<br />
"id": "profile identifier",<br />
"name": "player name",<br />
"legacy": "true or false"<br />
}<br />
}<br />
</syntaxhighlight><br />
'''Note:''' If a user wishes to stay logged in on his computer you are strongly advised to store the received <code>accessToken</code> instead of the password itself.<br />
<br />
Currently each account will only have one single profile, multiple profiles per account are however planned in the future. If a user attempts to log into a valid Mojang account with no attached Minecraft license, the authentication will be successful, but the response will not contain a "selectedProfile" field, and the "availableProfiles" array will be empty.<br />
<br />
Some instances in the wild have been observed of Mojang returning a flat "null" for failed refresh attempts against legacy accounts. It's not clear what the actual error tied to the null response is and it is extremely rare, but implementations should be wary of null output from the response.<br />
<br />
== Refresh ==<br />
<br />
Refreshes a valid <code>accessToken</code>. It can be uses to keep a user logged in between gaming sessions and is preferred over storing the user's password in a file (see [[lastlogin]]). <br />
<br />
=== Endpoint ===<br />
/refresh<br />
<br />
=== Payload ===<br />
<syntaxhighlight lang="javascript"><br />
{<br />
"accessToken": "valid accessToken",<br />
"clientToken": "client identifier" // This needs to be identical to the one used<br />
// to obtain the accessToken in the first place<br />
"selectedProfile": { // optional; sending it will result in an error<br />
"id": "profile identifier", // hexadecimal<br />
"name": "player name"<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
Note: The provided <code>accessToken</code> gets invalidated.<br />
<br />
=== Response ===<br />
<syntaxhighlight lang="javascript"><br />
{<br />
"accessToken": "random access token", // hexadecimal<br />
"clientToken": "client identifier", // identical to the one received<br />
"selectedProfile": {<br />
"id": "profile identifier", // hexadecimal<br />
"name": "player name"<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
== Validate ==<br />
<br />
Checks if an <code>accessToken</code> is a valid session token with a currently-active session. Note: this method will not respond successfully to all currently-logged-in sessions, just the most recently-logged-in for each user. It is intended to be used by servers to validate that a user should be connecting (and reject users who have logged in elsewhere since starting Minecraft), NOT to auth that a particular session token is valid for authentication purposes. To authenticate a user by session token, use the refresh verb and catch resulting errors.<br />
<br />
=== Endpoint ===<br />
/validate<br />
<br />
=== Payload ===<br />
<syntaxhighlight lang="javascript"><br />
{<br />
"accessToken": "valid accessToken",<br />
}<br />
</syntaxhighlight><br />
<br />
=== Response ===<br />
Returns an empty payload if successful.<br />
<br />
== Signout ==<br />
<br />
Invalidates <code>accessToken</code>s using an account's username and password.<br />
<br />
=== Endpoint ===<br />
/signout<br />
<br />
=== Payload ===<br />
<syntaxhighlight lang="javascript"><br />
{<br />
"username": "mojang account name",<br />
"password": "mojang account password",<br />
}<br />
</syntaxhighlight><br />
<br />
=== Response ===<br />
Returns an empty payload if successful.<br />
<br />
== Invalidate ==<br />
<br />
Invalidates <code>accessToken</code>s using a client/access token pair.<br />
<br />
=== Endpoint ===<br />
/invalidate<br />
<br />
=== Payload ===<br />
<syntaxhighlight lang="javascript"><br />
{<br />
"accessToken": "valid accessToken",<br />
"clientToken": "client identifier" // This needs to be identical to the one used<br />
// to obtain the accessToken in the first place<br />
}<br />
</syntaxhighlight><br />
<br />
=== Response ===<br />
Returns an empty payload if successful.<br />
<br />
== Joining a Server ==<br />
<br />
See [[Protocol Encryption#Authentication|Protocol Encryption]]<br />
<br />
== Player Information ==<br />
<br />
https://sessionserver.mojang.com/session/minecraft/profile/<uuid><br />
<br />
This will return the player's username plus any additional information about them (e.g. skins). Example: https://sessionserver.mojang.com/session/minecraft/profile/4566e69fc90748ee8d71d7ba5aa00d20<br />
<br />
<br />
[[Category:Protocol Details]]<br />
[[Category:Minecraft Modern]]<br />
<br />
=== Response ===<br />
<syntaxhighlight lang="javascript"><br />
{<br />
"id":"profile identifier",<br />
"name":"player name",<br />
"properties":[ <br />
{<br />
"name":"dunno",<br />
"value":"base64 string",<br />
"signature":"not base64?"<br />
}<br />
]<br />
}<br />
</syntaxhighlight><br />
<br />
"value" base64 string decoded:<br />
<syntaxhighlight lang="javascript"><br />
{<br />
"timestamp":"some numbers",<br />
"profileId":"profile identifier",<br />
"profileName":"player name",<br />
"isPublic":"true or false",<br />
"textures":{<br />
"SKIN":{<br />
"url":"player skin URL"<br />
}<br />
}<br />
}<br />
</syntaxhighlight></div>Aragashttps://wiki.vg/index.php?title=Legacy_Mojang_Authentication&diff=5480Legacy Mojang Authentication2014-03-19T05:49:30Z<p>Aragas: /* Player Information */</p>
<hr />
<div>Minecraft 1.6 introduced a new authentication scheme called Yggdrasil which completely replaces the [[Legacy_Authentication|previous authentication system]]. Mojang's other game, Scrolls, uses this method of authentication as well.<br />
<br />
== Request format ==<br />
<br />
All requests to Yggdrasil are made to the following server:<br />
<br />
https://authserver.mojang.com<br />
<br />
Further, they are expected to fulfill the following rules:<br />
<br />
* Are <code>POST</code> requests<br />
* Have the <code>Content-Type</code> header set to <code>application/json</code><br />
* Contain a [http://json.org JSON]-encoded dictionary as payload<br />
<br />
If a request was successful the server will respond with:<br />
<br />
* Status code <code>200</code><br />
* A [http://json.org JSON]-encoded dictionary according to the specifications below<br />
<br />
If however a request fails, the server will respond with:<br />
<br />
* An appropriate, non-200 [http://en.wikipedia.org/wiki/List_of_HTTP_status_codes HTTP status code]<br />
* A [http://json.org JSON]-encoded dictionary following this format:<br />
<syntaxhighlight lang="javascript"><br />
{<br />
"error": "Short description of the error",<br />
"errorMessage": "Longer description which can be shown to the user",<br />
"cause": "Cause of the error" // optional<br />
}<br />
</syntaxhighlight><br />
<br />
== Errors ==<br />
These are some of the errors that can be encountered:<br />
{| class="wikitable"<br />
|-<br />
! Error<br />
! Cause<br />
! Error message<br />
! Notes<br />
|-<br />
| <code>Method Not Allowed</code><br />
|<br />
| The method specified in the request is not allowed for the resource identified by the request URI<br />
| Something other than a POST request was received.<br />
|-<br />
| <code>Not Found</code><br />
|<br />
| The server has not found anything matching the request URI<br />
| Non-existing endpoint was called.<br />
|-<br />
| <code>ForbiddenOperationException</code><br />
| <code>UserMigratedException</code><br />
| Invalid credentials. Account migrated, use e-mail as username.<br />
| <br />
|-<br />
| <code>ForbiddenOperationException</code><br />
| <br />
| Invalid credentials. Invalid username or password.<br />
| <br />
|-<br />
| <code>ForbiddenOperationException</code><br />
| <br />
| Invalid token.<br />
| <code>accessToken</code> was invalid.<br />
|-<br />
| <code>IllegalArgumentException</code><br />
| <br />
| Access token already has a profile assigned.<br />
| Selecting profiles isn't implemented yet.<br />
|-<br />
| <code>Unsupported Media Type</code><br />
| <br />
| The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method<br />
| Data was not submitted as application/json<br />
|}<br />
<br />
== Authenticate ==<br />
<br />
Authenticates a user using his password.<br />
<br />
=== Endpoint ===<br />
/authenticate<br />
<br />
=== Payload ===<br />
<syntaxhighlight lang="javascript"><br />
{<br />
"agent": { // defaults to Minecraft<br />
"name": "Minecraft", // For Mojang's other game Scrolls, "Scrolls" should be used<br />
"version": 1 // This number might be increased<br />
// by the vanilla client in the future<br />
},<br />
"username": "mojang account name", // Can be an email address or player name for<br />
// unmigrated accounts<br />
"password": "mojang account password",<br />
"clientToken": "client identifier" // optional<br />
}<br />
</syntaxhighlight><br />
<br />
The <code>clientToken</code> should be a randomly generated identifier and must be identical for each request.<br />
In case it is omitted the server will generate a random token based on Java's [http://docs.oracle.com/javase/7/docs/api/java/util/UUID.html#toString() UUID.toString()] which should then be stored by the client. This will however also invalidate all previously acquired <code>accessToken</code>s for this user across all clients.<br />
<br />
=== Response ===<br />
<syntaxhighlight lang="javascript"><br />
{<br />
"accessToken": "random access token", // hexadecimal<br />
"clientToken": "client identifier", // identical to the one received<br />
"availableProfiles": [ // only present if the agent field was received<br />
{<br />
"id": "profile identifier", // hexadecimal<br />
"name": "player name",<br />
"legacy": "true or false" // In practice, this field only appears in the response if true. Default to false.<br />
}<br />
],<br />
"selectedProfile": { // only present if the agent field was received<br />
"id": "profile identifier",<br />
"name": "player name",<br />
"legacy": "true or false"<br />
}<br />
}<br />
</syntaxhighlight><br />
'''Note:''' If a user wishes to stay logged in on his computer you are strongly advised to store the received <code>accessToken</code> instead of the password itself.<br />
<br />
Currently each account will only have one single profile, multiple profiles per account are however planned in the future. If a user attempts to log into a valid Mojang account with no attached Minecraft license, the authentication will be successful, but the response will not contain a "selectedProfile" field, and the "availableProfiles" array will be empty.<br />
<br />
Some instances in the wild have been observed of Mojang returning a flat "null" for failed refresh attempts against legacy accounts. It's not clear what the actual error tied to the null response is and it is extremely rare, but implementations should be wary of null output from the response.<br />
<br />
== Refresh ==<br />
<br />
Refreshes a valid <code>accessToken</code>. It can be uses to keep a user logged in between gaming sessions and is preferred over storing the user's password in a file (see [[lastlogin]]). <br />
<br />
=== Endpoint ===<br />
/refresh<br />
<br />
=== Payload ===<br />
<syntaxhighlight lang="javascript"><br />
{<br />
"accessToken": "valid accessToken",<br />
"clientToken": "client identifier" // This needs to be identical to the one used<br />
// to obtain the accessToken in the first place<br />
"selectedProfile": { // optional; sending it will result in an error<br />
"id": "profile identifier", // hexadecimal<br />
"name": "player name"<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
Note: The provided <code>accessToken</code> gets invalidated.<br />
<br />
=== Response ===<br />
<syntaxhighlight lang="javascript"><br />
{<br />
"accessToken": "random access token", // hexadecimal<br />
"clientToken": "client identifier", // identical to the one received<br />
"selectedProfile": {<br />
"id": "profile identifier", // hexadecimal<br />
"name": "player name"<br />
}<br />
}<br />
</syntaxhighlight><br />
<br />
== Validate ==<br />
<br />
Checks if an <code>accessToken</code> is a valid session token with a currently-active session. Note: this method will not respond successfully to all currently-logged-in sessions, just the most recently-logged-in for each user. It is intended to be used by servers to validate that a user should be connecting (and reject users who have logged in elsewhere since starting Minecraft), NOT to auth that a particular session token is valid for authentication purposes. To authenticate a user by session token, use the refresh verb and catch resulting errors.<br />
<br />
=== Endpoint ===<br />
/validate<br />
<br />
=== Payload ===<br />
<syntaxhighlight lang="javascript"><br />
{<br />
"accessToken": "valid accessToken",<br />
}<br />
</syntaxhighlight><br />
<br />
=== Response ===<br />
Returns an empty payload if successful.<br />
<br />
== Signout ==<br />
<br />
Invalidates <code>accessToken</code>s using an account's username and password.<br />
<br />
=== Endpoint ===<br />
/signout<br />
<br />
=== Payload ===<br />
<syntaxhighlight lang="javascript"><br />
{<br />
"username": "mojang account name",<br />
"password": "mojang account password",<br />
}<br />
</syntaxhighlight><br />
<br />
=== Response ===<br />
Returns an empty payload if successful.<br />
<br />
== Invalidate ==<br />
<br />
Invalidates <code>accessToken</code>s using a client/access token pair.<br />
<br />
=== Endpoint ===<br />
/invalidate<br />
<br />
=== Payload ===<br />
<syntaxhighlight lang="javascript"><br />
{<br />
"accessToken": "valid accessToken",<br />
"clientToken": "client identifier" // This needs to be identical to the one used<br />
// to obtain the accessToken in the first place<br />
}<br />
</syntaxhighlight><br />
<br />
=== Response ===<br />
Returns an empty payload if successful.<br />
<br />
== Joining a Server ==<br />
<br />
See [[Protocol Encryption#Authentication|Protocol Encryption]]<br />
<br />
== Player Information ==<br />
<br />
https://sessionserver.mojang.com/session/minecraft/profile/<uuid><br />
<br />
This will return the player's username plus any additional information about them (e.g. skins). Example: https://sessionserver.mojang.com/session/minecraft/profile/4566e69fc90748ee8d71d7ba5aa00d20<br />
<br />
<br />
[[Category:Protocol Details]]<br />
[[Category:Minecraft Modern]]<br />
<br />
=== Payload ===<br />
<syntaxhighlight lang="javascript"><br />
{<br />
"id":"profile identifier",<br />
"name":"player name",<br />
"properties":[ <br />
{<br />
"name":"dunno",<br />
"value":"base64 string",<br />
"signature":"not base64?"<br />
}<br />
]<br />
}<br />
</syntaxhighlight><br />
<br />
"value" base64 string decoded:<br />
<syntaxhighlight lang="javascript"><br />
{<br />
"timestamp":"some numbers",<br />
"profileId":"profile identifier",<br />
"profileName":"player name",<br />
"isPublic":"true or false",<br />
"textures":{<br />
"SKIN":{<br />
"url":"player skin URL"<br />
}<br />
}<br />
}<br />
</syntaxhighlight></div>Aragashttps://wiki.vg/index.php?title=Talk:How_to_Write_a_Client&diff=5479Talk:How to Write a Client2014-03-17T17:44:00Z<p>Aragas: Oops, doubled</p>
<hr />
<div>==== Respawning ====<br />
<br />
I have noticed that sending a 0x09 does nothing to make a client respawn.<br />
But a 0xCD with payload to 1 does.<br />
However, the client may stay invisible from an observer logged on the server... If the observer logs out then logs in, then it can see that the client has respawned.<br />
<br />
This is very weird and means that maybe more information needs to be sent to server. (of course, I sent 0x0D regularly while testing all that, and server gave me an 0x0D to spawn (which I respected) and 0x08 Health updates).<br />
<br />
--> I (may have) found out what happens : this is (in my sense) a bug from the notchian client : from the dying client, if you stop sending your position packets 0x0D after death and stop all sends except keep-alives, the "dead body" stays visible for a notchian observer. When the dying client respawns, the dead body disappears and never reappears... So the client is invisible from an observer (but blocks are refused in his hitbox by the server, so it seems to exist through the server).<br />
If you send 0x0D after being dead (filled up with last position before dying for instance), the body disappears.<br />
And if after that you send a 0xCD to respawn, everyhing is ok, the observer can see you.<br />
<br />
So if you send 0xCD (respawn) right after dying (without sending 0x0D between time of death and 0xCD), the notchian observer has no time to delete the dead body, and when the observer receives new 0x0D, it thinks it is from a dead body and make it disappear instead of making it respawning.<br />
<br />
So the right procedure is given in the article...<br />
Thanks for reading.<br />
<br />
== PlayerPositionAndLook apologize 1.7.x ==<br />
<br />
So... what about apologize handling? We still need to apologize?<br />
<br />
With the exact packet or what? Because, you know, Packet Id conflict<br />
<br />
Or use client side PlayerPositionAndLook? How to handle HeadY and FeetY? Tried to do something, but still can't move my player.<br />
<br />
Na, ya know, noob here, can't do anything with that. Life is pain. Help me %MINECRAFT_MASTER%, you're my only hope.</div>Aragashttps://wiki.vg/index.php?title=Talk:How_to_Write_a_Client&diff=5478Talk:How to Write a Client2014-03-17T17:43:14Z<p>Aragas: /* PlayerPositionAndLook apologize 1.7.x */ new section</p>
<hr />
<div>==== Respawning ====<br />
<br />
I have noticed that sending a 0x09 does nothing to make a client respawn.<br />
But a 0xCD with payload to 1 does.<br />
However, the client may stay invisible from an observer logged on the server... If the observer logs out then logs in, then it can see that the client has respawned.<br />
<br />
This is very weird and means that maybe more information needs to be sent to server. (of course, I sent 0x0D regularly while testing all that, and server gave me an 0x0D to spawn (which I respected) and 0x08 Health updates).<br />
<br />
--> I (may have) found out what happens : this is (in my sense) a bug from the notchian client : from the dying client, if you stop sending your position packets 0x0D after death and stop all sends except keep-alives, the "dead body" stays visible for a notchian observer. When the dying client respawns, the dead body disappears and never reappears... So the client is invisible from an observer (but blocks are refused in his hitbox by the server, so it seems to exist through the server).<br />
If you send 0x0D after being dead (filled up with last position before dying for instance), the body disappears.<br />
And if after that you send a 0xCD to respawn, everyhing is ok, the observer can see you.<br />
<br />
So if you send 0xCD (respawn) right after dying (without sending 0x0D between time of death and 0xCD), the notchian observer has no time to delete the dead body, and when the observer receives new 0x0D, it thinks it is from a dead body and make it disappear instead of making it respawning.<br />
<br />
So the right procedure is given in the article...<br />
Thanks for reading.<br />
<br />
== PlayerPositionAndLook apologize 1.7.x ==<br />
<br />
So... what about apologize handling? We still need to apologize?<br />
<br />
With the exact packet or what? Because, you know, Packet Id conflict<br />
<br />
Or use client side PlayerPositionAndLook? How to handle HeadY and FeetY? Tried to do something, but still can't move my player.<br />
<br />
Na, ya know, noob here, can't do anything with that. Life is pain. Help me %MINECRAFT_MASTER%, you're my only hope.<br />
<br />
== PlayerPositionAndLook apologize 1.7.x ==<br />
<br />
So... what about apologize handling? We still need to apologize?<br />
<br />
With the exact packet or what? Because, you know, Packet Id conflict<br />
<br />
Or use client side PlayerPositionAndLook? How to handle HeadY and FeetY? Tried to do something, but still can't move my player.<br />
<br />
Na, ya know, noob here, can't do anything with that. Life is pain. Help me %MINECRAFT_MASTER%, you're my only hope.</div>Aragashttps://wiki.vg/index.php?title=Talk:How_to_Write_a_Client&diff=5477Talk:How to Write a Client2014-03-17T17:43:07Z<p>Aragas: /* PlayerPositionAndLook apologize 1.7.x */ new section</p>
<hr />
<div>==== Respawning ====<br />
<br />
I have noticed that sending a 0x09 does nothing to make a client respawn.<br />
But a 0xCD with payload to 1 does.<br />
However, the client may stay invisible from an observer logged on the server... If the observer logs out then logs in, then it can see that the client has respawned.<br />
<br />
This is very weird and means that maybe more information needs to be sent to server. (of course, I sent 0x0D regularly while testing all that, and server gave me an 0x0D to spawn (which I respected) and 0x08 Health updates).<br />
<br />
--> I (may have) found out what happens : this is (in my sense) a bug from the notchian client : from the dying client, if you stop sending your position packets 0x0D after death and stop all sends except keep-alives, the "dead body" stays visible for a notchian observer. When the dying client respawns, the dead body disappears and never reappears... So the client is invisible from an observer (but blocks are refused in his hitbox by the server, so it seems to exist through the server).<br />
If you send 0x0D after being dead (filled up with last position before dying for instance), the body disappears.<br />
And if after that you send a 0xCD to respawn, everyhing is ok, the observer can see you.<br />
<br />
So if you send 0xCD (respawn) right after dying (without sending 0x0D between time of death and 0xCD), the notchian observer has no time to delete the dead body, and when the observer receives new 0x0D, it thinks it is from a dead body and make it disappear instead of making it respawning.<br />
<br />
So the right procedure is given in the article...<br />
Thanks for reading.<br />
<br />
== PlayerPositionAndLook apologize 1.7.x ==<br />
<br />
So... what about apologize handling? We still need to apologize?<br />
<br />
With the exact packet or what? Because, you know, Packet Id conflict<br />
<br />
Or use client side PlayerPositionAndLook? How to handle HeadY and FeetY? Tried to do something, but still can't move my player.<br />
<br />
Na, ya know, noob here, can't do anything with that. Life is pain. Help me %MINECRAFT_MASTER%, you're my only hope.</div>Aragashttps://wiki.vg/index.php?title=Library_List&diff=5474Library List2014-03-14T17:49:52Z<p>Aragas: Adding mah library if ya don't mind</p>
<hr />
<div>{{ToolsNavbox}}<br />
This is a rather incomplete list of Minecraft related libraries currently in development.<br />
{| class="wikitable sortable" style="width: auto; text-align: center;"<br />
|-style="background:#eee"<br />
!Name<br />
!class="unsortable"|Description<br />
!Author(s)<br />
!Language<br />
!License<br />
!Last Version Supported<br />
|-<br />
! [https://github.com/SirCmpwn/Craft.Net Craft.Net]<br />
| .NET Minecraft client, server, and data manipulation library<br />
| Drew DeVault (SirCmpwn)<br />
| {{C sharp}}<br />
| {{MIT}}<br />
| {{snapshot|13w38c}}<br />
|-<br />
! [https://github.com/superjoe30/node-minecraft-protocol node-minecraft-protocol]<br />
| npm install minecraft-protocol<br />
| [https://github.com/superjoe30 superjoe]<br />
| [http://nodejs.org/ node.js]<br />
| {{BSD}}<br />
| {{no|1.6.4}}<br />
|-<br />
! [https://github.com/ags131/SharpMinecraftLibrary SharpMinecraftLibrary]<br />
|<br />
| ags131, electronicboy<br />
| {{C sharp}}<br />
| {{unknown}}<br />
| {{no|1.6.2 (Partial)}}<br />
|-<br />
! [http://github.com/Steveice10/MCProtocolLib MCProtocolLib]<br />
| Java implementation of the Minecraft protocol.<br />
| Steveice10<br />
| {{Java}}<br />
| {{MIT}}<br />
| {{yes|1.7.4}}<br />
|-<br />
! [https://github.com/dkkline/McClientLib McClientLib]<br />
| Python MineCraft client protocol.<br />
| [https://github.com/dkkline Jeppe Klitgaard (Dkkline)]<br />
| {{Python}}<br />
| {{MIT}}<br />
| {{no|1.5.2}}<br />
|-<br />
! [https://github.com/pdelvo/Pdelvo.Minecraft Pdelvos Protocol Implementation]<br />
| .NET client/server protocol library with support for several versions.<br />
| pdelvo<br />
| {{C sharp}}<br />
| {{MIT}}<br />
| {{no|1.5.2}}<br />
|-<br />
! [https://github.com/shoghicp/Minecraft-PHP-Client-2 Minecraft PHP Client 2]<br />
| PHP client and protocol library. With events, actions and API<br />
| [https://twitter.com/shoghicp shoghicp]<br />
| {{PHP}}<br />
| {{WTFPL}}<br />
| {{no|1.5.1}}<br />
|-<br />
! [https://github.com/deoxxa/libmcnet libmcnet]<br />
| Event based, zero-copy, portable Minecraft network protocol parser<br />
| deoxxa<br />
| {{C}}<br />
| {{BSD}}<br />
| {{no|1.4}}<br />
|-<br />
! [https://github.com/deoxxa/node-mcnet node-mcnet]<br />
| Node.JS bindings to [https://github.com/deoxxa/libmcnet libmcnet]<br />
| deoxxa<br />
| {{JavaScript}}, [http://nodejs.org/ node.js]<br />
| {{BSD}}<br />
| {{no|1.3.2}}<br />
|-<br />
! [https://github.com/Maincraft/MCPackets MCPackets]<br />
| Java Minecraft protocol library<br />
| main()<br />
| {{Java}}<br />
| {{unknown}}<br />
| {{no|1.2.5}}<br />
|-<br />
! [https://github.com/axus/libmc--c libmc--c]<br />
| World representation data structures and OpenGL drawing functions.<br />
| axus<br />
| {{C++}}, {{OpenGL}}<br />
| {{GPLv3}}<br />
| {{no|1.1}}<br />
|-<br />
! [https://github.com/mave/mcproxy mcproxy]<br />
| Minecraft Proxy (and bot) framework in C++<br />
| mave<br />
| {{C++}}<br />
| {{GPLv3}}<br />
| {{no|1.1}}<br />
|-<br />
! [https://github.com/fragmer/fNbt fNbt]<br />
| Reading, writing, and manipulating NBT files and streams, for .NET<br />
| [http://matvei.org/ Matvei Stefarov (fragmer)]<br />
| {{C sharp}}<br />
| {{BSD}}<br />
| n/a<br />
|-<br />
! [https://gist.github.com/Jckf/7872337 Yggdrasil.php]<br />
| Interfacing with Mojang's Yggdrasil authentication system.<br />
| [http://www.jckf.no/ Jim C K Flaten (Jckf)]<br />
| {{PHP}}<br />
| {{unknown}}<br />
| n/a<br />
|-<br />
! [https://github.com/umby24/libMC.NET libMC.Net]<br />
| .NET Minecraft interaction library<br />
| [http://umby.d3s.co/ umby24]<br />
| {{C sharp}}<br />
| {{MIT}}<br />
| {{yes|1.7.4}}<br />
|-<br />
! [https://github.com/Aragas/MineLib.Network MineLib.Network]<br />
| .NET Minecraft network client interaction library.<br />
| [https://github.com/Aragas Aragas (Aragasas)]<br />
| {{C sharp}}<br />
| {{MIT}}<br />
| {{yes|1.7.4}}<br />
|-<br />
|}<br />
<br />
[[Category:Minecraft Modern]]</div>Aragashttps://wiki.vg/index.php?title=Protocol&diff=5441Protocol2014-02-24T14:08:00Z<p>Aragas: Not correct info. We get X and Z coords from Vanilla/Bukkit servers as Short, not Int</p>
<hr />
<div>This page presents a dissection of the current stable [http://minecraft.net/game/ Minecraft] protocol. The current pre-release protocol is documented [[Pre-release_protocol|elsewhere]]. The protocol for Pocket Minecraft is substantially different, and is documented at [[Pocket Minecraft Protocol]].<br />
<br />
If you're having trouble, check out the [[Protocol_FAQ|FAQ]] or ask for help in the IRC channel ([irc://irc.freenode.net/mcdevs #mcdevs on irc.freenode.net]).<br />
<br />
'''Note:''' While you may use the contents of this page without restriction to create servers, clients, bots, etc… you still need to provide attribution to #mcdevs if you copy any of the contents of this page for publication elsewhere.<br />
<br />
{{Warning|As of 1.7 strings are now UTF-8 (prefixed with a VarInt giving the string's length in bytes) instead of UTF-16.}}<br />
<br />
{| class="wikitable"<br />
|-<br />
! Term<br />
! Definition<br />
|-<br />
| Player<br />
| When used in the singular, Player always refers to the client connected to the server<br />
|-<br />
| Entity<br />
| Entity refers to any item, player, mob, minecart or boat in the world. This definition is subject to change as Notch extends the protocol<br />
|-<br />
| EID<br />
| An EID - or Entity ID - is a unique 4-byte integer used to identify a specific entity<br />
|-<br />
| XYZ<br />
| In this document, the axis names are the same as those used by Notch. Y points upwards, X points South, and Z points West.<br />
|-<br />
!colspan="2"|See also: [[Data types]], [[Units of Measurement]]<br />
|}<br />
<br />
The changes between versions may be viewed at [[Protocol History]]<br />
<br />
== Packets ==<br />
=== Protocol Version ===<br />
1.7.2 - 4<br />
<br />
== Packet format ==<br />
<br />
{| class="wikitable"<br />
! Field Name !! Field Type !! Notes<br />
|-<br />
| Length || VarInt || Length of packet data + length of the packet ID<br />
|-<br />
| Packet ID || VarInt || <br />
|-<br />
| Data || || <br />
|}<br />
<br />
== Handshaking ==<br />
<br />
=== Serverbound ===<br />
<br />
==== Handshake ====<br />
This causes the server to switch into the target state.<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=4 | 0x00<br />
| Protocol Version || VarInt || (4 as of 1.7.2)<br />
|-<br />
| Server Address (hostname or IP) || String || localhost<br />
|- <br />
| Server Port || Unsigned Short|| 25565<br />
|-<br />
| Next state || VarInt || 1 for status, 2 for login<br />
|}<br />
<br />
== Play ==<br />
<br />
=== Clientbound ===<br />
<br />
==== Keep Alive ====<br />
<br />
The server will frequently send out a keep-alive, each containing a random ID. The client must respond with the same packet.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=1 | 0x00<br />
| Keep Alive ID || Int ||<br />
|}<br />
<br />
<br />
==== Join Game ====<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=6 | 0x01<br />
| Entity ID || Int || The player's Entity ID<br />
|-<br />
| Gamemode || Unsigned Byte || 0: survival, 1: creative, 2: adventure. Bit 3 (0x8) is the hardcore flag<br />
|-<br />
| Dimension || Byte || -1: nether, 0: overworld, 1: end<br />
|-<br />
| Difficulty || Unsigned Byte || 0 thru 3 for Peaceful, Easy, Normal, Hard<br />
|-<br />
| Max Players || Unsigned Byte || Used by the client to draw the player list<br />
|-<br />
| Level Type || String || default, flat, largeBiomes, amplified, default_1_1<br />
|}<br />
{{Warning|If the Dimension isn't valid then the client will crash}}<br />
<br />
==== Chat Message ====<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=1 | 0x02<br />
| JSON Data || String || https://gist.github.com/thinkofdeath/e882ce057ed83bac0a1c , Limited to 32767 bytes<br />
|}<br />
{{Warning|Malformed JSON will disconnect the client}}<br />
<br />
==== Time Update ====<br />
<br />
Time is based on ticks, where 20 ticks happen every second. There are 24000 ticks in a day, making Minecraft days exactly 20 minutes long.<br />
<br />
The time of day is based on the timestamp modulo 24000. 0 is sunrise, 6000 is noon, 12000 is sunset, and 18000 is midnight.<br />
<br />
The default SMP server increments the time by <code>20</code> every second.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=2 | 0x03<br />
| Age of the world || Long || In ticks; not changed by server commands<br />
|-<br />
| Time of day || Long || The world (or region) time, in ticks. If negative the sun will stop moving at the Math.abs of the time<br />
|}<br />
<br />
==== Entity Equipment ====<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=3 | 0x04<br />
| EntityID || Int || Entity's ID<br />
|-<br />
| Slot || Short || Equipment slot: 0=held, 1-4=armor slot (1 - boots, 2 - leggings, 3 - chestplate, 4 - helmet)<br />
|-<br />
| Item || [[Slot_Data|Slot]] || Item in slot format<br />
|}<br />
<br />
==== Spawn Position ====<br />
<br />
Sent by the server after login to specify the coordinates of the spawn point (the point at which players spawn at, and which the compass points to). It can be sent at any time to update the point compasses point at.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=3 | 0x05<br />
| X || Int || Spawn X in block coordinates<br />
|-<br />
| Y || Int || Spawn Y in block coordinates<br />
|-<br />
| Z || Int || Spawn Z in block coordinates<br />
|}<br />
<br />
==== Update Health ====<br />
<br />
Sent by the server to update/set the health of the player it is sent to.<br />
<br />
Food saturation acts as a food "overcharge". Food values will not decrease while the saturation is over zero. Players logging in automatically get a saturation of 5.0. Eating food increases the saturation as well as the food bar.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=3 | 0x06<br />
| Health || Float || 0 or less = dead, 20 = full HP<br />
|-<br />
| Food || Short || 0 - 20<br />
|- <br />
| Food Saturation || Float || Seems to vary from 0.0 to 5.0 in integer increments<br />
|}<br />
<br />
==== Respawn ====<br />
<br />
To change the player's dimension (overworld/nether/end), send them a respawn packet with the appropriate dimension, followed by prechunks/chunks for the new dimension, and finally a position and look packet. You do not need to unload chunks, the client will do it automatically.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=4 | 0x07<br />
| Dimension || Int || -1: The Nether, 0: The Overworld, 1: The End<br />
|-<br />
| Difficulty || Unsigned Byte || 0 thru 3 for Peaceful, Easy, Normal, Hard.<br />
|-<br />
| Gamemode || Unsigned Byte || 0: survival, 1: creative, 2: adventure. The hardcore flag is not included<br />
|-<br />
| Level Type || String || Same as [[Protocol#Join_Game|Join Game]]<br />
|}<br />
{{Warning|If the Dimension isn't valid then the client will crash}}<br />
<br />
{{Warning|Avoid changing player's dimension to same dimension they were already in, weird bugs can occur i.e. such player will be unable to attack other players in new world (fixes after their death and respawn)}}<br />
<br />
==== Player Position And Look ====<br />
<br />
Updates the players position on the server. <br />
If the distance between the last known position of the player on the server and the new position set by this packet is greater than 100 units will result in the client being kicked for "You moved too quickly :( (Hacking?)"<br />
Also if the fixed-point number of X or Z is set greater than <code>3.2E7D</code> the client will be kicked for "Illegal position"<br />
<br />
Yaw is measured in degrees, and does not follow classical trigonometry rules. The unit circle of yaw on the XZ-plane starts at (0, 1) and turns counterclockwise, with 90 at (-1, 0), 180 at (0,-1) and 270 at (1, 0). Additionally, yaw is not clamped to between 0 and 360 degrees; any number is valid, including negative numbers and numbers greater than 360.<br />
<br />
Pitch is measured in degrees, where 0 is looking straight ahead, -90 is looking straight up, and 90 is looking straight down.<br />
<br />
The yaw of player (in degrees), standing at point (x0,z0) and looking towards point (x,z) one can be calculated with:<br />
l = x-x0<br />
w = z-z0<br />
c = sqrt( l*l + w*w )<br />
alpha1 = -arcsin(l/c)/PI*180<br />
alpha2 = arccos(w/c)/PI*180<br />
if alpha2 > 90 then<br />
yaw = 180 - alpha1<br />
else<br />
yaw = alpha1<br />
<br />
You can get a unit vector from a given yaw/pitch via:<br />
x = -cos(pitch) * sin(yaw)<br />
y = -sin(pitch)<br />
z = cos(pitch) * cos(yaw)<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=6| 0x08<br />
| X || Double || Absolute position<br />
|-<br />
| Y || Double || Absolute position<br />
|-<br />
| Z || Double || Absolute position<br />
|-<br />
| Yaw || Float || Absolute rotation on the X Axis, in degrees<br />
|-<br />
| Pitch || Float || Absolute rotation on the Y Axis, in degrees<br />
|-<br />
| On Ground || Bool || True if the client is on the ground, False otherwise<br />
|}<br />
<br />
==== Held Item Change ====<br />
<br />
Sent to change the player's slot selection<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=1 | 0x09<br />
| Slot || Byte || The slot which the player has selected (0-8)<br />
|}<br />
<br />
==== Use Bed ====<br />
<br />
This packet tells that a player goes to bed.<br />
<br />
The client with the matching Entity ID will go into bed mode.<br />
<br />
This Packet is sent to all nearby players including the one sent to bed.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=5 | 0x0A<br />
| Entity ID || Int || Player ID<br />
|-<br />
| X || Int || Bed headboard X as block coordinate<br />
|-<br />
| Y || Unsigned Byte || Bed headboard Y as block coordinate<br />
|-<br />
| Z || Int || Bed headboard Z as block coordinate<br />
|}<br />
<br />
==== Animation ====<br />
<br />
Sent whenever an entity should change animation.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=2 | 0x0B<br />
| Entity ID || VarInt || Player ID<br />
|-<br />
| Animation || Unsigned Byte || Animation ID<br />
|}<br />
<br />
Animation can be one of the following values:<br />
<br />
{| class="wikitable"<br />
! ID !! Animation<br />
|-<br />
| 0 || Swing arm<br />
|-<br />
| 1 || Damage animation<br />
|-<br />
| 2 || Leave bed<br />
|-<br />
| 3 || Eat food<br />
|-<br />
| 4 || Critical effect<br />
|-<br />
| 5 || Magic critical effect<br />
|-<br />
| 102 || (unknown)<br />
|-<br />
| 104 || Crouch<br />
|-<br />
| 105 || Uncrouch<br />
|}<br />
<br />
==== Spawn Player ====<br />
<br />
This packet is sent by the server when a player comes into visible range, '''not''' when a player joins.<br />
<br />
Servers can, however, safely spawn player entities for players not in visible range. The client appears to handle it correctly.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=10 | 0x0C<br />
| Entity ID || VarInt || Player's Entity ID<br />
|-<br />
| Player UUID || String || Player's UUID<br />
|-<br />
| Player Name || String || Player's Name<br />
|-<br />
| X || Int || Player X as a [[Data_Types#Fixed-point_numbers|Fixed-Point number]] <br />
|-<br />
| Y || Int || Player X as a [[Data_Types#Fixed-point_numbers|Fixed-Point number]] <br />
|-<br />
| Z || Int || Player X as a [[Data_Types#Fixed-point_numbers|Fixed-Point number]] <br />
|-<br />
| Yaw || Byte || Player rotation as a packed byte<br />
|-<br />
| Pitch || Byte || Player rotation as a packet byte<br />
|-<br />
| Current Item || Short || The item the player is currently holding. Note that this should be 0 for "no item", unlike -1 used in other packets. A negative value crashes clients.<br />
|-<br />
| Metadata || [[Entities#Entity_Metadata_Format|Metadata]] || The client will crash if no metadata is sent<br />
|}<br />
{{Warning|The client will crash if no metadata is sent}}<br />
{{Warning|The client will disconnect if both UUID and Name are empty}}<br />
<br />
==== Collect Item ====<br />
<br />
Sent by the server when someone picks up an item lying on the ground - its sole purpose appears to be the animation of the item flying towards you. It doesn't destroy the entity in the client memory, and it doesn't add it to your inventory. The server only checks for items to be picked up after each Player Position and [Player Position & Look packet sent by the client.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=2 | 0x0D<br />
| Collected Entity ID || Int ||<br />
|- <br />
| Collector Entity ID || Int ||<br />
|}<br />
<br />
==== Spawn Object ====<br />
<br />
Sent by the server when an Object/Vehicle is created.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=8| 0x0E<br />
| Entity ID || VarInt || Entity ID of the object<br />
|-<br />
| Type || Byte || The type of object (See [[Entities#Objects|Objects]])<br />
|-<br />
| X || Int || X position as a [[Data_Types#Fixed-point_numbers|Fixed-Point number]] <br />
|-<br />
| Y || Int || Y position as a [[Data_Types#Fixed-point_numbers|Fixed-Point number]] <br />
|-<br />
| Z || Int || Z position as a [[Data_Types#Fixed-point_numbers|Fixed-Point number]] <br />
|-<br />
| Pitch || Byte || The pitch in steps of 2p/256<br />
|-<br />
| Yaw || Byte || The yaw in steps of 2p/256<br />
|-<br />
| Data || [[Object_Data|Object Data]] ||<br />
|}<br />
<br />
==== Spawn Mob ====<br />
<br />
Sent by the server when a Mob Entity is Spawned<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=12 | 0x0F<br />
| Entity ID || VarInt || Entity's ID<br />
|-<br />
| Type || Unsigned Byte || The type of mob. See [[Entities#Mobs|Mobs]]<br />
|-<br />
| X || Int || X position as a [[Data_Types#Fixed-point_numbers|Fixed-Point number]] <br />
|-<br />
| Y || Int || Y position as a [[Data_Types#Fixed-point_numbers|Fixed-Point number]] <br />
|-<br />
| Z || Int || Z position as a [[Data_Types#Fixed-point_numbers|Fixed-Point number]] <br />
|-<br />
| Pitch || Byte || The pitch in steps of 2p/256<br />
|-<br />
| Head Pitch || Byte || The pitch in steps of 2p/256<br />
|-<br />
| Yaw || Byte || The yaw in steps of 2p/256<br />
|-<br />
| Velocity X || Short ||<br />
|-<br />
| Velocity Y || Short ||<br />
|-<br />
| Velocity Z || Short ||<br />
|-<br />
| Metadata || [[Entities#Entity_Metadata_Format|Metadata]] ||<br />
|}<br />
<br />
==== Spawn Painting ====<br />
<br />
This packet shows location, name, and type of painting.<br />
<br />
Calculating the center of an image: given a (width x height) grid of cells, with (0, 0) being the top left corner, the center is (max(0, width / 2 - 1), height / 2). E.g.<br />
<br />
2x1 (1, 0)<br />
4x4 (1, 2)<br />
<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=6 | 0x10<br />
| Entity ID || VarInt || Entity's ID<br />
|-<br />
| Title || String || Name of the painting. Max length 13<br />
|-<br />
| X || Int || Center X coordinate<br />
|-<br />
| Y || Int || Center Y coordinate<br />
|-<br />
| Z || Int || Center Z coordinate<br />
|-<br />
| Direction || Int || Direction the painting faces (0 -z, 1 -x, 2 +z, 3 +x)<br />
|}<br />
<br />
==== Spawn Experience Orb ====<br />
<br />
Spawns one or more experience orbs.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=5 | 0x11<br />
| Entity ID || VarInt || Entity's ID<br />
|-<br />
| X || Int || X position as a [[Data_Types#Fixed-point_numbers|Fixed-Point number]] <br />
|-<br />
| Y || Int || Y position as a [[Data_Types#Fixed-point_numbers|Fixed-Point number]] <br />
|-<br />
| Z || Int || Z position as a [[Data_Types#Fixed-point_numbers|Fixed-Point number]] <br />
|-<br />
| Count || Short || The amount of experience this orb will reward once collected<br />
|}<br />
<br />
==== Entity Velocity ====<br />
<br />
Velocity is believed to be in units of 1/8000 of a block per server tick (50ms);<br />
for example, -1343 would move (-1343 / 8000) = −0.167875 blocks per tick (or −3,3575 blocks per second).<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=4 | 0x12<br />
| Entity ID || Int || Entity's ID<br />
|-<br />
| Velocity X || Short || Velocity on the X axis<br />
|-<br />
| Velocity Y || Short || Velocity on the Y axis<br />
|-<br />
| Velocity Z || Short || Velocity on the Z axis<br />
|}<br />
<br />
==== Destroy Entities ====<br />
<br />
Sent by the server when an list of Entities is to be destroyed on the client.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=2 | 0x13<br />
| Count || Byte || Length of following array<br />
|-<br />
| Entity IDs || Array of Int || The list of entities of destroy <br />
|}<br />
<br />
==== Entity ====<br />
<br />
Most entity-related packets are subclasses of this packet. When sent from the server to the client, it may initialize the entry.<br />
<br />
For player entities, either this packet or any move/look packet is sent every game tick.<br />
So the meaning of this packet is basically that the entity did not move/look since the last such packet.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=1 | 0x14<br />
| Entity ID || Int || Entity's ID<br />
|}<br />
<br />
==== Entity Relative Move ====<br />
<br />
This packet is sent by the server when an entity moves less then 4 blocks; if an entity moves more than 4 blocks Entity Teleport should be sent instead.<br />
<br />
This packet allows at most four blocks movement in any direction, because byte range is from -128 to 127.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=4| 0x15<br />
| Entity ID || Int || Entity's ID<br />
|-<br />
| DX || Byte || Change in X position as a [[Data_Types#Fixed-point_numbers|Fixed-Point number]]<br />
|-<br />
| DY || Byte || Change in Y position as a [[Data_Types#Fixed-point_numbers|Fixed-Point number]]<br />
|-<br />
| DZ || Byte || Change in Z position as a [[Data_Types#Fixed-point_numbers|Fixed-Point number]]<br />
|}<br />
<br />
==== Entity Look ====<br />
<br />
This packet is sent by the server when an entity rotates. Example: "Yaw" field 64 means a 90 degree turn.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=3 | 0x16<br />
| Entity ID || Int || Entity's ID<br />
|-<br />
| Yaw || Byte || The X Axis rotation as a fraction of 360<br />
|-<br />
| Pitch || Byte || The Y Axis rotation as a fraction of 360<br />
|}<br />
<br />
==== Entity Look and Relative Move ====<br />
<br />
This packet is sent by the server when an entity rotates and moves.<br />
Since a byte range is limited from -128 to 127, and movement is offset of fixed-point numbers,<br />
this packet allows at most four blocks movement in any direction. (-128/32 == -4)<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=6 | 0x17<br />
| Entity ID || Int || Entity's ID<br />
|-<br />
| DX || Byte || Change in X position as a [[Data_Types#Fixed-point_numbers|Fixed-Point number]]<br />
|-<br />
| DY || Byte || Change in Y position as a [[Data_Types#Fixed-point_numbers|Fixed-Point number]]<br />
|-<br />
| DZ || Byte || Change in Z position as a [[Data_Types#Fixed-point_numbers|Fixed-Point number]]<br />
|-<br />
| Yaw || Byte || The X Axis rotation as a fraction of 360<br />
|-<br />
| Pitch || Byte || The Y Axis rotation as a fraction of 360<br />
|}<br />
<br />
==== Entity Teleport ====<br />
<br />
This packet is sent by the server when an entity moves more than 4 blocks.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=6 | 0x18<br />
| Entity ID || Int || Entity's ID<br />
|-<br />
| X || Int || X position as a [[Data_Types#Fixed-point_numbers|Fixed-Point number]]<br />
|-<br />
| Y || Int || Y position as a [[Data_Types#Fixed-point_numbers|Fixed-Point number]]<br />
|-<br />
| Z || Int || Z position as a [[Data_Types#Fixed-point_numbers|Fixed-Point number]]<br />
|-<br />
| Yaw || Byte || The X Axis rotation as a fraction of 360<br />
|-<br />
| Pitch || Byte || The Y Axis rotation as a fraction of 360<br />
|}<br />
<br />
==== Entity Head Look ====<br />
<br />
Changes the direction an entity's head is facing.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=2 | 0x19<br />
| Entity ID || Int || Entity's ID<br />
|-<br />
| Head Yaw || Byte || Head yaw in steps of 2p/256<br />
|}<br />
<br />
==== Entity Status ====<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=2 | 0x1A<br />
| Entity ID || Int || Entity's ID<br />
|-<br />
| Entity Status || Byte || See below<br />
|}<br />
<br />
{| class="wikitable"<br />
|-<br />
! Entity Status !! Meaning<br />
|-<br />
| 0 || Something related to living entities?<br />
|-<br />
| 1 || Entity hurt<br />
|-<br />
| 2 || Something related to the player entity?<br />
|-<br />
| 3 || Entity dead<br />
|-<br />
| 4 || Iron Golem throwing up arms<br />
|-<br />
| 6 || Wolf taming<br />
|-<br />
| 7 || Wolf tamed<br />
|-<br />
| 8 || Wolf shaking water off itself<br />
|-<br />
| 9 || (of self) Eating accepted by server<br />
|-<br />
| 10 || Sheep eating grass<br />
|-<br />
| 11 || Iron Golem handing over a rose<br />
|-<br />
| 12 || Spawn "heart" particles near a villager<br />
|-<br />
| 13 || Spawn particles indicating that a villager is angry and seeking revenge<br />
|-<br />
| 14 || Spawn happy particles near a villager<br />
|-<br />
| 15 || Spawn a "magic" particle near the Witch<br />
|-<br />
| 16 || Zombie converting into a villager by shaking violently (unused in recent update)<br />
|-<br />
| 17 || A firework exploding<br />
|-<br />
| 18 || Fall in love with human?<br />
|}<br />
<br />
==== Attach Entity ====<br />
<br />
This packet is sent when a player has been attached to an entity (e.g. Minecart)<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=3 | 0x1B<br />
| Entity ID || Int || Entity's ID<br />
|-<br />
| Vehicle ID || Int || Vechicle's Entity ID<br />
|-<br />
| Leash || Bool || If true leashes the entity to the vehicle<br />
|}<br />
<br />
==== Entity Metadata ====<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=2 | 0x1C<br />
| Entity ID || Int || Entity's ID<br />
|-<br />
| Metadata || [[Entities#Entity_Metadata_Format|Metadata]] || <br />
|}<br />
<br />
==== Entity Effect ====<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=4 | 0x1D<br />
| Entity ID || Int || Entity's ID<br />
|-<br />
| Effect ID || Byte || See [[http://www.minecraftwiki.net/wiki/Potion_effect#Parameters]]<br />
|-<br />
| Amplifier || Byte || <br />
|-<br />
| Duration || Short ||<br />
|}<br />
<br />
==== Remove Entity Effect ====<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=2 | 0x1E<br />
| Entity ID || Int || Entity's ID<br />
|-<br />
| Effect ID || Byte ||<br />
|}<br />
<br />
==== Set Experience ====<br />
<br />
Sent by the server when the client should change experience levels.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=3 | 0x1F<br />
| Experience bar || Float || Between 0 and 1<br />
|-<br />
| Level || Short ||<br />
|-<br />
| Total Experience || Short ||<br />
|}<br />
<br />
==== Entity Properties ====<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=3 | 0x20<br />
| Entity ID || Int || Entity's ID<br />
|-<br />
| Count || Int || Length of following array<br />
|-<br />
| Properties || Array of Property Data ||<br />
|}<br />
<br />
'''Property Data''' structure:<br />
{| class="wikitable"<br />
|-<br />
! Field Name !! Field Type !! Notes<br />
|-<br />
| Key || String || <br />
|-<br />
| Value || Double || <br />
|-<br />
| List Length || Short || Number of list elements that follow.<br />
|-<br />
| Modifiers || Array of Modifier Data || http://www.minecraftwiki.net/wiki/Attribute#Modifiers<br />
|}<br />
<br />
Known key values:<br />
{| class="wikitable"<br />
|-<br />
! Key !! Default !! Min !! Max !! Label<br />
|-<br />
| generic.maxHealth || 20.0 || 0.0 || Double.MaxValue || Max Health<br />
|-<br />
| generic.followRange || 32.0 || 0.0 || 2048.0 || Follow Range<br />
|-<br />
| generic.knockbackResistance || 0.0 || 0.0 || 1.0 || Knockback Resistance<br />
|-<br />
| generic.movementSpeed || 0.699999988079071 || 0.0 || Double.MaxValue || Movement Speed<br />
|-<br />
| generic.attackDamage || 2.0 || 0.0 || Double.MaxValue || <br />
|-<br />
| horse.jumpStrength || 0.7 || 0.0 || 2.0 || Jump Strength<br />
|-<br />
| zombie.spawnReinforcements || 0.0 || 0.0 || 1.0 || Spawn Reinforcements Chance<br />
|}<br />
<br />
'''Modifier Data''' structure:<br />
{| class="wikitable"<br />
|-<br />
! Field Name !! Field Type !! Notes<br />
|-<br />
| UUID || 128-bit integer ||<br />
|-<br />
| Amount || Double ||<br />
|-<br />
| Operation || Byte ||<br />
|}<br />
<br />
==== Chunk Data ====<br />
<br />
Chunks are not unloaded by the client automatically. To unload chunks, send this packet with ground-up continuous=true and no 16^3 chunks (eg. primary bit mask=0). The server does not send skylight information for nether-chunks, it's up to the client to know if the player is currently in the nether. You can also infer this information from the primary bitmask and the amount of uncompressed bytes sent.<br />
<br />
See also: [[SMP Map Format]]<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=7 | 0x21<br />
| Chunk X || Int || Chunk X coordinate<br />
|-<br />
| Chunk Z || Int || Chunk Z coordinate<br />
|-<br />
| Ground-Up continuous || Boolean || This is True if the packet represents all sections in this vertical column, where the primary bit map specifies exactly which sections are included, and which are air<br />
|-<br />
| Primary bit map || Unsigned Short || Bitmask with 1 for every 16x16x16 section which data follows in the compressed data.<br />
|-<br />
| Add bit map || Unsigned Short || Same as above, but this is used exclusively for the 'add' portion of the payload<br />
|- <br />
| Compressed size || Int || Size of compressed chunk data<br />
|-<br />
| Compressed data || Byte array || The chunk data is compressed using Zlib Deflate<br />
|}<br />
<br />
==== Multi Block Change ====<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=5 | 0x22<br />
| Chunk X || Short || Chunk X coordinate<br />
|-<br />
| Chunk Z || Short || Chunk Z Coordinate<br />
|-<br />
| Record count || Short || The number of blocks affected<br />
|-<br />
| Data size || Int || The total size of the data, in bytes. Should always be 4*record count<br />
|-<br />
| Records || Array of Records || <br />
|}<br />
<br />
'''Record'''<br />
{| class="wikitable"<br />
|-<br />
! Bit mask !! Width !! Meaning<br />
|-<br />
| 00 00 00 0F || 4 bits || Block metadata<br />
|-<br />
| 00 00 FF F0 || 12 bits || Block ID<br />
|-<br />
| 00 FF 00 00 || 8 bits || Y co-ordinate<br />
|-<br />
| 0F 00 00 00 || 4 bits || Z co-ordinate, relative to chunk<br />
|-<br />
| F0 00 00 00 || 4 bits || X co-ordinate, relative to chunk<br />
|}<br />
<br />
==== Block Change ====<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=5 | 0x23<br />
| X || Int || Block X Coordinate<br />
|-<br />
| Y || Unsigned Byte || Block Y Coordinate<br />
|-<br />
| Z || Int || Block Z Coordinate<br />
|-<br />
| Block ID || VarInt || The new block ID for the block<br />
|-<br />
| Block Metadata || Unsigned Byte || The new metadata for the block<br />
|}<br />
<br />
==== Block Action ====<br />
<br />
This packet is used for a number of things:<br />
* <div class="li">Chests opening and closing<br />
* Pistons pushing and pulling<br />
* Note blocks playing<br />
<br />
See Also: [[Block Actions]] <br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=6 | 0x24<br />
| X || Int || Block X Coordinate<br />
|-<br />
| Y || Short || Block Y Coordinate<br />
|-<br />
| Z || Int || Block Z Coordinate<br />
|-<br />
| Byte 1 || Unsigned Byte || Varies depending on block - see [[Block_Actions]]<br />
|-<br />
| Byte 2 || Unsigned Byte || Varies depending on block - see [[Block_Actions]]<br />
|-<br />
| Block Type || VarInt || The block type for the block<br />
|}<br />
<br />
==== Block Break Animation ====<br />
<br />
0-9 are the displayable destroy stages and each other number means that there is no animation on this coordinate.<br />
<br />
You can also set an animation to air! The animation will still be visible.<br />
<br />
If you need to display several break animations at the same time you have to give each of them a unique Entity ID.<br />
<br />
Also if you set the coordinates to a special block like water etc. it won't show the actual break animation but some other interesting effects. (Water will loose it's transparency)<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=5 | 0x25<br />
| Entity ID || VarInt || Entity's ID<br />
|-<br />
| X || Int || rowspan=3 | Block Position<br />
|-<br />
| Y || Int<br />
|-<br />
| Z || Int<br />
|-<br />
| Destroy Stage || Byte || 0 - 9<br />
|}<br />
<br />
==== Map Chunk Bulk ====<br />
<br />
See also: [[SMP Map Format]]<br />
<br />
To reduce the number of bytes this packet is used to send chunks together for better compression results.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=5 | 0x26<br />
| Chunk column count || Short || The number of chunk in this packet<br />
|-<br />
| Data length || Int || The size of the data field<br />
|-<br />
| Sky light sent || Bool || Whether or not the chunk data contains a light nibble array. This is true in the main world, false in the end + nether<br />
|-<br />
| Data || Byte Array || Compressed chunk data<br />
|-<br />
| Meta information || Meta || See below <br />
|}<br />
<br />
'''Meta'''<br />
{| class="wikitable"<br />
! Field Name !! Field Type !! Notes<br />
|-<br />
|Chunk X || Int || The X Coordinate of the chunk<br />
|-<br />
|Chunk Z || Int || The Z Coordinate of the chunk<br />
|-<br />
|Primary bitmap || Unsigned Short || A bitmap which specifies which sections are not empty in this chunk<br />
|-<br />
|Add bitmap || Unsigned Short || A bitmap which specifies which sections need add information because of very high block ids. not yet used<br />
|}<br />
<br />
==== Explosion ====<br />
<br />
Sent when an explosion occurs (creepers, TNT, and ghast fireballs).<br />
<br />
Each block in Records is set to air. Coordinates for each axis in record is int(X) + record.x<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="9" | 0x27<br />
| X || Float ||<br />
|-<br />
| Y || Float ||<br />
|-<br />
| Z || Float ||<br />
|-<br />
| Radius || Float || Currently unused in the client<br />
|-<br />
| Record count || Int || This is the count, not the size. The size is 3 times this value.<br />
|-<br />
| Records || (Byte, Byte, Byte) × count || Each record is 3 signed bytes long, each bytes are the XYZ (respectively) offsets of affected blocks.<br />
|-<br />
| Player Motion X || Float || X velocity of the player being pushed by the explosion<br />
|-<br />
| Player Motion Y || Float || Y velocity of the player being pushed by the explosion<br />
|-<br />
| Player Motion Z || Float || Z velocity of the player being pushed by the explosion<br />
|}<br />
<br />
==== Effect ====<br />
<br />
Sent when a client is to play a sound or particle effect.<br />
<br />
By default, the minecraft client adjusts the volume of sound effects based on distance. The final boolean field is used to disable this, and instead the effect is played from 2 blocks away in the correct direction. Currently this is only used for effect 1013 (mob.wither.spawn), and is ignored for any other value by the client.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="6" | 0x28<br />
| Effect ID || Int || The ID of the effect, see below.<br />
|-<br />
| X || Int || The X location of the effect<br />
|-<br />
| Y || Byte || The Y location of the effect<br />
|-<br />
| Z || Int || The Z location of the effect<br />
|-<br />
| Data || Int || Extra data for certain effects, see below.<br />
|-<br />
| Disable relative volume || Bool || See above<br />
|}<br />
<br />
===== Effects =====<br />
<br />
{| class="wikitable"<br />
! ID !! Name<br />
|-<br />
| colspan=2 | '''Sound'''<br />
|-<br />
| 1000|| <code>random.click</code><br />
|-<br />
| 1001|| <code>random.click</code><br />
|-<br />
| 1002|| <code>random.bow</code><br />
|-<br />
| 1003|| <code>random.door_open</code> or <code>random.door_close</code> (50/50 chance)<br />
|-<br />
| 1004|| <code>random.fizz</code><br />
|-<br />
| 1005|| Play a music disc. '''Data''' [http://www.minecraftwiki.net/wiki/Music_Discs Record ID]<br />
|-<br />
| ''(1006 not assigned)'' ||<br />
|-<br />
| 1007|| <code>mob.ghast.charge</code><br />
|-<br />
| 1008|| <code>mob.ghast.fireball</code><br />
|-<br />
| 1009|| <code>mob.ghast.fireball</code>, but with a lower volume.<br />
|-<br />
| 1010|| <code>mob.zombie.wood</code><br />
|-<br />
| 1011|| <code>mob.zombie.metal</code><br />
|-<br />
| 1012|| <code>mob.zombie.woodbreak</code><br />
|-<br />
| 1013|| <code>mob.wither.spawn</code><br />
|-<br />
| 1014|| <code>mob.wither.shoot</code><br />
|-<br />
| 1015|| <code>mob.bat.takeoff</code><br />
|-<br />
| 1016|| <code>mob.zombie.infect</code><br />
|-<br />
| 1017|| <code>mob.zombie.unfect</code><br />
|-<br />
| 1018|| <code>mob.enderdragon.end</code><br />
|-<br />
| 1020|| <code>random.anvil_break</code><br />
|-<br />
| 1021|| <code>random.anvil_use</code><br />
|-<br />
| 1022|| <code>random.anvil_land</code><br />
|-<br />
| colspan=2 | '''Particle'''<br />
|-<br />
| 2000|| Spawns 10 smoke particles, e.g. from a fire. '''Data''' direction, see below<br />
|-<br />
| 2001|| Block break. '''Data''' [http://www.minecraftwiki.net/wiki/Data_values Block ID]<br />
|-<br />
| 2002|| Splash potion. Particle effect + glass break sound. '''Data''' [http://www.lb-stuff.com/Minecraft/PotionDataValues1.9pre3.txt Potion ID]<br />
|-<br />
| 2003|| Eye of ender entity break animation - particles and sound<br />
|-<br />
| 2004|| Mob spawn particle effect: smoke + flames<br />
|-<br />
| 2005|| Spawn "happy villager" effect (green crosses), used for bonemealing vegetation.<br />
|-<br />
| 2005|| Spawn fall particles (when player hits ground). '''Data''' fall damage taken for particle speed<br />
|}<br />
<br />
Smoke directions:<br />
<br />
{| class="wikitable"<br />
! ID !! Direction<br />
|-<br />
| 0 || South - East<br />
|-<br />
| 1 || South<br />
|-<br />
| 2 || South - West<br />
|-<br />
| 3 || East<br />
|-<br />
| 4 || (Up or middle ?)<br />
|-<br />
| 5 || West<br />
|-<br />
| 6 || North - East<br />
|-<br />
| 7 || North<br />
|-<br />
| 8 || North - West<br />
|}<br />
<br />
==== Sound Effect ====<br />
<br />
Used to play a sound effect on the client.<br />
<br />
All known sound effect names can be seen [https://github.com/SirCmpwn/Craft.Net/blob/master/source/Craft.Net.Common/SoundEffect.cs here].<br />
<br />
Custom sounds made be added by resource packs<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="7" | 0x29<br />
| Sound name || String || <br />
|-<br />
| Effect position X || Int || Effect X multiplied by 8<br />
|-<br />
| Effect position Y || Int || Effect Y multiplied by 8<br />
|-<br />
| Effect position Z || Int || Effect Z multiplied by 8<br />
|-<br />
| Volume || Float || 1 is 100%, can be more<br />
|-<br />
| Pitch || Unsigned Byte || 63 is 100%, can be more<br />
|}<br />
<br />
==== Particle ====<br />
<br />
Displays the named particle<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="9" | 0x2A<br />
| Particle name || String || The name of the particle to create. A list can be found [https://gist.github.com/thinkofdeath/5110835 here]<br />
|-<br />
| X || Float || X position of the particle<br />
|-<br />
| Y || Float || Y position of the particle<br />
|-<br />
| Z || Float || Z position of the particle<br />
|-<br />
| Offset X || Float || This is added to the X position after being multiplied by random.nextGaussian() <br />
|-<br />
| Offset Y || Float || This is added to the Y position after being multiplied by random.nextGaussian() <br />
|-<br />
| Offset Z || Float || This is added to the Z position after being multiplied by random.nextGaussian() <br />
|-<br />
| Particle data || Float || The data of each particle<br />
|-<br />
| Number of particles || Int || The number of particles to create<br />
|}<br />
<br />
==== Change Game State ====<br />
<br />
It appears when a bed can't be used as a spawn point and when the rain state changes. <br />
<br />
The class has an array of strings linked to reason codes 0, 1, 2, and 3 but only the codes for 1 and 2 are null.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="2" | 0x2B<br />
| Reason || Unsigned Byte ||<br />
|-<br />
| Value || Float || Depends on reason<br />
|}<br />
<br />
'''Reason codes'''<br />
<br />
{| class="wikitable"<br />
! Code !! Effect !! Notes<br />
|-<br />
| 0 || Invalid Bed || "tile.bed.notValid"<br />
|-<br />
| 1 || End raining || <br />
|-<br />
| 2 || Begin raining || <br />
|-<br />
| 3 || Change game mode || "gameMode.changed" 0 - Survival, 1 - Creative, 2 - Adventure <br />
|-<br />
| 4 || Enter credits ||<br />
|-<br />
| 5 || Demo messages || 0 - Show welcome to demo screen, 101 - Tell movement controls, 102 - Tell jump control, 103 - Tell inventory control<br />
|- <br />
| 6 || Arrow hitting player || Appears to be played when an arrow strikes another player in Multiplayer<br />
|-<br />
| 7 || Fade value || The current darkness value. 1 = Dark, 0 = Bright, Setting the value higher causes the game to change color and freeze<br />
|-<br />
| 8 || Fade time || Time in ticks for the sky to fade<br />
|}<br />
<br />
==== Spawn Global Entity ====<br />
<br />
With this packet, the server notifies the client of thunderbolts striking within a 512 block radius around the player. The coordinates specify where exactly the thunderbolt strikes.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="5" | 0x2C<br />
| Entity ID || VarInt || The entity ID of the thunderbolt<br />
|-<br />
| Type || Byte || The global entity type, currently always 1 for thunderbolt.<br />
|-<br />
| X || Int || Thunderbolt X a [[Data_Types#Fixed-point_numbers|fixed-point number]]<br />
|-<br />
| Y || Int || Thunderbolt Y a [[Data_Types#Fixed-point_numbers|fixed-point number]]<br />
|-<br />
| Z || Int || Thunderbolt Z a [[Data_Types#Fixed-point_numbers|fixed-point number]]<br />
|}<br />
<br />
==== Open Window ====<br />
<br />
This is sent to the client when it should open an inventory, such as a chest, workbench, or furnace. This message is not sent anywhere for clients opening their own inventory.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="6" | 0x2D<br />
| Window id || Unsigned Byte || A unique id number for the window to be displayed. Notchian server implementation is a counter, starting at 1.<br />
|-<br />
| Inventory Type || Unsigned Byte || The window type to use for display. Check below<br />
|-<br />
| Window title || String || The title of the window.<br />
|-<br />
| Number of Slots || Unsigned Byte || Number of slots in the window (excluding the number of slots in the player inventory).<br />
|-<br />
| Use provided window title || Bool || If false, the client will look up a string like "window.minecart". If true, the client uses what the server provides.<br />
|-<br />
| Entity ID || Int || EntityHorse's entityId. Only sent when window type is equal to 11 (AnimalChest).<br />
|}<br />
<br />
See [[Inventory#Windows|inventory windows]] for further information.<br />
<br />
==== Close Window ====<br />
<br />
This packet is sent from the server to the client when a window is forcibly closed, such as when a chest is destroyed while it's open.<br />
<br />
Note, notchian clients send a close window message with window id 0 to close their inventory even though there is never an Open Window message for inventory. <br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| 0x2E<br />
| Window ID || Unsigned Byte || This is the id of the window that was closed. 0 for inventory.<br />
|}<br />
<br />
==== Set Slot ====<br />
<br />
Sent by the server when an item in a slot (in a window) is added/removed.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="3" | 0x2F<br />
| Window ID || Byte<br />
| The window which is being updated. 0 for player inventory. Note that all known window types include the player inventory. This packet will only be sent for the currently opened window while the player is performing actions, even if it affects the player inventory. After the window is closed, a number of these packets are sent to update the player's inventory window (0).<br />
|-<br />
| Slot || Short || The slot that should be updated<br />
|-<br />
| Slot data || [[Slot_Data|Slot]] ||<br />
|}<br />
<br />
==== Window Items ====<br />
<br />
[[File:Inventory-slots.png|thumb|The inventory slots]]<br />
<br />
Sent by the server when an item in a slot (in a window) is added/removed. This includes the main inventory, equipped armour and crafting slots. <br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="3" | 0x30<br />
| Window ID || Unsigned Byte || The id of window which items are being sent for. 0 for player inventory.<br />
|-<br />
| Count || Short || The number of slots (see below)<br />
|-<br />
| Slot data || Array of [[Slot_Data|Slot]]s ||<br />
|}<br />
<br />
See [[Inventory#Windows|inventory windows]] for further information about how slots are indexed.<br />
<br />
==== Window Property ====<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="3" | 0x31<br />
| Window ID || Unsigned Byte || The id of the window.<br />
|-<br />
| Property || Short || Which property should be updated.<br />
|-<br />
| Value || Short || The new value for the property.<br />
|}<br />
<br />
'''Furnace'''<br />
<br />
Properties:<br />
<br />
* 0: Progress arrow<br />
* 1: Fire icon (fuel)<br />
<br />
Values:<br />
<br />
* 0-200 for progress arrow<br />
* 0-200 for fuel indicator<br />
<br />
Ranges are presumably in in-game ticks<br />
<br />
'''Enchantment Table'''<br />
<br />
Properties: 0, 1 or 2 depending on the "enchantment slot" being given.<br />
<br />
Values: The enchantment's level.<br />
<br />
==== Confirm Transaction ====<br />
<br />
A packet from the server indicating whether a request from the client was accepted, or whether there was a conflict (due to lag). This packet is also sent from the client to the server in response to a server transaction rejection packet.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="3" | 0x32<br />
| Window ID || Unsigned Byte || The id of the window that the action occurred in.<br />
|-<br />
| Action number || Short || Every action that is to be accepted has a unique number. This field corresponds to that number.<br />
|-<br />
| Accepted || Bool || Whether the action was accepted.<br />
|}<br />
<br />
==== Update Sign ====<br />
<br />
This message is sent from the server to the client whenever a sign is discovered or created. This message is NOT sent when a sign is destroyed or unloaded.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="7" | 0x33<br />
| X || Int || Block X Coordinate<br />
|-<br />
| Y || Short || Block Y Coordinate<br />
|-<br />
| Z || Int || Block Z Coordinate<br />
|-<br />
| Line 1 || String || First line of text in the sign<br />
|-<br />
| Line 2 || String || Second line of text in the sign<br />
|-<br />
| Line 3 || String || Third line of text in the sign<br />
|-<br />
| Line 4 || String || Fourth line of text in the sign<br />
|}<br />
<br />
==== Maps ====<br />
<br />
If the first byte of the array is 0, the next two bytes are X start and Y start and the rest of the bytes are the colors in that column.<br />
<br />
If the first byte of the array is 1, the rest of the bytes are in groups of three: (data, x, y). The lower half of the data is the type (always 0 under vanilla) and the upper half is the direction.<br />
<br />
If the first byte of the array is 2, the second byte is the map scale.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="4" | 0x34<br />
| Item Damage || VarInt || The damage value of the map being modified<br />
|-<br />
| Length || Short || Length of following byte array<br />
|-<br />
| Data || Byte Array || Array data<br />
|}<br />
<br />
==== Update Block Entity ====<br />
<br />
Essentially a block update on a block entity.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="6" | 0x35<br />
| X || Int ||<br />
|-<br />
| Y || Short ||<br />
|-<br />
| Z || Int ||<br />
|-<br />
| Action || Unsigned Byte || The type of update to perform<br />
|-<br />
| Data length || Short || Varies<br />
|-<br />
| NBT Data || Byte Array || Present if data length > 0. Compressed with [[wikipedia:Gzip|gzip]]. Varies<br />
|}<br />
<br />
'''Actions'''<br />
<br />
* '''1''': Set mob displayed inside a mob spawner. Custom 1 contains the [[Entities#Mobs|mob type]]<br />
<br />
==== Sign Editor Open ====<br />
<br />
Sent on placement of sign.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="3" | 0x36<br />
| X || Int || X in block coordinates<br />
|-<br />
| Y || Int || Y in block coordinates<br />
|-<br />
| Z || Int || Z in block coordinates<br />
|}<br />
<br />
==== Statistics ====<br />
{| class="wikitable"<br />
! Packet ID<br />
! colspan="2" | Field Name<br />
! Field Type !! Notes<br />
|-<br />
| rowspan="3" | 0x37<br />
| colspan="2" | Count || VarInt || Number of entrys<br />
|-<br />
| rowspan=2 | Entry <br />
| Statistic's name || String || https://gist.github.com/thinkofdeath/a1842c21a0cf2e1fb5e0<br />
|-<br />
| Value || VarInt || The amount to set it to<br />
|}<br />
<br />
==== Player List Item ====<br />
<br />
Sent by the notchian server to update the user list (<tab> in the client).<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="3" | 0x38<br />
| Player name || String || Supports chat colouring, limited to 16 characters.<br />
|-<br />
| Online || Bool || The client will remove the user from the list if false.<br />
|-<br />
| Ping || Short || Ping, presumably in ms.<br />
|}<br />
<br />
==== Player Abilities ====<br />
<br />
The latter 2 floats are used to indicate the walking and flying speeds respectively, while the first byte is used to determine the value of 4 booleans.<br />
<br />
The flags are whether damage is disabled (god mode, 8, bit 3), whether the player can fly (4, bit 2), whether the player is flying (2, bit 1), and whether the player is in creative mode (1, bit 0).<br />
<br />
To get the values of these booleans, simply AND (&) the byte with 1,2,4 and 8 respectively, to get the 0 or 1 bitwise value. To set them OR (|) them with their repspective masks.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="3" | 0x39<br />
| Flags || Byte ||<br />
|-<br />
| Flying speed || Float|| previous integer value divided by 250<br />
|-<br />
| Walking speed || Float || previous integer value divided by 250<br />
|}<br />
<br />
==== Tab-Complete ====<br />
<br />
The server responds with a list of auto-completions of the last word sent to it. In the case of regular chat, this is a player username. Command names and parameters are also supported.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=2| 0x3A <br />
| Count || VarInt || Number of following strings<br />
|-<br />
| Match || String || One eligible command, note that each command is sent separately instead of in a single string, hence the need for Count<br />
|}<br />
<br />
==== Scoreboard Objective ====<br />
<br />
This is sent to the client when it should create a new scoreboard or remove one.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="3" | 0x3B<br />
| Objective name || String || An unique name for the objective<br />
|-<br />
| Objective value || String || The text to be displayed for the score.<br />
|-<br />
| Create/Remove || Byte || 0 to create the scoreboard. 1 to remove the scoreboard. 2 to update the display text. <br />
|}<br />
<br />
==== Update Score ====<br />
<br />
This is sent to the client when it should update a scoreboard item. <br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="4" | 0x3C<br />
| Item Name || String || An unique name to be displayed in the list.<br />
|-<br />
| Update/Remove || Byte || 0 to create/update an item. 1 to remove an item.<br />
|-<br />
| Score Name || String || The unique name for the scoreboard to be updated. Only sent when Update/Remove does not equal 1.<br />
|-<br />
| Value || Int || The score to be displayed next to the entry. Only sent when Update/Remove does not equal 1.<br />
|}<br />
{{Warning|The final String and Int are only sent if the Update/Remove Byte does not equal 1}}<br />
<br />
==== Display Scoreboard ====<br />
<br />
This is sent to the client when it should display a scoreboard.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="2" | 0x3D<br />
| Position || Byte || The position of the scoreboard. 0 = list, 1 = sidebar, 2 = belowName.<br />
|-<br />
| Score Name || String || The unique name for the scoreboard to be displayed.<br />
|}<br />
<br />
==== Teams ====<br />
<br />
Creates and updates teams.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="8" | 0x3E<br />
| Team Name || String || A unique name for the team. (Shared with scoreboard).<br />
|-<br />
| Mode || Byte || If 0 then the team is created. <br />
If 1 then the team is removed. <br />
<br />
If 2 the team team information is updated. <br />
<br />
If 3 then new players are added to the team. <br />
<br />
If 4 then players are removed from the team.<br />
|-<br />
| Team Display Name || String || Only if Mode = 0 or 2. <br />
|-<br />
| Team Prefix || String || Only if Mode = 0 or 2. Displayed before the players' name that are part of this team. <br />
|-<br />
| Team Suffix || String || Only if Mode = 0 or 2. Displayed after the players' name that are part of this team. <br />
|-<br />
| Friendly fire || Byte || Only if Mode = 0 or 2; 0 for off, 1 for on, 3 for seeing friendly invisibles<br />
|-<br />
| Player count || Short || Only if Mode = 0 or 3 or 4. Number of players in the array<br />
|-<br />
| Players || Array of strings || Only if Mode = 0 or 3 or 4. Players to be added/remove from the team.<br />
|}<br />
<br />
==== Plugin Message ====<br />
<br />
Mods and plugins can use this to send their data. Minecraft itself uses a number of [[plugin channel]]s. These internal channels are prefixed with <code>MC|</code>.<br />
<br />
More documentation on this: http://dinnerbone.com/blog/2012/01/13/minecraft-plugin-channels-messaging/<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="3" | 0x3F<br />
| Channel || String || Name of the "channel" used to send the data.<br />
|-<br />
| Length || Short || Length of the following byte array<br />
|-<br />
| Data || Byte Array || Any data.<br />
|}<br />
<br />
==== Disconnect ====<br />
<br />
Sent by the server before it disconnects a client. The server assumes that the sender has already closed the connection by the time the packet arrives.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| 0x40<br />
| Reason || String || Displayed to the client when the connection terminates. Must be valid JSON.<br />
|}<br />
<br />
=== Serverbound ===<br />
<br />
==== Keep Alive ====<br />
<br />
The server will frequently send out a keep-alive, each containing a random ID. The client must respond with the same packet.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=1 | 0x00<br />
| Keep Alive ID || Int ||<br />
|}<br />
<br />
==== Chat Message ====<br />
<br />
The default server will check the message to see if it begins with a '/'. If it doesn't, the username of the sender is prepended and sent to all other clients (including the original sender). If it does, the server assumes it to be a command and attempts to process it. A message longer than 100 characters will cause the server to kick the client. This change was initially done by allowing the client to not slice the message up to 119 (the previous limit), without changes to the server. For this reason, the vanilla server kept the code to cut messages at 119, but this isn't a protocol limitation and can be ignored.<br />
<br />
For more information, see [[Chat]].<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=1 | 0x01<br />
| Message || String || <br />
|}<br />
<br />
==== Use Entity ====<br />
<br />
This packet is sent from the client to the server when the client attacks or right-clicks another entity (a player, minecart, etc).<br />
<br />
A Notchian server only accepts this packet if the entity being attacked/used is visible without obstruction and within a 4-unit radius of the player's position.<br />
<br />
Note that middle-click in creative mode is interpreted by the client and sent as a Creative Inventory Action packet instead.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=2 | 0x02<br />
| Target || Int ||<br />
|-<br />
| Mouse || Byte || 0 = Left-click, 1 = Right-click<br />
|}<br />
<br />
==== Player ====<br />
<br />
This packet is used to indicate whether the player is on ground (walking/swimming), or airborne (jumping/falling).<br />
<br />
When dropping from sufficient height, fall damage is applied when this state goes from False to True. The amount of damage applied is based on the point where it last changed from True to False. Note that there are several movement related packets containing this state.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=1 | 0x03<br />
| On Ground || Bool || True if the client is on the ground, False otherwise<br />
|}<br />
<br />
==== Player Position ====<br />
<br />
Updates the players XYZ position on the server. <br />
If <code>HeadY - FeetY</code> is less than <code>0.1</code> or greater than <code>1.65</code>, the stance is illegal and the client will be kicked with the message “Illegal Stance”.<br />
If the distance between the last known position of the player on the server and the new position set by this packet is greater than 100 units will result in the client being kicked for "You moved too quickly :( (Hacking?)"<br />
Also if the fixed-point number of X or Z is set greater than <code>3.2E7D</code> the client will be kicked for "Illegal position" <br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=5| 0x04<br />
| X || Double || Absolute position<br />
|-<br />
| FeetY || Double || Absolute feet position, normally HeadY - 1.62. Used to modify the players bounding box when going up stairs, crouching, etc…<br />
|-<br />
| HeadY || Double || Absolute head position<br />
|-<br />
| Z || Double || Absolute position<br />
|-<br />
| On Ground || Bool || True if the client is on the ground, False otherwise<br />
|}<br />
<br />
==== Player Look ====<br />
<br />
[[File:Minecraft-trig-yaw.png|thumb|The unit circle for yaw]]<br />
<br />
[[File:Yaw.png|thumb|The unit circle of yaw, redrawn]]<br />
<br />
Updates the direction the player is looking in.<br />
<br />
Yaw is measured in degrees, and does not follow classical trigonometry rules. The unit circle of yaw on the XZ-plane starts at (0, 1) and turns counterclockwise, with 90 at (-1, 0), 180 at (0,-1) and 270 at (1, 0). Additionally, yaw is not clamped to between 0 and 360 degrees; any number is valid, including negative numbers and numbers greater than 360.<br />
<br />
Pitch is measured in degrees, where 0 is looking straight ahead, -90 is looking straight up, and 90 is looking straight down.<br />
<br />
The yaw of player (in degrees), standing at point (x0,z0) and looking towards point (x,z) one can be calculated with:<br />
l = x-x0<br />
w = z-z0<br />
c = sqrt( l*l + w+w )<br />
alpha1 = -arcsin(l/c)/PI*180<br />
alpha2 = arccos(w/c)/PI*180<br />
if alpha2 > 90 then<br />
yaw = 180 - alpha1<br />
else<br />
yaw = alpha1<br />
<br />
Pitch is measured in degrees, where 0 is looking straight ahead, -90 is looking straight up, and 90 is looking straight down.<br />
<br />
You can get a unit vector from a given yaw/pitch via:<br />
x = -cos(pitch) * sin(yaw)<br />
y = -sin(pitch)<br />
z = cos(pitch) * cos(yaw)<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=3| 0x05<br />
| Yaw || Float || Absolute rotation on the X Axis, in degrees<br />
|-<br />
| Pitch || Float || Absolute rotation on the Y Axis, in degrees<br />
|-<br />
| On Ground || Bool || True if the client is on the ground, False otherwise<br />
|}<br />
<br />
==== Player Position And Look ====<br />
<br />
A combination of Player Look and Player position. <br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=7| 0x06<br />
| X || Double || Absolute position<br />
|-<br />
| FeetY || Double || Absolute feet position. Is normally HeadY - 1.62. Used to modify the players bounding box when going up stairs, crouching, etc…<br />
|-<br />
| HeadY || Double || Absolute head position<br />
|-<br />
| Z || Double || Absolute position<br />
|-<br />
| Yaw || Float || Absolute rotation on the X Axis, in degrees<br />
|-<br />
| Pitch || Float || Absolute rotation on the Y Axis, in degrees<br />
|-<br />
| On Ground || Bool || True if the client is on the ground, False otherwise<br />
|}<br />
<br />
==== Player Digging ====<br />
<br />
Sent when the player mines a block. A Notchian server only accepts digging packets with coordinates within a 6-unit radius of the player's position.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="5" | 0x07<br />
| Status || Byte || The action the player is taking against the block (see below)<br />
|-<br />
| X || Int || Block position<br />
|-<br />
| Y || Unsigned Byte || Block position<br />
|-<br />
| Z || Int || Block position<br />
|-<br />
| Face || Byte || The face being hit (see below)<br />
|}<br />
<br />
Status can (currently) be one of six values:<br />
<br />
{| class="wikitable"<br />
! Meaning !! Value<br />
|-<br />
| Started digging || <code>0</code><br />
|-<br />
| Cancelled digging || <code>1</code><br />
|-<br />
| Finished digging || <code>2</code><br />
|-<br />
| Drop item stack || <code>3</code><br />
|-<br />
| Drop item || <code>4</code><br />
|-<br />
| Shoot arrow / finish eating || <code>5</code><br />
|}<br />
<br />
Notchian clients send a 0 (started digging) when they start digging and a 2 (finished digging) once they think they are finished. If digging is aborted, the client simply send a 1 (Cancel digging).<br />
<br />
Status code 4 (drop item) is a special case. In-game, when you use the Drop Item command (keypress 'q'), a dig packet with a status of 4, and all other values set to 0, is sent from client to server. Status code 3 is similar, but drops the entire stack.<br />
<br />
Status code 5 (shoot arrow / finish eating) is also a special case. The x, y and z fields are all set to 0 like above, with the exception of the face field, which is set to 255.<br />
<br />
The face can be one of six values, representing the face being hit:<br />
<br />
{| class="wikitable"<br />
|-<br />
| Value || 0 || 1 || 2 || 3 || 4 || 5<br />
|-<br />
| Offset || -Y || +Y || -Z || +Z || -X || +X<br />
|}<br />
<br />
In 1.7.3, when a player opens a door with left click the server receives Packet 0xE+start digging and opens the door.<br />
<br />
==== Player Block Placement ====<br />
{| class="wikitable"<br />
|-<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="8" | 0x08<br />
| X || Int || Block position<br />
|-<br />
| Y || Unsigned Byte || Block position<br />
|-<br />
| Z || Int || Block position<br />
|-<br />
| Direction || Byte || The offset to use for block/item placement (see below)<br />
|-<br />
| Held item || [[Slot_Data|Slot]] ||<br />
|-<br />
| Cursor position X || Byte || The position of the crosshair on the block<br />
|-<br />
| Cursor position Y || Byte ||<br />
|-<br />
| Cursor position Z || Byte ||<br />
|}<br />
In normal operation (ie placing a block), this packet is sent once, with the values set normally.<br />
<br />
This packet has a special case where X, Y, Z, and Direction are all -1. (Note that Y is unsigned so set to 255.) This special packet indicates that the currently held item for the player should have its state updated such as eating food, shooting bows, using buckets, etc.<br />
<br />
In a Notchian Beta client, the block or item ID corresponds to whatever the client is currently holding, and the client sends one of these packets any time a right-click is issued on a surface, so no assumptions can be made about the safety of the ID. However, with the implementation of server-side inventory, a Notchian server seems to ignore the item ID, instead operating on server-side inventory information and holding selection. The client has been observed (1.2.5 and 1.3.2) to send both real item IDs and -1 in a single session.<br />
<br />
Special note on using buckets: When using buckets, the Notchian client might send two packets: first a normal and then a special case. The first normal packet is sent when you're looking at a block (e.g. the water you want to scoop up). This normal packet does not appear to do anything with a Notchian server. The second, special case packet appears to perform the action - based on current position/orientation and with a distance check - it appears that buckets can only be used within a radius of 6 units.<br />
<br />
==== Held Item Change ====<br />
<br />
Sent when the player changes the slot selection<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=1 | 0x09<br />
| Slot || Short || The slot which the player has selected (0-8)<br />
|}<br />
<br />
==== Animation ====<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=2 | 0x0A<br />
| Entity ID || Int || Player ID<br />
|-<br />
| Animation || Byte || Animation ID<br />
|}<br />
<br />
<br />
Animation can be one of the following values:<br />
<br />
{| class="wikitable"<br />
! ID !! Animation<br />
|-<br />
| 0 || No animation<br />
|-<br />
| 1 || Swing arm<br />
|-<br />
| 2 || Damage animation<br />
|-<br />
| 3 || Leave bed<br />
|-<br />
| 5 || Eat food<br />
|-<br />
| 6 || Critical effect<br />
|-<br />
| 7 || Magic critical effect<br />
|-<br />
| 102 || (unknown)<br />
|-<br />
| 104 || Crouch<br />
|-<br />
| 105 || Uncrouch<br />
|}<br />
<br />
==== Entity Action ====<br />
<br />
Sent at least when crouching, leaving a bed, or sprinting.<br />
To send action animation to client use 0x28.<br />
The client will send this with Action ID = 3 when "Leave Bed" is clicked.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="3" | 0x0B<br />
| Entity ID || Int || Player ID<br />
|-<br />
| Action ID || Byte || The ID of the action, see below.<br />
|-<br />
| Jump Boost || Int || Horse jump boost. Ranged from 0 -> 100.<br />
|}<br />
<br />
Action ID can be one of the following values:<br />
<br />
{| class="wikitable"<br />
! ID !! Action<br />
|-<br />
| 1 || Crouch<br />
|-<br />
| 2 || Uncrouch<br />
|-<br />
| 3 || Leave bed<br />
|-<br />
| 4 || Start sprinting<br />
|-<br />
| 5 || Stop sprinting<br />
|}<br />
<br />
==== Steer Vehicle ====<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="4" | 0x0C<br />
| Sideways || Float || Positive to the left of the player<br />
|-<br />
| Forward || Float || Positive forward<br />
|-<br />
| Jump || Bool ||<br />
|-<br />
| Unmount || Bool || True when leaving the vehicle<br />
|}<br />
<br />
==== Close Window ====<br />
<br />
This packet is sent by the client when closing a window. <br />
<br />
Note, notchian clients send a close window message with window id 0 to close their inventory even though there is never an Open Window message for inventory. <br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| 0x0D<br />
| Window id || byte || This is the id of the window that was closed. 0 for inventory.<br />
|}<br />
<br />
<br />
==== Click Window ====<br />
<br />
This packet is sent by the player when it clicks on a slot in a window.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="6" | 0x0E<br />
| Window ID || Byte || The id of the window which was clicked. 0 for player inventory.<br />
|-<br />
| Slot || Short || The clicked slot. See below.<br />
|-<br />
| Button || Byte || The button used in the click. See below.<br />
|-<br />
| Action number || Short || A unique number for the action, used for transaction handling (See the Transaction packet).<br />
|-<br />
| Mode || Byte || Inventory operation mode. See below.<br />
|-<br />
| Clicked item || [[Slot_Data|Slot]] ||<br />
|}<br />
<br />
See [[Inventory#Windows|inventory windows]] for further information about how slots are indexed.<br />
<br />
When right-clicking on a stack of items, half the stack will be picked up and half left in the slot. If the stack is an odd number, the half left in the slot will be smaller of the amounts.<br />
<br />
The Action number is actually a counter, starting at 1. This number is used by the server as a transaction ID to send back a [[#0x6A|Transaction packet]].<br />
<br />
The distinct type of click performed by the client is determined by the combination of the "Mode" and "Button" fields.<br />
{| class="wikitable"<br />
! Mode !! Button !! Slot !! Trigger<br />
|-<br />
! rowspan="2" | 0<br />
| 0 || Normal || Left mouse click<br />
|-<br />
| 1 || Normal || Right mouse click<br />
|-<br />
! rowspan="2" | 1<br />
| 0 || Normal || Shift + left mouse click<br />
|-<br />
| 1 || Normal || Shift + right mouse click ''(Identical behavior)''<br />
|-<br />
! rowspan="5" | 2<br />
| 0 || Normal || Number key 1<br />
|-<br />
| 1 || Normal || Number key 2<br />
|-<br />
| 2 || Normal || Number key 3<br />
|-<br />
| ...<br />
| ...<br />
| ...<br />
|-<br />
| 8 || Normal || Number key 9<br />
|-<br />
! rowspan="1" | 3<br />
| 2 || Normal || Middle click<br />
|-<br />
! rowspan="4" | 4<br />
| 0 || Normal || Drop key (Q)<br />
|-<br />
| 1 || Normal || Ctrl + Drop key (Ctrl-Q)<br />
|-<br />
| 0 || -999 || Left click outside inventory holding nothing ''(No-op)''<br />
|-<br />
| 1 || -999 || Right click outside inventory holding nothing ''(No-op)''<br />
|-<br />
! rowspan="6" | 5<br />
| 0 || -999 || Starting left mouse drag ''(Or middle mouse)''<br />
|-<br />
| 4 || -999 || Starting right mouse drag<br />
|-<br />
| 1 || Normal || Add slot for left-mouse drag<br />
|-<br />
| 5 || Normal || Add slot for right-mouse drag<br />
|-<br />
| 2 || -999 || Ending left mouse drag<br />
|-<br />
| 6 || -999 || Ending right mouse drag<br />
|-<br />
! 6 <br />
| 0 || Normal || Double click<br />
|}<br />
<br />
Starting from version 1.5, "painting mode" is available for use in inventory windows. It is done by picking up stack of something (more than 1 items), then holding mouse button (left, right or middle) and dragging holded stack over empty (or same type in case of right button ) slots. In that case client sends the following to server after mouse button release (omitting first pickup packet which is sent as usual):<br />
<br />
# packet with mode 5, slot -999 , button (0 for left | 4 for right);<br />
# packet for every slot painted on, mode is still 5, button (1 | 5);<br />
# packet with mode 5, slot -999, button (2 | 6);<br />
<br />
If any of the painting packets other than the "progress" ones are sent out of order (for example, a start, some slots, then another start; or a left-click in the middle) the painting status will be reset.<br />
<br />
==== Confirm Transaction ====<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="3" | 0x0F<br />
| Window ID || Byte || The id of the window that the action occurred in.<br />
|-<br />
| Action number || Short || Every action that is to be accepted has a unique number. This field corresponds to that number.<br />
|-<br />
| Accepted || Bool || Whether the action was accepted.<br />
|}<br />
<br />
==== Creative Inventory Action ====<br />
<br />
While the user is in the standard inventory (i.e., not a crafting bench) on a creative-mode server then the server will send this packet:<br />
<br />
* If an item is dropped into the quick bar<br />
* If an item is picked up from the quick bar (item id is -1)<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="2" | 0x10<br />
| Slot || Short || Inventory slot<br />
|-<br />
| Clicked item || [[Slot_Data|Slot]] ||<br />
|}<br />
<br />
==== Enchant Item ====<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="2" | 0x11<br />
| Window ID || Byte || The ID sent by [[#0x64|Open Window]]<br />
|-<br />
| Enchantment || Byte || The position of the enchantment on the enchantment table window, starting with 0 as the topmost one.<br />
|}<br />
<br />
==== Update Sign ====<br />
<br />
This message is sent from the client to the server when the "Done" button is pushed after placing a sign. <br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="7" | 0x12<br />
| X || Int || Block X Coordinate<br />
|-<br />
| Y || Short || Block Y Coordinate<br />
|-<br />
| Z || Int || Block Z Coordinate<br />
|-<br />
| Line 1 || String || First line of text in the sign<br />
|-<br />
| Line 2 || String || Second line of text in the sign<br />
|-<br />
| Line 3 || String || Third line of text in the sign<br />
|-<br />
| Line 4 || String || Fourth line of text in the sign<br />
|}<br />
<br />
==== Player Abilities ====<br />
<br />
The latter 2 bytes are used to indicate the walking and flying speeds respectively, while the first byte is used to determine the value of 4 booleans.<br />
<br />
The flags are whether damage is disabled (god mode, 8, bit 3), whether the player can fly (4, bit 2), whether the player is flying (2, bit 1), and whether the player is in creative mode (1, bit 0).<br />
<br />
To get the values of these booleans, simply AND (&) the byte with 1,2,4 and 8 respectively, to get the 0 or 1 bitwise value. To set them OR (|) them with their repspective masks.<br />
The vanilla client sends this packet when the player starts/stops flying with the second parameter changed accordingly. All other parameters are ignored by the vanilla server.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="3" | 0x13<br />
| Flags || Byte ||<br />
|-<br />
| Flying speed || Float|| previous integer value divided by 250<br />
|-<br />
| Walking speed || Float || previous integer value divided by 250<br />
|}<br />
<br />
==== Tab-Complete ====<br />
<br />
Sent when the user presses [tab] while writing text. The payload contains all text behind the cursor.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| 0x14 <br />
| Text || String ||<br />
|}<br />
<br />
==== Client Settings ====<br />
<br />
Sent when the player connects, or when settings are changed.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="6" | 0x15<br />
| Locale || String || en_GB<br />
|-<br />
| View distance || Byte || 0-3 for 'far', 'normal', 'short', 'tiny'.<br />
|-<br />
| Chat flags || Byte || Chat settings. See notes below.<br />
|-<br />
| Chat colours || Bool || "Colours" multiplayer setting<br />
|-<br />
| Difficulty || Byte || Client-side difficulty from options.txt<br />
|-<br />
| Show Cape || Bool || Client-side "show cape" option<br />
|}<br />
<br />
Chat flags has several values packed into one byte.<br />
<br />
'''Chat Enabled:''' Bits 0-1. 00: Enabled. 01: Commands only. 10: Hidden.<br />
<br />
==== Client Status ====<br />
<br />
Sent when the client is ready to complete login and when the client is ready to respawn after death.<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=1 | 0x16<br />
| Action ID || Byte || See below<br />
|}<br />
<br />
Action ID values:<br />
{| class="wikitable"<br />
|-<br />
! Action ID !! Name<br />
|-<br />
| 0 || Perform respawn<br />
|-<br />
| 1 || Request stats<br />
|-<br />
| 2 || Open inventory achievement<br />
|}<br />
<br />
==== Plugin Message ====<br />
<br />
Mods and plugins can use this to send their data. Minecraft itself uses a number of [[plugin channel]]s. These internal channels are prefixed with <code>MC|</code>.<br />
<br />
More documentation on this: http://dinnerbone.com/blog/2012/01/13/minecraft-plugin-channels-messaging/<br />
<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan="3" | 0x17<br />
| Channel || String || Name of the "channel" used to send the data.<br />
|-<br />
| Length || Short || Length of the following byte array<br />
|-<br />
| Data || Byte Array || Any data.<br />
|}<br />
<br />
== Status ==<br />
The status ping works as follows. <br />
C->S : Handshake State=1<br />
C->S : Request<br />
S->C : Response<br />
C->S : Ping<br />
S->C : Ping<br />
<br />
=== Clientbound ===<br />
<br />
==== Response ====<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=1 | 0x00 <br />
| JSON Response || String || https://gist.github.com/thinkofdeath/6927216<br />
|}<br />
<br />
<br />
==== Ping ====<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=1 | 0x01 <br />
| Time || Long || Should be the same as sent by the client<br />
|}<br />
<br />
=== Serverbound ===<br />
<br />
==== Request ====<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=1 | 0x00 || || ||<br />
|}<br />
<br />
<br />
==== Ping ====<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=1 | 0x01 <br />
| Time || Long ||<br />
|}<br />
<br />
== Login ==<br />
<br />
The login process is as follows:<br />
C->S : Handshake State=2<br />
C->S : Login Start<br />
S->C : Encryption Key Request<br />
(Client Auth)<br />
C->S : Encryption Key Response<br />
(Server Auth, Both enable encryption)<br />
S->C : Login Success<br />
<br />
For unauthenticated and* localhost connections there is no encryption.<br />
In that case Login Start is directly followed by Login Success.<br />
<br />
<nowiki>*</nowiki> It could be that only one of the two conditions is enough for an unencrypted connection.<br />
<br />
See [[Protocol Encryption]] for details.<br />
<br />
=== Clientbound ===<br />
<br />
==== Disconnect ====<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=1 | 0x00<br />
| JSON Data || String ||<br />
|}<br />
<br />
==== Encryption Request ====<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=5 | 0x01 <br />
| Server ID || String ||<br />
|-<br />
| Length || Short || length of public key<br />
|-<br />
| Public Key || Byte array || <br />
|-<br />
| Length || Short || length of verify token<br />
|-<br />
| Verify Token || Byte array || <br />
|- <br />
|}<br />
<br />
See [[Protocol Encryption]] for details.<br />
<br />
==== Login Success ====<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=2 | 0x02<br />
| UUID || String ||<br />
|-<br />
| Username || String ||<br />
|}<br />
<br />
=== Serverbound ===<br />
<br />
==== Login Start ====<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=1 | 0x00<br />
| Name || String || <br />
|}<br />
<br />
==== Encryption Response ====<br />
{| class="wikitable"<br />
! Packet ID !! Field Name !! Field Type !! Notes<br />
|-<br />
| rowspan=4 | 0x01 <br />
| Length || Short || length of public key<br />
|-<br />
| Shared Secret || Byte array || <br />
|-<br />
| Length || Short || length of verify token<br />
|-<br />
| Verify Token || Byte array ||<br />
|- <br />
|}<br />
<br />
See [[Protocol Encryption]] for details.<br />
<br />
== See Also ==<br />
* [[Data Types]]<br />
* [[Protocol History]]<br />
* [[Units of Measurement]]<br />
<br />
[[Category:Protocol Details]]<br />
[[Category:Minecraft Modern]]</div>Aragas