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

Bound Tier2 stock BuildingType remap seam

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-19 14:45:57 -07:00
commit 58e9effb83
2 changed files with 41 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -1263,6 +1263,25 @@
and `0x005b7a6f` is just a helper-side child allocation. The only candidate-family store in
this strip that still matters to Tier-2 is `0x00419559`, and that one is only the later clone
pass stamping the chosen seed-row id onto the new row.
The `Port00` / `Warehouse00` name seam is narrower than that clone pass now too. Direct
recovery shows `0x00419680` constructing `gpdBuildingTypeDB` at `0x0062b2fc` by storing
vtable `0x005c9718`, and the surrounding `.rdata` descriptor at `0x005c9718` is the `%1*.bty`
table `{ 0x00416950, 0x00416ce0, 0x004168e0, "%1*.bty", ... }`. The ordinary DB load path at
`0x0044431c` calls vtable slot `+0x04 = 0x00416ce0`, while `0x00416950` walks live rows and
calls slot `+0x08 = 0x004168e0` as the per-entry cleanup path. Inside `0x00416ce0`, the stock
building-type loader rewrites only the bare source names `port` (`0x005c8f94`) and `warehouse`
(`0x005c8e4c`) to `Port00` (`0x005c96a0`) and `Warehouse00` (`0x005c9694`) before scanning the
live candidate collection `0x0062b268`; when it finds the matching candidate row,
`0x00416ded` seeds `[row+0x173]` from that live candidate row id before re-entering
`0x00518900`. So the remaining Tier-2 source question is no longer a hidden late writer for the
`00` names themselves. That remap is already owned by the stock `.bty` load callback, leaving
the row-family choice and later bank-selection problem above it as the active frontier.
The checked-in stock source report reinforces that boundary too:
`artifacts/exports/rt3-1.06/building-type-sources.json` still contains only the bare source
stems `port` and `warehouse`, while the numbered `port00..11` and `warehouse00..11` families
stay in `named_binding_comparison.binding_only_canonical_stems`. So the numbered Tier-2
families no longer belong under stock `BuildingTypes/*.bty` discovery either; they belong under
the scenario/live candidate-table projection seam above the now-grounded bare-name remap.
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