People very, very often have questions regarding the Minecraft Modern Protocol, so we'll try to address some of the most common ones on this document. If you're still having trouble, join us on IRC, channel #mcdevs on irc.libera.chat.
- 1 Is the protocol documentation complete?
- 2 What's the normal login sequence for a client?
- 3 What does the normal status ping sequence look like?
- 4 Offline mode
- 5 I think I've done everything right, but…
- 5.1 …my player isn't spawning!
- 5.2 …my client isn't receiving complete map chunks!
- 5.3 …all connecting clients spasm and jerk uncontrollably!
- 5.4 …the client is trying to send an invalid packet that begins with 0xFE01
- 5.5 …the client disconnects after some time with a "Timed out" error
- 5.6 ...my client isn't sending a Login Start packet!
- 6 How do I open/save a command block?
Is the protocol documentation complete?
Depending on your definition, yes! All packet types are known and their layout documented. Some finer details are missing, but everything you need to make functional programs is present. We also collect information on the pre-release protocol changes, allowing us to quickly document new releases.
What's the normal login sequence for a client?
See Authentication for communication with Mojang's servers.
The recommended login sequence looks like this, where C is the client and S is the server:
- Client connects to server
- C→S: Handshake State=2
- C→S: Login Start
- S→C: Encryption Request
- Client auth
- C→S: Encryption Response
- Server auth, both enable encryption
- S → C: Set Compression (Optional, enables compression)
- S → C: Login Success
- S → C: Join Game
- S → C: Plugin Message:
minecraft:brandwith the server's brand (Optional)
- S → C: Server Difficulty (Optional)
- S → C: Player Abilities (Optional)
- C → S: Plugin Message:
minecraft:brandwith the client's brand (Optional)
- C → S: Client Settings
- S → C: Held Item Change
- S → C: Declare Recipes
- S → C: Tags
- S → C: Entity Status (for the ; see Entity statuses#Player)
- S → C: Declare Commands
- S → C: Unlock Recipes
- S → C: Player Position And Look
- S → C: Player Info (Add Player action)
- S → C: Player Info (Update latency action)
- S → C: Update View Position
- S → C: Update Light (One sent for each chunk in a square centered on the player's position)
- S → C: Chunk Data And Update Light (One sent for each chunk in a square centered on the player's position)
- S → C: World Border (Once the world is finished loading)
- S → C: Spawn Position (“home” spawn, not where the client will spawn on login)
- S → C: Player Position And Look (Required, tells the client they're ready to spawn)
- C → S: Teleport Confirm
- C → S: Player Position And Look (to confirm the spawn position)
- C → S: Client Status (sent either before or while receiving chunks, further testing needed, server handles correctly if not sent)
- S → C: inventory, entities, etc
What does the normal status ping sequence look like?
When a Notchian client and server exchange information in a status ping, the exchange of packets will be as follows:
- C → S: Handshake with Next State set to 1 (Status)
- Client and Server set protocol state to Status.
- C → S: Request
- S → C: Response
- C → S: Ping
- S → C: Pong
- S → ❌: Server terminates connection to client
(Note that C is the Notchian client and S is the Notchian server).
If the server is in offline mode, it will not send the Encryption Request packet, and likewise, the client should not send Encryption Response. In this case, encryption is never enabled, and no authentication is performed.
I think I've done everything right, but…
…my player isn't spawning!
Note that if the following steps are taken, a Minecraft client will spawn the player:
- Do Handshake (see Protocol Encryption)
- Send Spawn Position packet
- Send Player Position And Look (clientbound) packet
While the above steps are sufficient for Minecraft 1.4.5, it is good form to send packets that inform the client about the world around the player before allowing the player to spawn.
…my client isn't receiving complete map chunks!
Main article: How to Write a Client
…all connecting clients spasm and jerk uncontrollably!
For newer clients, your server needs to send 49 chunks ahead of time, not just one. Send a 7×7 square of chunks, centered on the connecting client's position, before spawning them.
…the client is trying to send an invalid packet that begins with 0xFE01
…the client disconnects after some time with a "Timed out" error
The server is expected to send a Keep Alive packet every 1-15 seconds (if the server does not send a keep alive within 20 seconds of state change to Play, the client will disconnect from the server for Timed Out), and the client should respond with the serverbound version of that packet. If either party does not receive keep alives for some period of time, they will disconnect.
...my client isn't sending a Login Start packet!
By default, the Notchian server and client may group packets depending on if Nagle's TCP algorithm is enabled - the primary objective of Nagle's algorithm is to reduce the total number of packets needed to be sent over the network, increasing the efficiency. Nagle's algorithm is achieved by delaying each TCP packet to check if there are any more that are about to be sent to group them. You may not see a Login Start packet as you may not have parsed anything past the packet's length, because of this, you'll need to separate packets based off of the packet length.
How do I open/save a command block?
The process to actually open the command block window clientside is somewhat complex; the client actually uses the Update Block Entity (0x09) packet to open it.
First, the client must have at least an Entity Status packet)of 2, or else the client will refuse to open the command block. (The op permission level is set with the
To actually open the command block:
- C→S: Player Block Placement (0x1C), with the position being the command block that was right-clicked.
- S→C: Update Block Entity (0x09), with the NBT of the command block.
And to save it, use the
MC|AutoCmd plugin channel.