pc/protocol: entity_teleport layout for 1.21.2+ (velocity, f32 rotation, relative flags)

[u9g]

Since 1.21.2 ClientboundTeleportEntityPacket has the same layout as the player position packet: PositionMoveRotation (position, delta movement, f32 yaw/pitch), a Set<Relative> written as a 32-bit int, then onGround. minecraft-data still described the pre-1.21.2 layout (i8 rotation, no velocity, no flags), so every entity_teleport on 1.21.3+ fails to parse (Chunk size is 67 but only 33 was read, PrismarineJS/mineflayer#3759).

Verified against a captured 1.21.4 packet from a Velocity/ViaVersion network:

77                         packet id
97 80 80 80 04             entityId varint (5 bytes)
c02fef0a40000000 ... x3    x y z
0000000000000000 ... x3    dx dy dz
c2b40000 00000000          yaw pitch (f32)
00000000                   relatives (i32)
01                         onGround

1 + 5 + 24 + 24 + 8 + 4 + 1 = 67, which is the chunk size in the error. The flags field reuses PositionUpdateRelatives (already defined for packet_position on these versions), so consumers can treat both packets the same way.

Applied to 1.21.3 through 1.21.11 (proto.yml, protocol.json rebuilt with npm run build) and 26.1 (protocol.json only, it has no proto.yml). Decompiled 26.1 ClientboundTeleportEntityPacket / Relative.SET_STREAM_CODEC = ByteBufCodecs.INT confirm the same layout there.

Relation to the open PRs: #1154 covers only 1.21.3; #1251 covers 1.21.4–1.21.11 but encodes the relatives as a 9-bit bitfield, which protodef reads as 2 bytes, not the 4 bytes vanilla writes, so those packets would still be partial reads. This PR supersedes both.

The mineflayer side (consuming the relative flags in the entity_teleport handler) is in a separate PR.

[rom1504]

Can you double check in the decompiled code ?

[u9g]

Yes — double-checked in the decompiled sources for 1.21.4, 1.21.11 and 26.1 (same layout in all three):

ClientboundTeleportEntityPacket.STREAM_CODEC (net/minecraft/network/protocol/game/ClientboundTeleportEntityPacket.java):

public static final StreamCodec<FriendlyByteBuf, ClientboundTeleportEntityPacket> STREAM_CODEC = StreamCodec.composite(
    ByteBufCodecs.VAR_INT, ClientboundTeleportEntityPacket::id,
    PositionMoveRotation.STREAM_CODEC, ClientboundTeleportEntityPacket::change,
    Relative.SET_STREAM_CODEC, ClientboundTeleportEntityPacket::relatives,
    ByteBufCodecs.BOOL, ClientboundTeleportEntityPacket::onGround,
    ClientboundTeleportEntityPacket::new
);

PositionMoveRotation.STREAM_CODEC:

StreamCodec.composite(
    Vec3.STREAM_CODEC, PositionMoveRotation::position,      // 3 x f64
    Vec3.STREAM_CODEC, PositionMoveRotation::deltaMovement, // 3 x f64
    ByteBufCodecs.FLOAT, PositionMoveRotation::yRot,        // f32
    ByteBufCodecs.FLOAT, PositionMoveRotation::xRot         // f32
);

Relative.SET_STREAM_CODEC:

public static final StreamCodec<ByteBuf, Set<Relative>> SET_STREAM_CODEC = ByteBufCodecs.INT.map(Relative::unpack, Relative::pack);

i.e. a plain 32-bit int (4 bytes), confirming a u32 bitflags is the right encoding here (a 9-bit protodef bitfield reads 2 bytes, which is why #1251 would still under-read). The Relative enum is identical in all three versions (X(0) … ROTATE_DELTA(8)), matching the existing PositionUpdateRelatives flag order.

So the wire format is: varint entityId, 3×f64 pos, 3×f64 delta, f32 yaw, f32 pitch, u32 relative flags, bool onGround — exactly what this PR encodes.

Also noticed the 26.1 hunk was missing from the pushed commit (d5256da only touched 1.21.3–1.21.11 + features.json) — pushed c12191f applying the same layout to data/pc/26.1/protocol.json (it has no proto.yml, and PositionUpdateRelatives was already defined there for packet_position).