Narrow region restore handoff to vtable callback

This commit is contained in:
Jan Petykiewicz 2026-04-18 13:09:52 -07:00
commit a4101b73fc
2 changed files with 43 additions and 2 deletions

View file

@ -90,6 +90,17 @@ Working rule:
`[region+0x25a/+0x25e] = 100.0f` and `[region+0x31b] = 1.0f`. That means the remaining queue item
is specifically post-construction restore or rebuild of the same latches, not their basic field
identity.
- The next restore-side target is explicit now too: the checked-in function map already grounds
`0x00421510` as the tagged region-collection load owner that dispatches each live region through
vtable slot `+0x40`, and `0x0041f5c0` as the per-record load slot that reloads the tagged payload
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 tables region-specific
`+0x48` callback or the immediate post-load owner above it.
- 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