jan/rrt
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Classify zero-family stock alias clusters

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-19 15:31:02 -07:00
commit b946e69bd0
4 changed files with 94 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

6
docs/control-loop-atlas/map-and-scenario-content-load.md
View file

@ -96,6 +96,12 @@
`Distillery x2`, `Toolndie x2`). So the next load-side source-selection pass should bias toward
that `0x5e` alias-root lane when testing why the later chooser seeds only part of the stock
family into the numbered Tier-2 bank.
The same `name_0x5e` dword-family summary now also says the current residue is still stock-side:
`MunitionsFactory` belongs to a zero-valued `WeaponsFactory` alias cluster with
`Electric Plant`, `Fertilizer Factory`, `Nuclear Power Plant`, `Oil Well`, and `Weapons
Factory`. So the next load-side source-selection pass should treat the open question as one of
cluster choice inside the wider stock corpus, not as a jump from stock rows to some unrelated
non-stock family.
The fixed
tail is explicit now too: `0x00444dd0` writes one direct dword from
`[world+0x19]`, one zeroed `0x1f4`-byte slab under `0x32cf`, closes the package, derives the

8
docs/control-loop-atlas/runtime-roots-camera-and-support-families.md
View file

@ -1339,6 +1339,14 @@
stronger stock-family clue than the direct-name lanes, and keep the explicit non-overlap residue
(`MunitionsFactory/MunitionsFactory x1`) separate instead of folding it into the recovered
industrial/commercial subset.
That non-overlap residue is grounded against the wider stock corpus now too. The same checked-in
`name_0x5e` dword-family summary shows `MunitionsFactory` sits in a zero-valued
`WeaponsFactory` alias cluster (`Electric Plant`, `Fertilizer Factory`, `Munitions Factory`,
`Nuclear Power Plant`, `Oil Well`, `Weapons Factory`) rather than outside stock assets
entirely. So the remaining Tier-2 chooser/source-selection frontier is no longer “stock vs
non-stock”; it is which stock alias-root cluster is selected and why later clone/replay paths
prefer the nonzero `0x000001f4` cluster while the peer-site residue can still surface a
zero-family `WeaponsFactory`-side root.
The direct `+0xba/+0xbb` writer census now rules out a broad false lead too. The obvious new
stores at `0x004ecd42/0x004ecdaa` and `0x004ed5d5/0x004ed625` are only shell-side
portrait/string refresh helpers over a different id-keyed collection rooted through