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

Bind world-region restore callback strip

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-18 13:18:10 -07:00
commit 2d2a83957f
3 changed files with 21 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -3058,8 +3058,11 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
`0x0056ae30` dispatches selector `3` over the active registry, `0x0056ae80` marks pending flag
`0x100` by key, `0x0056aeb0` closes the digital driver, and `0x0056aee0/0x0056af20` are the
constructor/destructor pair for that sibling service object. One other sibling table is no longer
anonymous either: local `.rdata` at `0x005c9a60` is the world-region record family, while the
smaller collection table at `0x005c9ae0` is the live region manager stored at `0x0062bae0`.
anonymous either: local `.rdata` at `0x005c9a28` is the actual world-region record-family vtable
root, while the smaller collection table at `0x005c9ae0` is the live region manager stored at
`0x0062bae0`. The same root now also resolves the restore-side virtual strip precisely:
`0x0041f5c0` is slot `+0x40`, `0x0041f650` is slot `+0x44`, `0x00455870` is slot `+0x48`, and
`0x00455930` is slot `+0x4c`.
Constructor-side evidence is the anchor here. `0x00421660` allocates one `0x389`-sized region
row, resolves the new record, and forwards into `0x00421200`, which seeds region id
`[region+0x23a]`, class `[region+0x23e]`, profile collection `[region+0x37f]`, name buffer

12
docs/rehost-queue.md
View file

@ -95,11 +95,13 @@ Working rule:
through `0x00455fc0` before rebuilding profile collection `[region+0x37f]`. So the next region
pass should ask whether `[region+0x276/+0x302/+0x316]` are restored directly inside that payload
load or rebuilt immediately after it, rather than treating “restore seam” as a generic unknown.
- Direct disassembly of `0x00455fc0` now answers part of that question: the shared loader clears and
reseeds the common `0x23a`-family string/scalar bands, then dispatches object vtable slot `+0x48`
and re-enters `0x0052ebd0`; it does not touch `[region+0x276/+0x302/+0x316]` directly. That
narrows the remaining restore target further to the world-region table’s region-specific
`+0x48` callback or the immediate post-load owner above it.
- Direct disassembly now closes that callback identity too: `0x0041f590/0x0041f5b0` prove the
world-region vtable root is `0x005c9a28`, so the `0x00455fc0` dispatch at slot `+0x48` lands on
`0x00455870` and the serializer sibling at `+0x4c` lands on `0x00455930`. Those two callbacks
only restore and serialize two triplet-like three-lane scalar bands through
`0x00531150/0x00531030` plus `0x00530720/0x0052e8b0`; they still do not touch
`[region+0x276/+0x302/+0x316]`. That means the remaining region restore target is now the later
owner that rebuilds those latches or the separate tagged body seam that persists them.
- Reconstruct the save-side placed-structure collection body on top of the newly grounded
`0x36b1/0x36b2/0x36b3` header seam so the blocked city-connection / linked-transit branch can
stop depending on atlas-only placed-structure and local-runtime refresh notes, especially the