Found during review of the persistence-plumbing branch: _build_metadata_section
wrote raw bounds.size into the wire's 2nd float triple, but the wire format
(and _parse_metadata_section) treats that triple as max_pos, computing
size = max - min. AABB(Vector3.ZERO, size) masks this since size == max when
position is 0 -- exactly what every existing test used. Any chunk at a real,
nonzero world position would silently corrupt on its own client-local
encode/decode round-trip. Same bug class as the backend's min+size/min+max
mismatch fixed in chunk_codec.py (eb39e43), just on the client side this
time. Added a regression case to smoke_test_chunk_codec_interop.gd using a
real nonzero chunk position (96,-32,0) -- 33/33 passing. Full sibling smoke
suite re-verified clean afterward.
No test ever exercised the client ChunkDataDecoder against real byte data
before this (M2 chunk streaming was never fed real content on PC2/PC3).
Added scripts/smoke_test_chunk_codec_interop.gd, decoding the backend's
exact golden fixtures (backend/tests/fixtures/chunks/*.bin) and asserting
byte-identical logical values -- the real cross-language contract this
whole persistence system depends on. It found three bugs on first run:
1. chunk_data_decoder.gd's _read_float32/_write_float32 used `bits as
float`/`val as int`, a numeric cast in GDScript, not an IEEE-754
bitcast -- silently corrupted every non-integer position/rotation/
scale/bounds value (1.5 decoded as 1069547520.0, verified). Fixed with
PackedByteArray.decode_float/encode_float (real bitcast, same
little-endian order as the rest of this format).
2. backend/app/services/chunk_codec.py's binary codec wrote bounds as
min+size, disagreeing with world.md §3's documented min+max wire
format and with the client's actual (correct) decoder -- corrupted
every chunk's bounds on the wire despite the backend's own JSON path
using min+max correctly. Fixed the binary encode/decode to match the
spec; regenerated the golden fixtures.
3. chunk_data_decoder.gd's object-properties parsing used
`JSON.parse_string(props_str) or {}` -- GDScript's `or` is a boolean
operator, not Python/JS-style short-circuit-return, so this silently
evaluated to a bool for any object with real property data, crashing
on assignment to the typed `properties: Dictionary` field. Fixed with
an explicit type check.
Full backend suite (132/132) and 4 sibling client smoke tests re-verified
clean after all three fixes; no other `or {}`/`or []` instances of bug 3's
pattern found elsewhere in the codebase.
daddy