Protocol for r/21_u6 NetworkProtocolVersion 776 #18
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Minecraft Network Protocol Docs 01/14/2025
For r21_u6, Network Protocol Version 776
New Packets
ClientCameraAimAssistPacket
ClientMovementPredictionSyncPacket
CreativeContentPacket
Renamed Packets
ItemComponentPacket
Packet Changes
CameraAimAssistPresetsPacket
CommandBlockUpdatePacket
StartGamePacket
StructureEditorData
New Types
ActorDataBoundingBoxComponent
ActorDataFlagComponent
CameraInstruction::FadeInstruction
CameraInstruction::FadeInstruction::ColorOption
CameraInstruction::FadeInstruction::TimeOption
CameraInstruction::SetInstruction
CameraInstruction::SetInstruction::EaseOption
CameraInstruction::SetInstruction::PosOption
CameraInstruction::SetInstruction::RotOption
CameraInstruction::SetInstruction::FacingOption
CameraInstruction::SetInstruction::ViewOffsetOption
CameraInstruction::SetInstruction::EntityOffsetOption
CameraInstruction::TargetInstruction
MovementAttributesComponent
Other Changes in Types
CameraInstruction
SerializedAbilitiesData::SerializedLayer
New Enums
ActorDataBoundingBoxComponent::Type:
CameraAimAssist::TargetMode:
ClientCameraAimAssistPacketAction:
CreativeItemCategory:
NoteBlockInstrument:
Enum Changes
AbilitiesIndex:
ActorDataIDs:
ActorEvent:
ActorFlags:
ActorType:
AnimatePacket::Action:
See also PlayerAuthInputPacket::InputData::MissedSwing for a very similar action ]
Writes RowingTime ]
Writes RowingTime ]
BuildPlatform:
Connection::DisconnectFailReason:
ContainerEnumName:
ComplexInventoryTransaction::Type:
See ItemReleaseInventoryTransaction::ActionType for which it is. ]
ContainerID:
CraftingDataEntryType:
Enchant::Type:
ItemReleaseInventoryTransaction::ActionType:
ItemUseInventoryTransaction::ActionType:
If it is a usable item like food the server is expected to send a SetActorDataPacket with ActorFlags::USINGITEM along with the transaction response.
While using an item, movement speed is slowed which will be reflected in the move vector in Player Auth Input. ]
When using server auth block breaking as specified in StartGamePacket this is never sent.
Instead, block actions are supplied in Player Auth Input. ]
ItemUseOnActorInventoryTransaction::ActionType:
Server is expected to deal damage to the entity with visuals. ]
MapItemTrackedActor::Type:
MinecraftPacketIds:
ParticleType:
PlayerActionType:
Corresponds to Player Auth Input InputData::StartJumping bit 31 ]
Server is expected to respond with SetActorDataPacket with ActorFlags::SPRINTING and an UpdateAttributesPacket to apply the sprint boost.
Corresponds to Player Auth Input InputData::StartSprinting bit 25 ]
Server is expected to respond with SetActorDataPacket with ActorFlags::SPRINTING and an UpdateAttributesPacket clearing the sprint speed boost.
Corresponds to Player Auth Input InputData::StopSprinting bit 26 ]
Server is expected to respond with SetActorDataPacket with ActorFlags::SNEAKING true if accepted, false if rejected, and a bounding box update.
Corresponds to Player Auth Input InputData::StartSneaking bit 27 ]
Server is expected to respond with SetActorDataPacket with ActorFlags::SNEAKING false if accepted, true if rejected, and a bounding box update.
Corresponds to Player Auth Input InputData::StopSneaking bit 28 ]
Used to be a ChangeDimension action.
Sent in Player Action. ]
Server is expected to respond with SetActorDataPacket with ActorFlags::GLIDING true if accepted or false if rejected, and a bounding box update.
Corresponds to Player Auth Input InputData::StartGliding bit 32 ]
Server is expected to respond with SetActorDataPacket with ActorFlags::GLIDING false if accepted or true if rejected, and a bounding box update.
Corresponds to Player Auth Input InputData::StopGliding bit 33 ]
Sent in Player Action in EDU ]
Only sent if server auth block breaking is disabled in StartGamePacket.
Sent in Player Auth Input Block Actions with position and facing. ]
Server is expected to respond with SetActorDataPacket with ActorFlags::SWIMMING set to true if accepted or false if rejected, and a bounding box update.
Corresponds to Player Auth Input InputData::StartSwimming bit 29 ]
Server is expected to respond with SetActorDataPacket with ActorFlags::SWIMMMING set to false if accepted or true if rejected, and a bounding box update.
Corresponds to Player Auth Input InputData::StopSwimming bit 30 ]
Server is expected to send a SetActorDataPacket with ActorFlags::DAMAGENEARBYMOBS set to true if accepted or false if rejected along with a bounding box update.
Sent in Player Action but will soon turn into a Player Auth Input InputData bit ]
Server is expected to send a SetActorDataPacket with ActorFlags::DAMAGENEARBYMOBS set to false if accepted or true if rejected along with a bounding box update.
Sent in Player Action but will soon turn into a Player Auth Input InputData bit ]
Used for the client to inform the server that it predicted the player destroying a block.
The server may respond with block, chunk, or item information if it disagrees, or send no response to imply agreement.
Only used when server-auth block breaking toggle is on as specified in StartGamePacket ]
Used to inform the server that the client's current block changed for block destruction.
The server is expected to use this to progress the block destruction and await an upcoming PredictDestroyBlock action.
They are also expected to broadcast LevelEventPackets for the block cracking of the block being destroyed.
Only sent when server-auth block breaking toggle is on as specified in StartGamePacket ]
Sent in Player Action.
Server can expect this to arrive with an InventoryTransactionPacket with ItemUseInventoryTransaction in it.]
Sent in Player Action ]
The server should ignore any client predicted positions from the moment a MovePlayerPacket was sent until receipt of this action.
Corresponds to Player Auth Input InputData::HandledTeleport bit 37 ]
Server is expected to broadcast a LevelSoundEventPacket with LevelSoundEvent::AttackNoDamage.
Corresponds to Player Auth Input InputData::MissedSwing bit 39 ]
Server is expected to respond with a SetActorDataPacket containing a bounding box update.
Server is expected to respond with SetActorDataPacket with ActorFlags::CRAWLING set to true if accepted, or false if rejected.
Corresponds to Player Auth Input InputData::StartCrawling bit 40 ]
Server is expected to respond with a SetActorDataPacket containing a bounding box update.
Server is expected to respond with SetActorDataPacket with ActorFlags::CRAWLING set to false if accepted, or true if rejected.
Corresponds to Player Auth Input InputData::StopCrawling bit 41 ]
Server is expected to respond with an UpdateAbilitiesPacket to accept or reject this.
Corresponds to Player Auth Input InputData::StartFlying bit 42 ]
Server is expected to respond with an UpdateAbilitiesPacket to accept or reject this.
Corresponds to Player Auth Input InputData::StopFlying bit 43 ]
Not sent when using server authoritative movement as specified in StartGamePacket ]
PlayerAuthInputPacket::InputData:
Server is expected to respond with SetActorDataPacket with ActorFlags::SPRINTING and an UpdateAttributesPacket to apply the sprint boost.]
Server is expected to respond with SetActorDataPacket with ActorFlags::SPRINTING and an UpdateAttributesPacket clearing the sprint speed boost. ]
Server is expected to respond with SetActorDataPacket with ActorFlags::SNEAKING true if accepted, false if rejected, and a bounding box update. ]
Server is expected to respond with SetActorDataPacket with ActorFlags::SNEAKING false if accepted, true if rejected, and a bounding box update. ]
Server is expected to respond with SetActorDataPacket with ActorFlags::SWIMMING set to true if accepted or false if rejected, and a bounding box update. ]
Server is expected to respond with SetActorDataPacket with ActorFlags::SWIMMMING set to false if accepted or true if rejected, and a bounding box update. ]
Server is expected to respond with SetActorDataPacket with ActorFlags::GLIDING true if accepted or false if rejected, and a bounding box update. ]
Server is expected to respond with SetActorDataPacket with ActorFlags::GLIDING false if accepted or true if rejected, and a bounding box update. ]
The server should ignore any client predicted positions from the moment a MovePlayerPacket was sent until receipt of this action. ]
Server is expected to broadcast a LevelSoundEventPacket with LevelSoundEvent::AttackNoDamage. ]
Server is expected to respond with a SetActorDataPacket containing a bounding box update.
Server is expected to respond with SetActorDataPacket with ActorFlags::CRAWLING set to true if accepted, or false if rejected. ]
Server is expected to respond with a SetActorDataPacket containing a bounding box update.
Server is expected to respond with SetActorDataPacket with ActorFlags::CRAWLING set to false if accepted, or true if rejected. ]
Server is expected to respond with an UpdateAbilitiesPacket to accept or reject this. ]
Server is expected to respond with an UpdateAbilitiesPacket to accept or reject this. ]
If set, Vehicle Rotation and Client Predicted Vehicle will be written ]
Server is expected to respond with SetActorDataPacket updates of the boat's ROW_TIME_LEFT
See Player Auth Input for further details ]
Server is expected to respond with SetActorDataPacket updates of the boat's ROW_TIME_RIGHT
See Player Auth Input for further details ]
Can be used as a hint to the server or ignored based on desired strictness ]
Can be used as a hint to the server or ignored based on desired strictness.
Strongly correlates with the 'on ground' state of the player ]
On this same tick will be an InventoryTransactionPacket of type ComplexInventoryTransaction::Type::ItemUseTransaction.
Server is expected to respond with SetActorDataPacket containing ActorFlags::USINGITEM true if they agree, otherwise false.]
and ActorFlags::DAMAGENEARBYMOBS set true in SetActorDataPacket ]
and ActorFlags::DAMAGENEARBYMOBS set false in SetActorDataPacket ]
This will be sent even if input permissions are disabled.]
This will be sent even if input permissions are disabled.]
This will be sent even if input permissions are disabled.]
This will be sent even if input permissions are disabled.]
This will be sent even if input permissions are disabled.]
This will be sent even if input permissions are disabled.]
Rotation:
ServerAuthMovementMode:
The mode is intended to be phased out in favor of server authoritative.
It results in the client communicating movement input in the following packets, see their documentation for details:
The client can be repositioned with:
]
This mode is the current default with previews coming soon for migrating to server authoritative
The packets sent from client to server are largely the same as for server authoritative, see their documentation for details:
PlayerActionPacket is sent in some cases, and in others has become a bit inside of PlayerAuthInputPacket.
The client can be repositioned with:
]
This mode is intended to become the new default after previews coming soon.
The packets from client to server are similar.
PlayerActionPacket is sent in some cases, and in others has become a bit inside of PlayerAuthInputPacket.
The client can be repositioned with:
Additionally, in this mode many client-bound packets have a 'Tick' value. These echo back the tick value that the client supplies in the PlayerAuthInputPacket.
For packets relating to a player or client predicted vehicle, the tick value should be that of the most recently processed PlayerAuthInputPacket from the player.
Specifying zero is also acceptable although may result in minor visual flickering as it may confuse client predicted actions.
]