test(cliffs): the crater RNG hypothesis is UNSUPPORTED - n is 1 (#84)

[wormeyman]

#130 proposed a mechanism class new to #84 — entity autoplace rolls, so removing calcite shifts the per-chunk RNG stream — and honestly marked itself "a hypothesis, not a result: nothing here tests it". This is that test.

No capture. Every fact below is in fixtures already committed, one of them since #111.

The hypothesis is not refuted. The evidence for it is.

1. n is ONE crater, not eight

The eight crater-cliff entities are eight segments of a single ring — centre (1646.62, 1679.75), radii 4.95 to 7.00, against the prototype's own crater_radius = 7. FFF #386 describes exactly this: "a ring of special cliffs where sections of the ring can randomly be removed."

Effective sample size 1. #130's table invites reading it as 8.

2. The spatial reading would have been vacuous

All eight segments sit within 0.33 tiles of a calcite entity — which looks decisive and is not. Their chunk (51,52) holds 805 calcite entities over 1024 tiles, 78.6% coverage. A ring landing on calcite there is the expected outcome.

3. #130's control row is VACUOUS

It offers "geyser OFF → 0 craters" as the arm separating calcite from resources generally. There are zero geysers in the ring's chunk — all 19 are in (48,48), (48,49), (53,54). The lever works globally (removes all 19, moves cliff-vulcanus 885 → 889) and cannot touch that chunk's stream by construction. Both halves are asserted, because "the lever did something" and "it did nothing here" are different claims.

4. A lever unrelated to calcite also produces craters

Sitting unread in oracle-vulcanus-cliff-suppressor-levers since #111:

arm	cliff-vulcanus	crater-cliff
default, resources ON	885	0
resources OFF via controls	916	8
LAVA TILES OFF only	1053	7
resources OFF + LAVA TILES OFF	1082	18

Craters appear with calcite still ON. Every #84 spec filters to name === "cliff-vulcanus", so the column was never looked at — the same failure #94 caught once already, in the same investigation.

5. And that row is a data fact, not a hypothesis

crater-cliff overrides the default cliff mask with an explicit {item, object, player, water_tile}. On Vulcanus only lava and lava-hot carry water_tile. Lava blocks crater segments by prototype; row 3 needs no RNG at all.

Where calcite stands

Its route is still unexplained and the RNG stream is still the only unclosed candidate. Two others are now closed by reading rather than assuming:

• Not entity collision. core/lualib/collision-mask-defaults.lua gives resource the mask {resource}, disjoint from every cliff mask including crater-cliff's. That is test(cliffs): the ore rule is NOT entity collision, and it acts at the destroy stage (#84) #124's prototype-level argument extended to the second entity type rather than assumed to carry over.
• Not lava tiles. feat(oracle): the resource lever moves TILES - confounded, but inert for cliffs (#84) #128 measured calcite moving zero blocking tiles.

A third fact from the same file closes a route this session had to consider: the default cliff mask carries not_colliding_with_itself = true, so cliffs never collide with cliffs of their own prototype. That matters because applyCliffs adds each cliff to the surface before testing the next one, and 57 of 400 adjacent orientation pairs have overlapping boxes — without the flag the entire run would be placement-order dependent.

Status and the real test

UNSUPPORTED, not refuted. Testing it properly needs a lever that changes the roll count in the ring's own chunk without touching that chunk's tiles or lava — switching off one of the rock prototypes listed before crater-cliff in autoplace_settings.entity would do it. One capture arm, and worth having a real control before spending it.

No new fixtures, no shipping behaviour change. pnpm run verify green (183 files, 1514 tests).

🤖 Generated with Claude Code

https://claude.ai/code/session_01MmitdaFJxN9Wm8LkQu33kc