Operator delegated the placement call. Applied standard top-down-arena practice
rather than the first-pass ring scatter:
clear core (5u) the landing spot and dash room; props there cramp spawn
and cause dash collisions the player never asked for
band 6-13u solids live in KITING range, which is also roughly where
the diver's travelling light reaches. A prop outside the
lit radius reads as an invisible wall - the worst failure
mode in a dark game, so cover is pulled inward to where
it can be SEEN before it is hit
min spacing 2.6u enforced across clutter AND cover on ONE shared occupancy
list. This is a NAVIGATION guarantee, not an aesthetic:
enemies have no pathfinding, so gaps must stay wider than
a body. Rejection-sampled; a piece that cannot fit is
DROPPED rather than jammed into a gap movers can't pass
explosives >8u a barrel near the landing spot chains into you on spawn
Measured live, all three invariants hold:
17 solids, radius 7.89..12.95, min gap 2.79 (policy >=2.60), 0 explosives <8u
Nav re-validated on a CLEAN run: closest approach 1.40u, two enemies in melee.
Enemies cross the inward cover band and reach the player.
Correction worth recording: three intermediate readings showed "frozen movers"
and were WRONG. Teleporting the player around a long-running Play session
desyncs the predicted character controller and leaves stale AI state - the
server had the player back at (2.5,0) while I was measuring against (0,0), and
an earlier "all four frozen" reading was simply enemies that had converged and
were attacking. Only the clean, unmutated run is valid. Do not mutate server
state and then trust a movement measurement in the same session.
304/304 EditMode green.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Operator at the A0 gate: "the world is very static." Part of that was a
regression from today's purge, and the audit's own signature pattern for the
third time: the system exists, the authoring is placed, and it silently
produces nothing.
Server/Economy/RoomFieldSystem.cs was deleted with the run/room FSM in
62e48a3b0. That was correct for the FSM, but the system was also the only
consumer of the ClutterFieldSpawner / CoverFieldSpawner / GeyserFieldSpawner
singletons. Those kept baking into Gameplay.unity and nothing read them:
before: Geyser 0 BlightClutter 0 (spawners configured for 14 + 2 + 3)
after: Geyser 2 BlightClutter 17
So the arena lost 14 destructible clutter pieces, 3 cover pieces and 2
periodically erupting geysers — a large share of everything that moved or
could be interacted with.
The old system could not be revived: it keyed every spawn off RunInfo,
RunRuntime, RoomPlan, RunMapMath, RegionMath and RoomTag teardown, all gone.
ArenaFieldSystem is a gym-scoped replacement that seeds ONCE at world start
and never tears down — Phase 1 is "no world, a gym", and everything
room-shaped belongs to the Phase-2 pocket generator, not here.
Contracts carried over deliberately, each load-bearing:
- baked.WithPosition, never FromPosition (FromPosition resets Scale, a GhostField)
- Geyser NextEruptTick born-correct off the live ServerTick via TickUtil.NonZero,
staggered 60 ticks per instance so eruptions desync; 0 stays "not ready"
- a 6 u keep-out ring around the arena origin (the player's landing spot)
- clutter variant 3 = the explosive hazard, 0-2 inert dressing
- a fixed arena seed: a gym wants the same arena every session
Verified live: geysers stamped 306 / 366 (staggered, Scale 1.00 preserved).
Navigation re-validated per the standing rule that adding Environment cover
can freeze movers, since enemies have NO pathfinding. First measurement showed
all four "frozen" — that was my error: they had already converged and were
attacking. Re-tested by moving the player across the arena: all four closed
23.5->20.4, 24.2->21.2, 23.9->20.9, 22.8->19.7 u through the cover field. No
soft-lock.
304/304 EditMode green.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
kronic