Skip to content

Updates for Minecraft release 1.26.40#32

Open
JakeShirley wants to merge 2 commits into
mainfrom
automated/1.26.40
Open

Updates for Minecraft release 1.26.40#32
JakeShirley wants to merge 2 commits into
mainfrom
automated/1.26.40

Conversation

@JakeShirley

Copy link
Copy Markdown
Member

AUTOMATED PR

Updating bedrock-protocol-docs for Minecraft release 1.26.40

@zachcampbellskyboxlabs

Copy link
Copy Markdown

Test PR please ignore :)

@conmaster2112

Copy link
Copy Markdown

W navi

@cishawe cishawe force-pushed the automated/1.26.40 branch from db8c68c to 6391983 Compare June 11, 2026 22:44
@Kaooot

Kaooot commented Jun 19, 2026

Copy link
Copy Markdown

Hello, first of all I'd like to thank all of you at Mojang for the fantastic work you're doing on the Cereal conversion,
the automation of protocol docs generation and the provision of JSON schemas via the BDS test configuration flag. This
is really helpful for anyone working with the Bedrock Network Protocol. In the current preview cycle, further packets
are being converted to Cereal and I've noticed a few encoding issues in the process. I'd therefore like to
bring these to your attention so that they can be resolved.

The current release is 1.26.30 Protocol 1001
The latest preview build is 1.26.40-beta.26 Protocol 2144

CraftingDataPacket:

The following net effects double the size of the raw packet, as confirmed by a comparison of the payload from u3 aka
current release with that from the latest preview build.

  • RecipeIngredient ItemDescriptors are written as conditions (see cereal definition hash 1429287564) where
    controlValueType=0 appears to be equivalent to ItemDescriptorType=Invalid
    • ItemDescriptorType=Invalid sends additional varint fields for Aux Value and Stack Size, but should not contain any
  • controlValueType=1 covers all other ItemDescriptor types
  • ItemDescriptorType is written as a string rather than as an unsigned varint: "item_tag" for ItemTagDescriptor, "name"
    for DefaultDescriptor, and so on.
  • Each item is written as a corresponding string identifier rather than a varint item runtime id for the item.

ItemStackResponsePacket:

It writes double optional has value bool fields for:

  • the ItemStackResponseInfo Containers field (bool1 -> if true -> bool2 -> if true -> write Containers array)
    • expected: std::optional<std::vector<ItemStackResponseContainerInfo>>
  • the ItemStackResponseSlotInfo ItemStackNetId field (bool1 -> if true -> bool2 -> if true ->
    write ItemStackNetId ID varint)
    • expected: std::optional<ItemStackNetId>

ResourcePackClientResponsePacket:

  • writes the ResourcePackResponse Type as a constant string, even though it has already been written with the Response
    conditional controlValueType unsigned varint.

ActorData Type:

see all cerealized packets which use ActorData such as AddActor or SetActorData.

  • Each DataItemPayload has its own constant "Type" byte, which was already sent with the DataItemEntry Payload
    unsigned varint controlValueType. At the start of the preview cycle, this was a constant string
    (examples: "byte", "int64", "compoundtag", "vec3") which has since been replaced by the constant byte.

AddPlayerPacket:

  • Suggestion: The BuildPlatform enumeration could be passed as a varint.

I hope the feedback provided here is helpful.

@Kaooot

Kaooot commented Jun 26, 2026

Copy link
Copy Markdown
## Updates for 1.26.40-beta.27 (v2164) 06/26/2026

PlayerAuthInputPacket:

* Input Data seems to be optional, even though it is marked as required.
* writes double optional has value bool fields for:
    * PackedLegacyItemUseInventoryTransaction optional
    * ItemStackRequest optional
    * PlayerBlockActions optional
    * VehicleRotation optional
    * ClientPredictedVehicle optional

PlayerListPacket:

* writes a constant byte for the PlayerListEntry type, seems to be zero
* PlayerListAddEntry: the payload appears to end after the zero-byte written after the XBL XUID field, but
  it should actually contain more fields, as they're all marked as required. At least this applies to the entry where
  the client - i.e. the packet receiver - is the same as the player specified in the entry and is to be added to the
  player list

PlayerLocationPacket:

* writes a constant varint for the PlayerLocationPacketType, seems to be zero

PlayerUpdateEntityOverridesPacket:

* writes a constant string for the UpdateType

Experiments:

* the array should be size-compressed

ItemStackRequestPacket:

* writes a constant byte for the ItemDescriptorType
* TextProcessingEventOrigin, ItemStackRequestSlotInfo ItemStackNetId, Filtered String Index fields could be of type
  varint instead of int32
* the NameDescriptor should contain a runtime ID for the item rather than its full name, in order to reduce network
  bandwidth
* writes an additional byte for each ItemStackRequestActionType, this must match the legacy
  ItemStackRequestActionType serialization, i.e. it must contain the removed types
  PlaceInItemContainer=7 and TakeFromItemContainer=8. Otherwise, the Bedrock Dedicated Server will not accept this, as
  can be seen here:
PacketViolationWarningPacket(violationType=PACKET_MALFORMED, violationSeverity=TERMINATING_CONNECTION,
violatingPacketId=147, violationContext=wrong const value for member "Action type")
## Additions 06/27/2026

SetScorePacket:
* Score Info array is required, but is optional according to the json schema
* ScorePacketEntryAction is written as a constant string value, even though it's already defined as an unsigned varint in std::variant

SerializedSkin:
* PieceTintColors persona::PieceType is serialized as string but should be an unsigned varint
* the SerializedPersonaPieceHandle persona::PieceType should be an unsigned varint instead of int32
* TrustedSkinFlag is serialized as string instead of unsigned varint

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants