0.3.6

Auxiliary per-position block data.

RetroAPI had both ends of block storage and nothing between them. Block state is 12 bits, total, for every property a block has. A block entity holds anything, at the price of being walked and range-checked every single tick, forever, by a game that expects a world to contain dozens of them and not tens of thousands. Data that needs more than a nibble and changes when a player right-clicks fell down the middle: give up on it, or pay per block per tick for it.

RetroBlockData, a 32-bit value per block position, per registered type, saved and synced. Sparse maps on the chunk, one entry per position that actually carries data, and no per-tick cost at all.

public static final RetroBlockDataType CAMO = RetroBlockData.registerBlockRef(id("camo"));

RetroBlockData.set(world, x, y, z, CAMO, RetroBlockData.encodeBlockRef(Block.GLASS.id, 0));
int worn = RetroBlockData.get(world, x, y, z, CAMO);

It persists in the region sidecar as a new v4 section, omitted entirely from chunks that carry none so those files stay byte-identical to v3. It rides the chunk packet on chunk send, and single-position changes are pushed to the players who can actually see the position. Reads work from the chunk-render thread's WorldRegion view, because a block's own renderer is exactly the caller that wants this.

registerBlockRef, for the case that makes a raw int wrong. A runtime block id is a property of the installed mod set, not of the world, so storing one verbatim means the day a mod is added or removed, every stored reference quietly points at a different block. A whole build re-skins itself and nothing errors. Block reference types go through a per-chunk string palette instead, the same machinery RetroAPI already uses for the modded blocks themselves, and a reference whose mod is missing this session is parked and written back out on save rather than erased. Vanilla ids are fixed for all time and are written numerically.

A position's data is dropped when the block there changes, so a value can never be inherited by whatever is placed there next. Metadata and state changes, a door opening or a crop growing, go through setBlockMeta and keep theirs.

Nothing else changed. Both launch smoke suites pass, client and server, with every mixin applying cleanly.