Difference between revisions of "Pre-release protocol"

From wiki.vg
Jump to navigation Jump to search
(Rough draft of the new configuration packets)
(Rough draft of the other packet changes)
Line 19: Line 19:
 
  !colspan="2"| Documentation
 
  !colspan="2"| Documentation
 
  |-
 
  |-
 +
!colspan="4"| Login clientbound
 +
{{PacketList|0x02|Login Success}}
 +
|-
 +
!colspan="4"| Login serverbound
 +
{{PacketList|0x00|Login Start}}
 +
{{PacketList|0x03|Login Acknowledged|rel=added}}
 +
|-
 
!colspan="4"| Configuration clientbound
 
!colspan="4"| Configuration clientbound
 
{{PacketList|0x00|Plugin Message (configuration)|rel=added}}
 
{{PacketList|0x00|Plugin Message (configuration)|rel=added}}
Line 36: Line 43:
 
{{PacketList|0x03|Pong (configuration)|rel=added}}
 
{{PacketList|0x03|Pong (configuration)|rel=added}}
 
{{PacketList|0x04|Resource Pack|rel=added}}
 
{{PacketList|0x04|Resource Pack|rel=added}}
 +
|-
 +
!colspan="4"| Play clientbound
 +
{{PacketList|0x0D|Chunk Batch Finished|rel=added}}
 +
{{PacketList|0x0E|Chunk Batch Start|rel=added}}
 +
{{PacketList|{{change|0x28|0x2A}}|Login (play)}}
 +
{{PacketList|{{change|0x41|0x43}}|Respawn}}
 +
{{PacketList|{{change|0x51|0x53}}|Display Objective}}
 +
{{PacketList|0x65|Start Configuration|rel=added}}
 +
{{PacketList|0x68|Feature Flags|pre=removed}}
 +
|-
 +
!colspan="4"| Play serverbound
 +
{{PacketList|0x08|Chunk Batch Received|rel=added}}
 +
{{PacketList|0x0B|Configuration Acknowledged|rel=added}}
 
|}
 
|}
  
Line 66: Line 86:
 
=== Clientbound ===
 
=== Clientbound ===
  
−
No changes so far.
+
 
 +
==== Chunk Batch Finished ====
 +
 
 +
{{Need Info|Why does the formula uses <code>25</code> instead of the normal tick duration of <code>50</code>?}}
 +
 
 +
Marks the end of a chunk batch. The Notchian client marks the time it receives this packet and calculates the ellapsed duration since the [[#Chunk Batch Start|beggining of the chunk batch]]. The server uses this duration and the batch size received in this packet to estimate the number of milliseconds ellapsed per chunk received. This value is then used to calculate the desired number of chunks per tick through the formula <code>25 / millisPerChunk</code>, which is reported to the server through [[#Chunk Batch Received|Chunk Batch Received]].
 +
 
 +
The Notchian client uses the samples from the latest 15 batches to estimate the chunks per millisecond number.
 +
 
 +
{| class="wikitable" {{added}}
 +
! Packet ID
 +
! State
 +
! Bound To
 +
! Field Name
 +
! Field Type
 +
! Notes
 +
|-
 +
| rowspan="1"| 0x0D
 +
| rowspan="1"| Play
 +
| rowspan="1"| Client
 +
| Batch size
 +
| VarInt
 +
| Number of chunks.
 +
|}
 +
 
 +
==== Chunk Batch Start ====
 +
 
 +
Marks the start of a chunk batch. The Notchian client marks and stores the time it receives this packet.
 +
 
 +
{| class="wikitable" {{added}}
 +
! Packet ID
 +
! State
 +
! Bound To
 +
! Field Name
 +
! Field Type
 +
! Notes
 +
|-
 +
| 0x0E
 +
| Play
 +
| Client
 +
| colspan="3"| ''no fields''
 +
|}
 +
 
 +
==== Login (play) ====
 +
 
 +
{{Need Info|Although the number of portal cooldown ticks is included in this packet, the whole portal usage process is still dictated entirely by the server. What kind of effect does this value have on the client, if any?}}
 +
 
 +
See [[Protocol Encryption]] for information on logging in.
 +
 
 +
{| class="wikitable"
 +
! Packet ID
 +
! State
 +
! Bound To
 +
! Field Name
 +
! Field Type
 +
! Notes
 +
|-
 +
| rowspan="26"| {{change|0x28|0x2A}}
 +
| rowspan="26"| Play
 +
| rowspan="26"| Client
 +
| Entity ID
 +
| Int
 +
| The player's Entity ID (EID).
 +
|-
 +
| Is hardcore
 +
| Boolean
 +
|
 +
|- {{removed}}
 +
| Game mode
 +
| Unsigned Byte
 +
| 0: Survival, 1: Creative, 2: Adventure, 3: Spectator.
 +
|- {{removed}}
 +
| Previous Game mode
 +
| Byte
 +
| -1: Undefined (null), 0: Survival, 1: Creative, 2: Adventure, 3: Spectator. The previous game mode. Vanilla client uses this for the debug (F3 + N & F3 + F4) game mode switch. (More information needed)
 +
|-
 +
| Dimension Count
 +
| VarInt
 +
| Size of the following array.
 +
|-
 +
| Dimension Names
 +
| Array of Identifier
 +
| Identifiers for all dimensions on the server.
 +
|- {{removed}}
 +
| Registry Codec
 +
| [[NBT|NBT Tag Compound]]
 +
| Represents certain registries that are sent from the server and are applied on the client.
 +
|- {{removed}}
 +
| Dimension Type
 +
| Identifier
 +
| Name of the dimension type being spawned into.
 +
|- {{removed}}
 +
| Dimension Name
 +
| Identifier
 +
| Name of the dimension being spawned into.
 +
|- {{removed}}
 +
| Hashed seed
 +
| Long
 +
| First 8 bytes of the SHA-256 hash of the world's seed. Used client side for biome noise
 +
|-
 +
| Max Players
 +
| VarInt
 +
| Was once used by the client to draw the player list, but now is ignored.
 +
|-
 +
| View Distance
 +
| VarInt
 +
| Render distance (2-32).
 +
|-
 +
| Simulation Distance
 +
| VarInt
 +
| The distance that the client will process specific things, such as entities.
 +
|-
 +
| Reduced Debug Info
 +
| Boolean
 +
| If true, a Notchian client shows reduced information on the {{Minecraft Wiki|debug screen}}.  For servers in development, this should almost always be false.
 +
|-
 +
| Enable respawn screen
 +
| Boolean
 +
| Set to false when the doImmediateRespawn gamerule is true.
 +
|- {{added}}
 +
| Dimension Type
 +
| Identifier
 +
| Name of the dimension type being spawned into.
 +
|- {{added}}
 +
| Dimension Name
 +
| Identifier
 +
| Name of the dimension being spawned into.
 +
|- {{added}}
 +
| Hashed seed
 +
| Long
 +
| First 8 bytes of the SHA-256 hash of the world's seed. Used client side for biome noise
 +
|- {{added}}
 +
| Game mode
 +
| Unsigned Byte
 +
| 0: Survival, 1: Creative, 2: Adventure, 3: Spectator.
 +
|- {{added}}
 +
| Previous Game mode
 +
| Byte
 +
| -1: Undefined (null), 0: Survival, 1: Creative, 2: Adventure, 3: Spectator. The previous game mode. Vanilla client uses this for the debug (F3 + N & F3 + F4) game mode switch. (More information needed)
 +
|-
 +
| Is Debug
 +
| Boolean
 +
| True if the world is a {{Minecraft Wiki|debug mode}} world; debug mode worlds cannot be modified and have predefined blocks.
 +
|-
 +
| Is Flat
 +
| Boolean
 +
| True if the world is a {{Minecraft Wiki|superflat}} world; flat worlds have different void fog and a horizon at y=0 instead of y=63.
 +
|-
 +
| Has death location
 +
| Boolean
 +
| If true, then the next two fields are present.
 +
|-
 +
| Death dimension name
 +
| Optional Identifier
 +
| Name of the dimension the player died in.
 +
|-
 +
| Death location
 +
| Optional Position
 +
| The location that the player died at.
 +
|-
 +
| Portal cooldown
 +
| VarInt
 +
| The number of ticks until the player can use the portal again.
 +
|}
 +
 
 +
==== Respawn ====
 +
 
 +
{{Need Info|Although the number of portal cooldown ticks is included in this packet, the whole portal usage process is still dictated entirely by the server. What kind of effect does this value have on the client, if any?}}
 +
 
 +
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.
 +
 
 +
{| class="wikitable"
 +
! Packet ID
 +
! State
 +
! Bound To
 +
! Field Name
 +
! Field Type
 +
! Notes
 +
|-
 +
| rowspan="12"| {{change|0x41|0x43}}
 +
| rowspan="12"| Play
 +
| rowspan="12"| Client
 +
| Dimension Type
 +
| Identifier
 +
| Valid dimensions are defined per dimension registry sent in [[#Login (play)|Login (play)]]
 +
|-
 +
| Dimension Name
 +
| Identifier
 +
| Name of the dimension being spawned into.
 +
|-
 +
| Hashed seed
 +
| Long
 +
| First 8 bytes of the SHA-256 hash of the world's seed. Used client side for biome noise
 +
|-
 +
| Game mode
 +
| Unsigned Byte
 +
| 0: Survival, 1: Creative, 2: Adventure, 3: Spectator.
 +
|-
 +
| Previous Game mode
 +
| Byte
 +
| -1: Undefined (null), 0: Survival, 1: Creative, 2: Adventure, 3: Spectator. The previous game mode. Vanilla client uses this for the debug (F3 + N & F3 + F4) game mode switch. (More information needed)
 +
|-
 +
| Is Debug
 +
| Boolean
 +
| True if the world is a {{Minecraft Wiki|debug mode}} world; debug mode worlds cannot be modified and have predefined blocks.
 +
|-
 +
| Is Flat
 +
| Boolean
 +
| True if the world is a {{Minecraft Wiki|superflat}} world; flat worlds have different void fog and a horizon at y=0 instead of y=63.
 +
|- {{removed}}
 +
| Data kept
 +
| Byte
 +
| Bit mask. 0x01: Keep attributes, 0x02: Keep metadata. Tells which data should be kept on the client side once the player has respawned.
 +
In the Notchian implementation, this is context dependent:
 +
* normal respawns (after death) keep no data;
 +
* exiting the end poem/credits keeps the attributes;
 +
* other dimension changes (portals or teleports) keep all data.
 +
|-
 +
| Has death location
 +
| Boolean
 +
| If true, then the next two fields are present.
 +
|-
 +
| Death dimension Name
 +
| Optional Identifier
 +
| Name of the dimension the player died in.
 +
|-
 +
| Death location
 +
| Optional Position
 +
| The location that the player died at.
 +
|-
 +
| Portal cooldown
 +
| VarInt
 +
| The number of ticks until the player can use the portal again.
 +
|}
 +
 
 +
{{Warning2|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).
 +
 
 +
Before 1.16, 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.}}
 +
 
 +
==== Display Objective ====
 +
 
 +
This is sent to the client when it should display a scoreboard.
 +
 
 +
{| class="wikitable"
 +
! Packet ID
 +
! State
 +
! Bound To
 +
! Field Name
 +
! Field Type
 +
! Notes
 +
|-
 +
| rowspan="2"| {{change|0x51|0x53}}
 +
| rowspan="2"| Play
 +
| rowspan="2"| Client
 +
| Position
 +
| {{change|Byte|VarInt}}
 +
| The position of the scoreboard. 0: list, 1: sidebar, 2: below name, 3 - 18: team specific sidebar, indexed as 3 + team color.
 +
|-
 +
| Score Name
 +
| String {{change|(16)|}}
 +
| The unique name for the scoreboard to be displayed.
 +
|}
 +
 
 +
==== Start Configuration ====
 +
 
 +
Sent during gameplay in order to redo the configuration process. The client must respond with [[#Configuration Acknowledged|Configuration Acknowledged]] for the process to start.
 +
 
 +
{| class="wikitable" {{added}}
 +
! Packet ID
 +
! State
 +
! Bound To
 +
! Field Name
 +
! Field Type
 +
! Notes
 +
|-
 +
| rowspan="1"| 0x65
 +
| rowspan="1"| Play
 +
| rowspan="1"| Client
 +
| colspan="3"| ''no fields''
 +
|}
 +
 
 +
This packet switches the connection state to [[#Configuration|configuration]].
 +
 
 +
==== Feature Flags ====
 +
 
 +
Used to enable and disable features, generally experimental ones, on the client.
 +
 
 +
{| class="wikitable" {{removed}}
 +
! Packet ID
 +
! State
 +
! Bound To
 +
! Field Name
 +
! Field Type
 +
! Notes
 +
|-
 +
| rowspan="2"| 0x6B
 +
| rowspan="2"| Play
 +
| rowspan="2"| Client
 +
| Total Features
 +
| VarInt
 +
| Number of features that appear in the array below.
 +
|-
 +
| Feature Flags
 +
| Identifier Array
 +
|
 +
|}
  
 
=== Serverbound ===
 
=== Serverbound ===
  
−
No changes so far.
+
==== Chunk Batch Received ====
 +
 
 +
Notifies the server that the chunk batch has been received by the client. The server uses the value sent in this packet to adjust the number of chunks to be sent in a batch.
 +
 
 +
The Notchian server will begin by stopping to send more chunk data until the client acknowledges one chunk batch. After the first acknowledgement, the number increases to 10 batches.
 +
 
 +
{| class="wikitable" {{added}}
 +
! Packet ID
 +
! State
 +
! Bound To
 +
! Field Name
 +
! Field Type
 +
! Notes
 +
|-
 +
| rowspan="1"| 0x07
 +
| rowspan="1"| Play
 +
| rowspan="1"| Server
 +
| Chunks per tick
 +
| Float
 +
| Desired chunks per tick.
 +
|}
 +
 
 +
==== Configuration Acknowledged ====
 +
 
 +
Sent by the client upon received a [[#Start Configuration|Start Configuration]] packet from the server.
 +
 
 +
{| class="wikitable" {{added}}
 +
! Packet ID
 +
! State
 +
! Bound To
 +
! Field Name
 +
! Field Type
 +
! Notes
 +
|-
 +
| rowspan="1"| 0x0B
 +
| rowspan="1"| Play
 +
| rowspan="1"| Server
 +
| colspan="3"| ''no fields''
 +
|}
 +
 
 +
This packet switches the connection state to [[#Configuration|configuration]].
  
 
== Status ==
 
== Status ==
Line 86: Line 451:
 
=== Clientbound ===
 
=== Clientbound ===
  
−
No changes so far.
+
==== Login Success ====
 +
 
 +
{| class="wikitable"
 +
! Packet ID
 +
! State
 +
! Bound To
 +
! colspan="2"| Field Name
 +
! colspan="2"| Field Type
 +
! Notes
 +
|-
 +
| rowspan="7"| 0x02
 +
| rowspan="7"| Login
 +
| rowspan="7"| Client
 +
| colspan="2"| UUID
 +
| colspan="2"| UUID
 +
| colspan="2"|
 +
|-
 +
| colspan="2"| Username
 +
| colspan="2"| String (16)
 +
| colspan="2"|
 +
|-
 +
| colspan="2"| Number Of Properties
 +
| colspan="2"| VarInt
 +
| Number of elements in the following array.
 +
|-
 +
| rowspan="4"| Property
 +
| Name
 +
| rowspan="4"| Array
 +
| String (32767)
 +
| colspan="2"|
 +
|-
 +
| Value
 +
| String (32767)
 +
| colspan="1"|
 +
|-
 +
| Is Signed
 +
| Boolean
 +
| colspan="2"|
 +
|-
 +
| Signature
 +
| Optional String (32767)
 +
| Only if Is Signed is true.
 +
|}
 +
 
 +
This packet switches the connection state to {{change|[[#Play|play]]|[[#Configuration|configuration]]}}.
  
 
=== Serverbound ===
 
=== Serverbound ===
  
−
No changes so far.
+
==== Login Start  ====
 +
 
 +
{| class="wikitable"
 +
! Packet ID
 +
! State
 +
! Bound To
 +
! Field Name
 +
! Field Type
 +
! Notes
 +
|-
 +
| rowspan="3"| 0x00
 +
| rowspan="3"| Login
 +
| rowspan="3"| Server
 +
| Name
 +
| String (16)
 +
| Player's Username.
 +
|- {{removed}}
 +
| Has Player UUID
 +
| Boolean
 +
| Whether or not the next field should be sent.
 +
|-
 +
| Player UUID
 +
| {{change|Optional}} UUID
 +
| The UUID of the player logging in. {{change|Only sent if Has Player UUID is true.}}
 +
|}
 +
 
 +
==== Login Acknowledged ====
 +
 
 +
Acknowledgement to the [[Protocol#Login_Success|Login Success]] packet sent by the server.
 +
 
 +
{| class="wikitable" {{added}}
 +
! Packet ID
 +
! State
 +
! Bound To
 +
! Field Name
 +
! Field Type
 +
! Notes
 +
|-
 +
| 0x03
 +
| Login
 +
| Server
 +
| colspan="3"| ''no fields''
 +
|}
  
 
== Configuration ==
 
== Configuration ==
Line 106: Line 557:
 
Note that the length of Data is known only from the packet length, since the packet has no length field of any kind.
 
Note that the length of Data is known only from the packet length, since the packet has no length field of any kind.
  
−
{| class="wikitable"
+
{| class="wikitable" {{added}}
 
  ! Packet ID
 
  ! Packet ID
 
  ! State
 
  ! State
Line 130: Line 581:
 
==== Disconnect (configuration) ====
 
==== Disconnect (configuration) ====
  
−
{| class="wikitable"
+
{| class="wikitable" {{added}}
 
  ! Packet ID
 
  ! Packet ID
 
  ! State
 
  ! State
Line 150: Line 601:
 
Sent by the server to notify the client that all the configuration has finish. The client answers with its own [[#Finish_Configuration_2|Finish Configuration]] whenever it is ready to continue.
 
Sent by the server to notify the client that all the configuration has finish. The client answers with its own [[#Finish_Configuration_2|Finish Configuration]] whenever it is ready to continue.
  
−
{| class="wikitable"
+
{| class="wikitable" {{added}}
 
  ! Packet ID
 
  ! Packet ID
 
  ! State
 
  ! State
Line 163: Line 614:
 
  | colspan="3"| ''no fields''
 
  | colspan="3"| ''no fields''
 
  |}
 
  |}
 +
 +
This packet switches the connection state to [[#Play|play]].
  
 
==== Keep Alive (configuration) ====
 
==== Keep Alive (configuration) ====
Line 170: Line 623:
 
The Notchian server uses a system-dependent time in milliseconds to generate the keep alive ID value.
 
The Notchian server uses a system-dependent time in milliseconds to generate the keep alive ID value.
  
−
{| class="wikitable"
+
{| class="wikitable" {{added}}
 
  ! Packet ID
 
  ! Packet ID
 
  ! State
 
  ! State
Line 190: Line 643:
 
Packet is not used by the Notchian server. When sent to the client, client responds with a [[#Pong (configuration)|Pong]] packet with the same id.
 
Packet is not used by the Notchian server. When sent to the client, client responds with a [[#Pong (configuration)|Pong]] packet with the same id.
  
−
{| class="wikitable"
+
{| class="wikitable" {{added}}
 
  ! Packet ID
 
  ! Packet ID
 
  ! State
 
  ! State
Line 210: Line 663:
 
Represents certain registries that are sent from the server and are applied on the client.
 
Represents certain registries that are sent from the server and are applied on the client.
  
−
{| class="wikitable"
+
{| class="wikitable" {{added}}
 
  ! Packet ID
 
  ! Packet ID
 
  ! State
 
  ! State
Line 590: Line 1,043:
 
==== Resource Pack ====
 
==== Resource Pack ====
  
−
{| class="wikitable"
+
{| class="wikitable" {{added}}
 
  ! Packet ID
 
  ! Packet ID
 
  ! State
 
  ! State
Line 626: Line 1,079:
 
Used to enable and disable features, generally experimental ones, on the client.
 
Used to enable and disable features, generally experimental ones, on the client.
  
−
{| class="wikitable"
+
{| class="wikitable" {{added}}
 
  ! Packet ID
 
  ! Packet ID
 
  ! State
 
  ! State
Line 654: Line 1,107:
 
==== Update Tags ====
 
==== Update Tags ====
  
−
{| class="wikitable"
+
{| class="wikitable" {{added}}
 
  ! Packet ID
 
  ! Packet ID
 
  ! State
 
  ! State
Line 723: Line 1,176:
 
Note that the length of Data is known only from the packet length, since the packet has no length field of any kind.
 
Note that the length of Data is known only from the packet length, since the packet has no length field of any kind.
  
−
{| class="wikitable"
+
{| class="wikitable" {{added}}
 
  ! Packet ID
 
  ! Packet ID
 
  ! State
 
  ! State
Line 749: Line 1,202:
 
Sent by the client to notify the client that all the configuration has finished. It is sent after the server sends its own [[#Finish_Configuration|Finish Configuration]].
 
Sent by the client to notify the client that all the configuration has finished. It is sent after the server sends its own [[#Finish_Configuration|Finish Configuration]].
  
−
{| class="wikitable"
+
{| class="wikitable" {{added}}
 
  ! Packet ID
 
  ! Packet ID
 
  ! State
 
  ! State
Line 762: Line 1,215:
 
  | colspan="3"| ''no fields''
 
  | colspan="3"| ''no fields''
 
  |}
 
  |}
 +
 +
This packet switches the connection state to [[#Play|play]].
  
 
==== Keep Alive (configuration) ====
 
==== Keep Alive (configuration) ====
Line 767: Line 1,222:
 
The server will frequently send out a keep-alive (see [[#Keep Alive (configuration)|clientbound Keep Alive]]), each containing a random ID. The client must respond with the same packet.
 
The server will frequently send out a keep-alive (see [[#Keep Alive (configuration)|clientbound Keep Alive]]), each containing a random ID. The client must respond with the same packet.
  
−
{| class="wikitable"
+
{| class="wikitable" {{added}}
 
  ! Packet ID
 
  ! Packet ID
 
  ! State
 
  ! State
Line 787: Line 1,242:
 
Response to the clientbound packet ([[#Ping (configuration)|Ping]]) with the same id.
 
Response to the clientbound packet ([[#Ping (configuration)|Ping]]) with the same id.
  
−
{| class="wikitable"
+
{| class="wikitable" {{added}}
 
  ! Packet ID
 
  ! Packet ID
 
  ! State
 
  ! State
Line 803: Line 1,258:
 
  |}
 
  |}
  
−
==== Resource Pack ====
+
==== Resource Pack (configuration) ====
  
−
{| class="wikitable"
+
{| class="wikitable" {{added}}
 
  ! Packet ID
 
  ! Packet ID
 
  ! State
 
  ! State

Revision as of 02:23, 3 August 2023

This page documents the changes from the last stable Minecraft release (currently 1.20.1, protocol 763) to the current pre-release (currently 23w31a, protocol Snapshot 144). 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.

Contents

Data types

No changes so far.

Packets

Packets

ID Packet name Documentation
Login clientbound
0x02 Login Success Current Pre
Login serverbound
0x00 Login Start Current Pre
0x03 Login Acknowledged Pre
Configuration clientbound
0x00 Plugin Message (configuration) Pre
0x01 Disconnect (configuration) Pre
0x02 Finish Configuration Pre
0x03 Keep Alive (configuration) Pre
0x04 Ping (configuration) Pre
0x05 Registry Data Pre
0x06 Resource Pack (configuration) Pre
0x07 Feature Flags Pre
0x08 Update Tags Pre
Configuration serverbound
0x00 Plugin Message (configuration) Pre
0x01 Finish Configuration Pre
0x02 Keep Alive (configuration) Pre
0x03 Pong (configuration) Pre
0x04 Resource Pack Pre
Play clientbound
0x0D Chunk Batch Finished Pre
0x0E Chunk Batch Start Pre
0x28 0x2A Login (play) Current Pre
0x41 0x43 Respawn Current Pre
0x51 0x53 Display Objective Current Pre
0x65 Start Configuration Pre
0x68 Feature Flags Current
Play serverbound
0x08 Chunk Batch Received Pre
0x0B Configuration Acknowledged Pre

New/modified data types

No changes so far.

Entity Metadata

No changes so far.

Entity

No changes so far.

Block Actions

No changes so far.

Inventories

No changes so far.

Plugin Channels

No changes so far.

Play

Clientbound

Chunk Batch Finished

Huh.png The following information needs to be added to this page:
Why does the formula uses 25 instead of the normal tick duration of 50?

Marks the end of a chunk batch. The Notchian client marks the time it receives this packet and calculates the ellapsed duration since the beggining of the chunk batch. The server uses this duration and the batch size received in this packet to estimate the number of milliseconds ellapsed per chunk received. This value is then used to calculate the desired number of chunks per tick through the formula 25 / millisPerChunk, which is reported to the server through Chunk Batch Received.

The Notchian client uses the samples from the latest 15 batches to estimate the chunks per millisecond number.

Packet ID State Bound To Field Name Field Type Notes
0x0D Play Client Batch size VarInt Number of chunks.

Chunk Batch Start

Marks the start of a chunk batch. The Notchian client marks and stores the time it receives this packet.

Packet ID State Bound To Field Name Field Type Notes
0x0E Play Client no fields

Login (play)

Huh.png The following information needs to be added to this page:
Although the number of portal cooldown ticks is included in this packet, the whole portal usage process is still dictated entirely by the server. What kind of effect does this value have on the client, if any?

See Protocol Encryption for information on logging in.

Packet ID State Bound To Field Name Field Type Notes
0x28 0x2A Play Client Entity ID Int The player's Entity ID (EID).
Is hardcore Boolean
Game mode Unsigned Byte 0: Survival, 1: Creative, 2: Adventure, 3: Spectator.
Previous Game mode Byte -1: Undefined (null), 0: Survival, 1: Creative, 2: Adventure, 3: Spectator. The previous game mode. Vanilla client uses this for the debug (F3 + N & F3 + F4) game mode switch. (More information needed)
Dimension Count VarInt Size of the following array.
Dimension Names Array of Identifier Identifiers for all dimensions on the server.
Registry Codec NBT Tag Compound Represents certain registries that are sent from the server and are applied on the client.
Dimension Type Identifier Name of the dimension type being spawned into.
Dimension Name Identifier Name of the dimension being spawned into.
Hashed seed Long First 8 bytes of the SHA-256 hash of the world's seed. Used client side for biome noise
Max Players VarInt Was once used by the client to draw the player list, but now is ignored.
View Distance VarInt Render distance (2-32).
Simulation Distance VarInt The distance that the client will process specific things, such as entities.
Reduced Debug Info Boolean If true, a Notchian client shows reduced information on the debug screen. For servers in development, this should almost always be false.
Enable respawn screen Boolean Set to false when the doImmediateRespawn gamerule is true.
Dimension Type Identifier Name of the dimension type being spawned into.
Dimension Name Identifier Name of the dimension being spawned into.
Hashed seed Long First 8 bytes of the SHA-256 hash of the world's seed. Used client side for biome noise
Game mode Unsigned Byte 0: Survival, 1: Creative, 2: Adventure, 3: Spectator.
Previous Game mode Byte -1: Undefined (null), 0: Survival, 1: Creative, 2: Adventure, 3: Spectator. The previous game mode. Vanilla client uses this for the debug (F3 + N & F3 + F4) game mode switch. (More information needed)
Is Debug Boolean True if the world is a debug mode world; debug mode worlds cannot be modified and have predefined blocks.
Is Flat Boolean True if the world is a superflat world; flat worlds have different void fog and a horizon at y=0 instead of y=63.
Has death location Boolean If true, then the next two fields are present.
Death dimension name Optional Identifier Name of the dimension the player died in.
Death location Optional Position The location that the player died at.
Portal cooldown VarInt The number of ticks until the player can use the portal again.

Respawn

Huh.png The following information needs to be added to this page:
Although the number of portal cooldown ticks is included in this packet, the whole portal usage process is still dictated entirely by the server. What kind of effect does this value have on the client, if any?

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.

Packet ID State Bound To Field Name Field Type Notes
0x41 0x43 Play Client Dimension Type Identifier Valid dimensions are defined per dimension registry sent in Login (play)
Dimension Name Identifier Name of the dimension being spawned into.
Hashed seed Long First 8 bytes of the SHA-256 hash of the world's seed. Used client side for biome noise
Game mode Unsigned Byte 0: Survival, 1: Creative, 2: Adventure, 3: Spectator.
Previous Game mode Byte -1: Undefined (null), 0: Survival, 1: Creative, 2: Adventure, 3: Spectator. The previous game mode. Vanilla client uses this for the debug (F3 + N & F3 + F4) game mode switch. (More information needed)
Is Debug Boolean True if the world is a debug mode world; debug mode worlds cannot be modified and have predefined blocks.
Is Flat Boolean True if the world is a superflat world; flat worlds have different void fog and a horizon at y=0 instead of y=63.
Data kept Byte Bit mask. 0x01: Keep attributes, 0x02: Keep metadata. Tells which data should be kept on the client side once the player has respawned.

In the Notchian implementation, this is context dependent:

  • normal respawns (after death) keep no data;
  • exiting the end poem/credits keeps the attributes;
  • other dimension changes (portals or teleports) keep all data.
Has death location Boolean If true, then the next two fields are present.
Death dimension Name Optional Identifier Name of the dimension the player died in.
Death location Optional Position The location that the player died at.
Portal cooldown VarInt The number of ticks until the player can use the portal again.

Warning.png 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).

Before 1.16, 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.

Display Objective

This is sent to the client when it should display a scoreboard.

Packet ID State Bound To Field Name Field Type Notes
0x51 0x53 Play Client Position Byte VarInt The position of the scoreboard. 0: list, 1: sidebar, 2: below name, 3 - 18: team specific sidebar, indexed as 3 + team color.
Score Name String (16) The unique name for the scoreboard to be displayed.

Start Configuration

Sent during gameplay in order to redo the configuration process. The client must respond with Configuration Acknowledged for the process to start.

Packet ID State Bound To Field Name Field Type Notes
0x65 Play Client no fields

This packet switches the connection state to configuration.

Feature Flags

Used to enable and disable features, generally experimental ones, on the client.

Packet ID State Bound To Field Name Field Type Notes
0x6B Play Client Total Features VarInt Number of features that appear in the array below.
Feature Flags Identifier Array

Serverbound

Chunk Batch Received

Notifies the server that the chunk batch has been received by the client. The server uses the value sent in this packet to adjust the number of chunks to be sent in a batch.

The Notchian server will begin by stopping to send more chunk data until the client acknowledges one chunk batch. After the first acknowledgement, the number increases to 10 batches.

Packet ID State Bound To Field Name Field Type Notes
0x07 Play Server Chunks per tick Float Desired chunks per tick.

Configuration Acknowledged

Sent by the client upon received a Start Configuration packet from the server.

Packet ID State Bound To Field Name Field Type Notes
0x0B Play Server no fields

This packet switches the connection state to configuration.

Status

Clientbound

No changes so far.

Serverbound

No changes so far.

Login

Clientbound

Login Success

Packet ID State Bound To Field Name Field Type Notes
0x02 Login Client UUID UUID
Username String (16)
Number Of Properties VarInt Number of elements in the following array.
Property Name Array String (32767)
Value String (32767)
Is Signed Boolean
Signature Optional String (32767) Only if Is Signed is true.

This packet switches the connection state to play configuration.

Serverbound

Login Start

Packet ID State Bound To Field Name Field Type Notes
0x00 Login Server Name String (16) Player's Username.
Has Player UUID Boolean Whether or not the next field should be sent.
Player UUID Optional UUID The UUID of the player logging in. Only sent if Has Player UUID is true.

Login Acknowledged

Acknowledgement to the Login Success packet sent by the server.

Packet ID State Bound To Field Name Field Type Notes
0x03 Login Server no fields

Configuration

Clientbound

Plugin Message (configuration)

Main article: Plugin channels

Mods and plugins can use this to send their data. Minecraft itself uses the minecraft:payload channel to send many types of payloads, which are documented here.

More documentation on this: https://dinnerbone.com/blog/2012/01/13/minecraft-plugin-channels-messaging/

Note that the length of Data is known only from the packet length, since the packet has no length field of any kind.

Packet ID State Bound To Field Name Field Type Notes
0x00 Configuration Client Channel Identifier Name of the plugin channel used to send the data.
Payload Byte Array (1048576) Any data, depending on the channel. minecraft:payload payloads are documented here. The length of this array must be inferred from the packet length.

In Notchian client, the maximum data length is 1048576 bytes.

Disconnect (configuration)

Packet ID State Bound To Field Name Field Type Notes
0x01 Configuration Client Reason Chat The reason why the player was disconnected.

Finish Configuration

Sent by the server to notify the client that all the configuration has finish. The client answers with its own Finish Configuration whenever it is ready to continue.

Packet ID State Bound To Field Name Field Type Notes
0x02 Configuration Client no fields

This packet switches the connection state to play.

Keep Alive (configuration)

The server will frequently send out a keep-alive, each containing a random ID. The client must respond with the same payload (see serverbound Keep Alive). If the client does not respond to them for over 30 seconds, the server kicks the client. Vice versa, if the server does not send any keep-alives for 20 seconds, the client will disconnect and yields a "Timed out" exception.

The Notchian server uses a system-dependent time in milliseconds to generate the keep alive ID value.

Packet ID State Bound To Field Name Field Type Notes
0x03 Configuration Client Keep Alive ID Long

Ping (configuration)

Packet is not used by the Notchian server. When sent to the client, client responds with a Pong packet with the same id.

Packet ID State Bound To Field Name Field Type Notes
0x04 Configuration Client ID Int

Registry Data

Represents certain registries that are sent from the server and are applied on the client.

Packet ID State Bound To Field Name Field Type Notes
0x05 Configuration Client Registry Codec NBT Tag Compound Information included below.


The Registry Codec NBT Tag Compound (Default value in JSON as of 1.19, 1.19.2, 1.20.1) includes three registries: "minecraft:dimension_type", "minecraft:worldgen/biome", and "minecraft:chat_type".

Name Type Notes
minecraft:dimension_type TAG_Compound The dimension type registry (see below).
minecraft:worldgen/biome TAG_Compound The biome registry (see below).
minecraft:chat_type TAG_Compound The chat type registry (see below).

Dimension type registry:

Name Type Notes
type TAG_String The name of the registry. Always "minecraft:dimension_type".
value TAG_List List of dimension types registry entries (see below).

Dimension type registry entry:

Name Type Notes
name TAG_String The name of the dimension type (for example, "minecraft:overworld").
id TAG_Int The protocol ID of the dimension (matches the index of the element in the registry list).
element TAG_Compound The dimension type (see below).

Dimension type:

Name Type Meaning Values
piglin_safe TAG_Byte Whether piglins shake and transform to zombified piglins. 1: true, 0: false.
has_raids TAG_Byte Whether players with the Bad Omen effect can cause a raid. 1: true, 0: false.
monster_spawn_light_level TAG_Int or TAG_Compound Possibly the light level(s) at which monsters can spawn. When TAG_Int, 0 - 15. When TAG_Compound, contains the fields: type (TAG_String), appears to be always "minecraft:uniform", and value (TAG_Compound), which contains the fields: max_inclusive (TAG_Int), min_inclusive (TAG_Int).
monster_spawn_block_light_limit TAG_Int
natural TAG_Byte When false, compasses spin randomly. When true, nether portals can spawn zombified piglins. 1: true, 0: false.
ambient_light TAG_Float How much light the dimension has. 0.0 to 1.0.
fixed_time Optional TAG_Long If set, the time of the day is the specified value. If set, 0 to 24000.
infiniburn TAG_String A resource location defining what block tag to use for infiniburn. "#" or minecraft resource "#minecraft:...".
respawn_anchor_works TAG_Byte Whether players can charge and use respawn anchors. 1: true, 0: false.
has_skylight TAG_Byte Whether the dimension has skylight access or not. 1: true, 0: false.
bed_works TAG_Byte Whether players can use a bed to sleep. 1: true, 0: false.
effects TAG_String ? "minecraft:overworld", "minecraft:the_nether", "minecraft:the_end" or something else.
min_y TAG_Int The minimum Y level. A multiple of 16. Example: -64
height TAG_Int The maximum height. A multiple of 16. Example: 256
logical_height TAG_Int The maximum height to which chorus fruits and nether portals can bring players within this dimension. (Must be lower than height) 0-384.
coordinate_scale TAG_Double The multiplier applied to coordinates when traveling to the dimension. 0.00001 - 30000000.0
ultrawarm TAG_Byte Whether the dimensions behaves like the nether (water evaporates and sponges dry) or not. Also causes lava to spread thinner. 1: true, 0: false.
has_ceiling TAG_Byte Whether the dimension has a bedrock ceiling or not. When true, causes lava to spread faster. 1: true, 0: false.

Biome registry:

Name Type Notes
type TAG_String The name of the registry. Always "minecraft:worldgen/biome".
value TAG_List List of biome registry entries (see below).

Biome registry entry:

Name Type Notes
name TAG_String The name of the biome (for example, "minecraft:ocean").
id TAG_Int The protocol ID of the biome (matches the index of the element in the registry list).
element TAG_Compound The biome properties (see below).

Biome properties:

Name Type Meaning Values
has_precipitation TAG_Byte Determines whether or not the biome has precipitation. 1: true, 0: false.
depth Optional TAG_Float The depth factor of the biome. The default values vary between 1.5 and -1.8.
temperature TAG_Float The temperature factor of the biome. The default values vary between 2.0 and -0.5.
scale Optional TAG_Float ? The default values vary between 1.225 and 0.0.
downfall TAG_Float ? The default values vary between 1.0 and 0.0.
category Optional TAG_String The category of the biome. Known values are "ocean", "plains", "desert", "forest", "extreme_hills", "taiga", "swamp", "river", "nether", "the_end", "icy", "mushroom", "beach", "jungle", "mesa", "savanna", and "none".
temperature_modifier Optional TAG_String ? The only known value is "frozen".
effects sky_color TAG_Compound TAG_Int The color of the sky. Example: 8364543, which is #7FA1FF in RGB.
water_fog_color TAG_Int Possibly the tint color when swimming. Example: 8364543, which is #7FA1FF in RGB.
fog_color TAG_Int Possibly the color of the fog effect when looking past the view distance. Example: 8364543, which is #7FA1FF in RGB.
water_color TAG_Int The tint color of the water blocks. Example: 8364543, which is #7FA1FF in RGB.
foliage_color Optional TAG_Int The tint color of the grass. Example: 8364543, which is #7FA1FF in RGB.
grass_color Optional TAG_Int ? Example: 8364543, which is #7FA1FF in RGB.
grass_color_modifier Optional TAG_String Unknown, likely affects foliage color. If set, known values are "swamp" and "dark_forest".
music Optional TAG_Compound Music properties for the biome. If present, contains the fields: replace_current_music (TAG_Byte), sound (TAG_String), max_delay (TAG_Int), min_delay (TAG_Int).
ambient_sound Optional TAG_String Ambient soundtrack. If present, the ID of a soundtrack. Example: "minecraft:ambient.basalt_deltas.loop".
additions_sound Optional TAG_Compound Additional ambient sound that plays randomly. If present, contains the fields: sound (TAG_String), tick_chance (TAG_Double).
mood_sound Optional TAG_Compound Additional ambient sound that plays at an interval. If present, contains the fields: sound (TAG_String), tick_delay (TAG_Int), offset (TAG_Double), block_search_extent (TAG_Int).
particle probability Optional TAG_Compound TAG_FLOAT Particles that appear randomly in the biome. Possibly the probability of spawning the particle. ?
options TAG_COMPOUND The properties of the particle to spawn. Contains the field "type" (TAG_String), which identifies the particle type.

Chat registry:

Name Type Notes
type TAG_String The name of the registry. Always "minecraft:chat_type".
value TAG_List List of chat type registry entries (see below).

Chat type:

Name Type Notes
name TAG_String The type's name (eg "minecraft:chat")
id TAG_Int
elements TAG_Compound "chat" and "narration" TAG_Compound's (see below)

Chat type "chat" and "narration":

Name Type Notes
translation_key TAG_String
style TAG_Compound Similar to Chat JSON (only present in "chat" TAG_Compound)
parameters TAG_List of TAG_String Values can be "sender", "target" and "content"

Resource Pack

Packet ID State Bound To Field Name Field Type Notes
0x06 Configuration Client URL String (32767) The URL to the resource pack.
Hash String (40) A 40 character hexadecimal and lowercase SHA-1 hash of the resource pack file.
If it's not a 40 character hexadecimal string, the client will not use it for hash verification and likely waste bandwidth — but it will still treat it as a unique id
Forced Boolean The notchian client will be forced to use the resource pack from the server. If they decline they will be kicked from the server.
Has Prompt Message Boolean true If the next field will be sent false otherwise. When false, this is the end of the packet
Prompt Message Optional Chat This is shown in the prompt making the client accept or decline the resource pack.

Feature Flags

Used to enable and disable features, generally experimental ones, on the client.

Packet ID State Bound To Field Name Field Type Notes
0x07 Configuration Client Total Features VarInt Number of features that appear in the array below.
Feature Flags Identifier Array

As of 23w31a, the following feature flags are available:

  • minecraft:vanilla - enables vanilla features
  • minecraft:bundle - enables support for the bundle
  • minecraft:trade_rebalance - enables support for the rebalanced villager trades

Update Tags

Packet ID State Bound To Field Name Field Type Notes
0x08 Configuration Client Length of the array VarInt
Array of tags Tag type Array Identifier Tag identifier (Vanilla required tags are minecraft:block, minecraft:item, minecraft:fluid, minecraft:entity_type, and minecraft:game_event)
Array of Tag (See below)

Tags look like:

Field Name Field Type Notes
Length VarInt Number of elements in the following array
Tags Tag name Array Identifier
Count VarInt Number of elements in the following array
Entries Array of VarInt Numeric ID of the given type (block, item, etc.).

More information on tags is available at: https://minecraft.gamepedia.com/Tag

And a list of all tags is here: https://minecraft.gamepedia.com/Tag#List_of_tags


Serverbound

Plugin Message (configuration)

Main article: Plugin channels

Mods and plugins can use this to send their data. Minecraft itself uses the minecraft:payload channel to send many types of payloads, which are documented here.

More documentation on this: https://dinnerbone.com/blog/2012/01/13/minecraft-plugin-channels-messaging/

Note that the length of Data is known only from the packet length, since the packet has no length field of any kind.

Packet ID State Bound To Field Name Field Type Notes
0x00 Configuration Server Channel Identifier Name of the plugin channel used to send the data.
Payload Byte Array (32767) Any data, depending on the channel. minecraft:payload payloads are documented here. The length of this array must be inferred from the packet length.

In Notchian server, the maximum data length is 32767 bytes.

Finish Configuration

Sent by the client to notify the client that all the configuration has finished. It is sent after the server sends its own Finish Configuration.

Packet ID State Bound To Field Name Field Type Notes
0x01 Configuration Server no fields

This packet switches the connection state to play.

Keep Alive (configuration)

The server will frequently send out a keep-alive (see clientbound Keep Alive), each containing a random ID. The client must respond with the same packet.

Packet ID State Bound To Field Name Field Type Notes
0x02 Configuration Server Keep Alive ID Long

Pong (configuration)

Response to the clientbound packet (Ping) with the same id.

Packet ID State Bound To Field Name Field Type Notes
0x03 Configuration Server ID Int id is the same as the ping packet

Resource Pack (configuration)

Packet ID State Bound To Field Name Field Type Notes
0x04 Configuration Server Result VarInt Enum 0: successfully loaded, 1: declined, 2: failed download, 3: accepted.
Retrieved from "https://wiki.vg/index.php?title=Pre-release_protocol&oldid=18328"