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 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 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. 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 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 stores at `0x004ecd42/0x004ecdaa` and `0x004ed5d5/0x004ed625` are only shell-side
portrait/string refresh helpers over a different id-keyed collection rooted through portrait/string refresh helpers over a different id-keyed collection rooted through

22
docs/rehost-queue.md
View file

@ -776,6 +776,28 @@ Working rule:
in this strip that still matters to Tier-2 is `0x00419559`, and it is simply the later clone in this strip that still matters to Tier-2 is `0x00419559`, and it is simply the later clone
pass stamping the chosen seed-row id onto the new row. So the queue no longer needs another pass stamping the chosen seed-row id onto the new row. So the queue no longer needs another
generic `+0x173` writer sweep before returning to the actual bank-byte owner. generic `+0x173` writer sweep before returning to the actual bank-byte owner.
The `Port00` / `Warehouse00` name mystery is narrower than that bank-byte owner 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", ... }`. That same vtable is
used by the ordinary DB load path at `0x0044431c`, which calls slot `+0x04 = 0x00416ce0`,
while `0x00416950` iterates 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, it seeds `[row+0x173]` from the live
candidate row id at `0x00416ded` and then re-enters `0x00518900`. So the queue no longer
needs a generic hidden late writer for the `00` names themselves: that remap is already owned
by the stock `.bty` load callback. The remaining Tier-2 source question is now the row-family
choice and later bank selection above that remap, especially the shifted `00` families
(`35/43` vs `10/18`) and the still-fixed `01..11` run families (`45..55` / `56..66`).
The checked-in stock source report agrees with that split too:
`artifacts/exports/rt3-1.06/building-type-sources.json` still shows only bare source stems
`port` and `warehouse`, while `port00..11` and `warehouse00..11` stay in
`named_binding_comparison.binding_only_canonical_stems`. So the queue no longer needs more
stock `BuildingTypes/*.bty` discovery for the numbered families either; the remaining `01..11`
source work belongs under scenario/live candidate-table projection and row-family choice above
the already-grounded bare-name remap.
The direct `+0xba/+0xbb` writer census is narrower now too. The obvious newly surfaced stores 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 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 refresh helpers: they walk a separate id-keyed collection through `0x0053f830`, free and