Skip to content

docs(cliffs): the CRATER PLACER is ADD-ONLY - the last untouched idea (#84) - #140

Merged
wormeyman merged 3 commits into
mainfrom
cliffs-crater-add-only
Aug 4, 2026
Merged

docs(cliffs): the CRATER PLACER is ADD-ONLY - the last untouched idea (#84)#140
wormeyman merged 3 commits into
mainfrom
cliffs-crater-add-only

Conversation

@wormeyman

Copy link
Copy Markdown
Collaborator

CliffCraterPlacer::tryToPlaceCliffAsCrater was the third and last of UPDATE 9's untouched ideas, carried there as "ruled out for the residual by position, never ruled out as a mechanism". It is add-only, so it cannot be the mechanism.

The read

tryToPlaceCliffAsCrater(Surface&, MapPosition const&, CliffPrototype const&, unsigned int) 0x10160bc34 — thin wrapper, a single bl to the overload below
tryToPlaceCliffAsCrater(…, CraterPlacementDefinition const&, RandomGenerator&) 0x10160bcac — calls calculateCliffSegments, then Surface::addEntity per accepted segment
CliffCraterPlacer::calculateCliffSegments 0x10160be6c — calls Surface::wouldCollide and emplaces the segments that pass

Across the whole 0x10160bc34..0x10160c088 range there is no destroy, remove or erase path of any kind — the only other bls are three PLT stubs of operator delete/memmove shape and the stack-check epilogue. Callers are EntityMapGenerationTask::applyEntities and CliffEditor::buildCliffs.

Why this closes it, and why the closing argument is DIRECTION

That bullet's own framing is why the candidate survived so long. Position arguments only say these objects are not the residual; they never say this code cannot cause it.

The ore effect is fewer cliffs when ore is present — 885 against 916 — so something has to destroy or prevent 31 of them. A function that can only add, and only where wouldCollide reports the space free, cannot produce that sign.

The crater counts corroborate rather than merely permit: 0 craters with resources on, 8 with them off, so both populations move the same way under the lever. Displacement would move them oppositely.

Where #84 stands now

All three of UPDATE 9's ideas are closed — chunk order (#137), the compute→apply queue (#138), and this one — and the ore effect is untouched by every one of them. It still reproduces at precision 1.000 with no surviving mechanism. The notes now say so explicitly, so the next person does not go looking for a fourth candidate on an empty list.

Verification

pnpm run verify green — 1534 app + 13 worker + 3 container tests, 0 warnings, exit 0. Documentation only; no code, fixture or test changes.

🤖 Generated with Claude Code

https://claude.ai/code/session_012VRsPwmSwjnFKVSS6jx9Mo

wormeyman and others added 3 commits August 4, 2026 09:07
…#84)

wip: banner added after #139 lands, to keep the UPDATE numbering contiguous.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012VRsPwmSwjnFKVSS6jx9Mo
…empty

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012VRsPwmSwjnFKVSS6jx9Mo
@wormeyman
wormeyman merged commit 194295f into main Aug 4, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant