Cross-overlay occupancy: earlier autoplacers block later ones (enemy bases are 47% over in region 0)

[wormeyman]

Successor to #9. The placement roll now covers all five overlays, and the density
agreement is good everywhere except one region, where the cause is measured, not
suspected: entities that placed earlier occupy the ground later ones would use.

The evidence

Nauvis enemy bases, region [0,0]-[512,512], against
test/fixtures/oracle-entity-counts.seed123456.json (2.1.12, seed 123456):

model	placed	game
roll + tile gate + own-overlay collision (shipped)	28	19
...plus this app's tree and rock placements as blockers	19	19

And in region [4096,4096], where the shipped model already agrees to 10.6%:

model	placed	game
shipped	157	142
plus tree + rock blockers	155	142

Trees occupy 34.3% of region 0 and rocks 3.8%, and both sort before spawners in
autoplace order, so the game finds that ground already taken. Region 0 is the
spawn-centred window where trees are densest, which is why it is the region that
shows it.

The mechanism is not a guess either - it is what the game's own source says. Both
crude-oil and sulfuric-acid-geyser carry order = "c" with the comment:

Other resources are "b"; oil won't get placed if something else is already there.

Why it was not fixed in the placement-roll work

Modelling it needs a tree placement roll, and trees currently render an expected
coverage blend rather than placing individual entities. That roll would itself be
unvalidated - there is no tree entry in the entity-count oracle - so the 19-vs-19
above rests on an unvalidated input. Shipping it would trade a known 47% residual in
one region for an unknown error in every region, on every overlay.

Owner ruling during that work: ship as-is, file this.

What doing it properly looks like

1. Add trees to the entity-count oracle (test/oracle/entityCounts.ts) and validate a
   tree placement roll on its own, the way every other overlay was.
2. Then make occupancy a first-class input to makePlacementSet - a shared per-chunk
   occupancy map that overlays write into in autoplace order, rather than each overlay
   colliding only against itself.
3. Re-measure every overlay. This changes densities globally, so all bands in
   test/entityDensity.spec.ts need re-pinning, not just the enemy rows.

Note that step 2 partially re-introduces the cross-overlay coupling the M3.5 spike
stopped on (docs/noise/placement-roll-NOTES.md). It is strictly weaker - occupancy
in autoplace order, not a shared RNG stream with data-dependent jitter draws - and it
would still not make positions tile-exact. Worth being explicit about that so this
does not get mistaken for "finish the tile-exact port".

Definition of done

• A tree placement roll validated against its own oracle counts.
• Occupancy shared across overlays in autoplace order.
• test/entityDensity.spec.ts re-pinned across all overlays, with the enemy region 0
  row banded rather than carrying its current "unbanded by owner ruling" exemption.

[wormeyman]

Blocker: this needs the game as an oracle, and a fresh cloud sandbox has none

Picked this up in a Claude Code web session. Every route to the ground truth step 1 requires is closed in that environment, so I'm recording a precise blocker + an executable plan rather than shipping unvalidated work (which is exactly the trade this issue was filed to avoid).

What's missing in the sandbox

• No Factorio binary (FACTORIO_BIN unset; no Steam/PATH install), so test/oracle/entityCounts.ts's count_entities_filtered capture can't run.
• No factorioLuaAPI/ mirror and no ~/GitHub/factorio-data clone. pnpm refs:sync can't create them because it pins to the binary's version, and there's no binary.
• factorio.com/get-download/.../headless/linux64 is 403 through the agent proxy, so self-provisioning a headless binary is out too.

Why that blocks all three DoD items

• Step 1 ("a tree placement roll validated against its own oracle counts") needs tree entity counts. The committed oracle-entity-counts.seed123456.json has none — only huge/big/big-sand-rock, crude-oil, biter/spitter-spawner. Trees today are validated as a probability field (oracle-trees.seed123456.json) and as ink vs. previews, neither of which is a placed count.
• Steps 2 and 3 both rest on step 1: occupancy matters because of trees (34.3% of region 0), and the global density re-pin is only meaningful once the tree blocker is validated.
• CLAUDE.md + test/fixtureProvenance.spec.ts forbid fabricating a fixture/expected value, so there's no honest shortcut around the capture.

---

Executable plan for a session that has a 2.1.12 binary

Step 1a — extend the capture (test/oracle/entityCounts.ts)

• In buildEntityCountControlLua, add a total tree count per region alongside the name loop: counts["tree:type"] = surface.count_entities_filtered{area = {{x0,y0},{x1,y1}}, type = "tree"}. A type total is the right denominator for occupancy (total tree tile coverage) and sidesteps enumerating all 20 base tree prototypes.
• Re-run node --experimental-strip-types test/oracle/entityCounts.ts. Cross-check built in for free: the capture rewrites the whole fixture, so every existing non-tree count must reproduce byte-for-byte — diff everything except the new tree rows and confirm it's empty before trusting the tree numbers. If the existing counts drift, stop: the binary/version/platform differs from the fixture's provenance.
• No new fixture file, so provenance stays keyed to the existing entry; re-confirm its version stamp against the binary used.

Step 1b — the tree placement roll

• Add trees to PLACEMENT_SALT (src/noise/placement/placementRoll.ts).
• Field: makeTreeDensity (max of 15 species) is already the arbitrated max_i p_i — roll U < treeMax(x,y).
• Collision box = the map-gen box 1.6 × 1.6, not the charted 1.0 × 1.0 the density render uses (trees.lua:4904 = 2× the 0.8×0.8 collision box; see the map-gen-box table in placement-roll-NOTES.md). Using the chart box here would under-exclude.
• Tile gate: trees' simple-entity default collision mask includes water_tile, so gate out water.
• Validate: new case in test/entityDensity.spec.ts, tree placed-count vs the tree:type game count in regions 0 and 1, banded like the others.

Step 2 — shared occupancy in autoplace order

• Today resolveChunk collides each overlay only against its own accepted boxes (accX/accY). Introduce a per-chunk shared occupancy provider keyed by (cx,cy) that resolves earlier overlays on demand and caches; each overlay reads occupied tiles as blockers and writes its own placements back.
• Autoplace order (from placement-roll-NOTES.md): trees a[tree] → rocks a[landscape]-c[rock] → resources b → spawners b[enemy]-a[spawner] → geyser c. Keep per-overlay salts (rolls stay independent); share occupancy only. This is the "strictly weaker than a shared RNG stream" coupling the issue describes — it will not make positions tile-exact and shouldn't try to.

Step 3 — re-pin test/entityDensity.spec.ts

• Game counts don't change; our placed counts drop for later overlays once earlier ones occupy ground. Re-measure and re-pin every overlay's band, not just enemy.
• Give the enemy region-0 row a real band (drop the "unbanded by owner ruling" exemption at BAND/its doc block); target ≈19 vs game 19, remembering the notes' caveat that the exact 19 is a coincidence at that precision — band it, don't pin it.
• FIELD_BAND (ungated roll vs field integral) is occupancy-independent — leave it.

Caveat to carry in: existing fixtures were captured on mac-arm64 2.1.12. Map-gen is meant to be deterministic across platforms, but per this repo's own rules that's to be verified, not assumed — the byte-for-byte reproduction of existing counts in step 1a is that verification.

---

Generated by Claude Code