This page documents the changes from the [[Protocol|last stable Minecraft release]] (currently [[Protocol version numbers|1.14.4, protocol 498]]) to the current pre-release (currently [[Protocol version numbers|19w41a, protocol 558]]). Note that this page contains bleeding-edge information that may not be completely or correctly documented.

+

This page documents the changes from the [[Protocol|last stable Minecraft release]] (currently [[Protocol version numbers|1.14.4, protocol 498]]) to the current pre-release (currently [[Protocol version numbers|19w42a, protocol 559]]). Note that this page contains bleeding-edge information that may not be completely or correctly documented.

One who wishes to commandeer the merging of this into [[Protocol]] when an update is made must be sure to respect any changes that may have occurred to the respective packets there.

One who wishes to commandeer the merging of this into [[Protocol]] when an update is made must be sure to respect any changes that may have occurred to the respective packets there.

Spawn Player

This packet is sent by the server when a player comes into visible range, not when a player joins.

This packet must be sent after the Player Info packet that adds the player data for the client to use when spawning a player. If the Player Info for the player spawned by this packet is not present when this packet arrives, Notchian clients will not spawn the player entity. The Player Info packet includes skin/cape data.

Servers can, however, safely spawn player entities for players not in visible range. The client appears to handle it correctly.

Data to set. May be a TAG_END (0), in which case the block entity at the given location is removed (though this is not required since the client will remove the block entity automatically on chunk unload or block removal)

Chunk Data

How do biomes work now? The biome change happened at the same time as the seed change, but it's not clear how/if biomes could be computed given that it's not the actual seed...

The server only sends skylight information for chunk pillars in the Overworld, it's up to the client to know in which dimenison the player is currently located. You can also infer this information from the primary bitmask and the amount of uncompressed bytes sent. This packet also sends all block entities in the chunk (though sending them is not required; it is still legal to send them with Update Block Entity later).

Compound containing one long array named MOTION_BLOCKING, which is a heightmap for the highest solid block at each position in the chunk (as a compacted long array with 256 entries at 9 bits per entry totaling 36 longs). The Notchian server also adds a WORLD_SURFACE long array, the purpose of which is unknown, but it's not required for the chunk to be accepted.

Biomes

Optional array of Integer

1024 biome IDs, ordered by x then z then d, in 4×4×4 blocks. Not present if full chunk is false.

If true, a Notchian client shows reduced information on the debug screen. For servers in development, this should almost always be false.

Unknown

Boolean

Added

Respawn

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.

Avoid changing player's dimension to same dimension they were already in unless they are dead. If you change the dimension to one they are already in, weird bugs can occur, such as the player being unable to attack other players in new world (until they die and respawn).

If you must respawn a player in the same dimension without killing them, send two respawn packets, one to a different world and then another to the world you want. You do not need to complete the first respawn; it only matters that you send two packets.

Serverbound

No changes so far.

Handshaking

Clientbound

There are no clientbound packets in the Handshaking state, since the protocol immediately switches to a different state after the client sends the first packet.

Hostname or IP, e.g. localhost or 127.0.0.1, that was used to connect. The Notchian server does not use this information. Note that SRV records are a complete redirect, e.g. if _minecraft._tcp.example.com points to mc.example.org, users connecting to example.com will provide mc.example.org as server address in addition to connecting to it.