bedrock: fix voxel_shapes deserialization - VoxelShape.cells is a single VoxelCells, not an array

[AnonymoDGH]

Summary

Fixes a deserialization failure for the bedrock voxel_shapes packet (0x151 / 337) on versions 1.26.0 through 1.26.30.

Fixes PrismarineJS/bedrock-protocol#753

The bug

On bedrock 1.26.30.5, connecting to a server crashes with:

Deserialization failure for packet 0xd1 ...
PartialReadError: Read error for undefined : undefined
    at Object.VoxelShape (...)
    at Object.packet_voxel_shapes (...)

The VoxelShape type defined cells as an array of VoxelCells:

VoxelShape:
   cells: VoxelCells[]varint   # <- wrong

but the actual packet contains a single VoxelCells record. This is confirmed by the 1.26.40 / latest schema, which correctly uses a single VoxelCells:

VoxelShape:
   cells: VoxelCells           # <- correct (1.26.40 / latest)

Verification

I decoded the two raw packet captures attached to bedrock-protocol#753 (7173 bytes each) using protodef against both schemas:

Before (array): PartialReadError — the exact error from the issue.

After (single):

DECODE OK: consumed 7173 of 7173 bytes
packet name: voxel_shapes
shapes: 127
name_map: 59
custom_shape_count: 0
coords in [0,1]: 1062/1062
sample names: minecraft:end_portal_frame_eye=57, minecraft:box_16x4x16=55, minecraft:wall_head_facing_south=54
round-trip identical: true

All 1062 voxel coordinates fall in the valid [0,1] range, the 59 name-map entries are valid block identifiers, and re-serializing the decoded value reproduces the original packet byte-for-byte.

Changes

Changed cells: VoxelCells[]varint → cells: VoxelCells in the VoxelShape type of types.yml for the four affected versions, and regenerated each protocol.json with node compileProtocol.js bedrock <version>:

• data/bedrock/1.26.0
• data/bedrock/1.26.10
• data/bedrock/1.26.20
• data/bedrock/1.26.30

1.26.40 (generated from bedrock/latest) already had the correct single-VoxelCells definition and is unchanged. The protocolSync test passes for all versions.

[AnonymoDGH]

Note on the failing build job: this is a pre-existing environment issue unrelated to this change. It fails at module load with Cannot find package '@napi-rs/snappy-wasm32-wasi' (imported from bedrock-protocol/node_modules/snappy), before any protocol data is read. The same failure occurs on master and on other open PRs (e.g. #1231, #1230).

The build (24) job, which runs the full data/schema test suite against this change, passes. Locally, protocolSync (yaml↔json sync validation) also passes for all versions, and I verified the fix decodes the reporter's real packet captures end-to-end.

[extremeheat]

Thanks, reran the CI as indeed it was caused by a PR that was reverted

[AnonymoDGH]

Thanks for reviewing and re-running the CI, @extremeheat — glad it's confirmed to be the reverted-PR issue and not this change. Appreciate it!