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

Bind Tier2 names to setup payload rows

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-19 14:13:55 -07:00
commit 4e1023fb29
2 changed files with 17 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -1229,6 +1229,12 @@
every current shipped `.bca` stays zero at `0xb8..0xbb` except `MachineShop.bca`, which carries
the lone selector-window exception `(0x00, 0x80, 0x3f, 0x00)` on a `788`-byte row, while the
separate `backup/Bldg/*.bca` corpus stays fully zero there.
Direct map-payload inspection sharpens that split further. The current Tier-2 maps
`Louisiana.gmp`, `Dutchlantis.gmp`, and `South East USA.gmp` all already carry the literal
`Port00` / `Warehouse00` / `Port01` / `Warehouse01` names inside the shared setup payload at
stable offsets `0x6f77`, `0x7087`, `0x70cb`, and `0x7241`, while the same map corpus shows no
`MachineShop` string at all. So the live `PortNN` / `WarehouseNN` family now looks more like a
setup-payload candidate-table / source-row projection problem than a hidden alternate BCA stem.
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

14
docs/rehost-queue.md
View file

@ -739,6 +739,13 @@ Working rule:
`backup/Bldg/*.bca` corpus stays fully zero in that same window. So the queue head is narrower
again: explain whether the Machine Shop exception is part of the seeded Tier-2 family at all,
or recover the later projection seam that still has to account for the broader live divergence.
Direct map-payload inspection now sharpens that split further. The current Tier-2 maps
`Louisiana.gmp`, `Dutchlantis.gmp`, and `South East USA.gmp` all already carry the literal
`Port00` / `Warehouse00` / `Port01` / `Warehouse01` names inside the shared setup payload at
stable offsets `0x6f77`, `0x7087`, `0x70cb`, and `0x7241` respectively, while the same map
corpus shows no `MachineShop` string at all. That moves the queue head again: the live
`PortNN` / `WarehouseNN` family is now more plausibly a setup-payload candidate-table / source
row projection problem than a hidden stock-BCA stem problem.
The direct `+0xba/+0xbb` writer census is narrower now too. The obvious newly surfaced stores
at `0x004ecd42/0x004ecdaa` and `0x004ed5d5/0x004ed625` are only shell-side portrait/string
refresh helpers: they walk a separate id-keyed collection through `0x0053f830`, free and
@ -765,9 +772,10 @@ Working rule:
question is not “who writes the mysterious group id?” but “which source/live rows become the
first seeded rows that let `0x00412d70` propagate nonzero bank bytes within that family?”
So the honest next queue head is now one step earlier again:
recover the non-stock writer or restore-time projection owner that makes some live candidates
reach those later consumer strips with nonzero `[candidate+0xba/+0xbb]` beyond the lone
`MachineShop.bca` selector-window exception in the shipped `BuildingTypes/*.bca` corpus.
recover the setup-payload or restore-time projection owner that carries those static
`PortNN` / `WarehouseNN` rows into the live candidate clone families with nonzero
`[candidate+0xba/+0xbb]`, beyond the separate `MachineShop.bca` selector-window exception in
the shipped `BuildingTypes/*.bca` corpus.
kinds”; it is the smaller set of scenario-specific records where that sweep explicitly writes
`[event+0x7ef]` itself or a still-later owner does.
- two explicit trigger-kind materializations are now grounded inside that retagger: