Files
benilla-octo/crates
gromandClaude Opus 5 948373f7a4 probes: a prop shares a slot with one that agrees, not only one identical
The interior prop-probe table holds 8192 and cannot be widened — 13 mesh-tag
bits, with every bit of that u32 already spoken for. It keyed on exact
coefficient bits, so two props shared a slot only when no MOLR light reached
either *and* their baked MODD colours matched to the last bit. Measured in
Ironforge at grom's login spot: 3,883 distinct probes standing still, 5,543 at a
far clip of 777, and his session saturated during the world load — after which
every further interior prop falls back to the room's flat day/night law.

The distinctness is the per-prop baked colour, not the prop's position: folding
the probe on a 16 yd grid instead of each prop's own centre removed only 4.5% of
the slots. Rounding the *key* onto a 1/32 step removes 35%. A shared slot keeps
the first claimer's exact rows, so the quantization decides who shares and never
reaches the light the shader reads.

Verified by render, not by argument: that Ironforge storeroom at the new default
is byte-identical to exact keying across 1.44M pixels, while starving the table
outright (the new `WOW_PROBE_CAP=0`) moves 109,830 of them by up to 14/255 — so
the lane does drive this view, and the sharing costs nothing measurable in it.

The table now also counts the distinct probes it refused, and all three overflow
warnings report it. That number is the whole question when the table saturates: a
small overflow is answered by sharing harder, a large one only by more slots, and
until now the log could not tell them apart.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SgstFWtn1RxEJ5kVrpgYwn
2026-10-19 12:39:10 -06:00
..