Narrow region restore handoff to vtable callback
This commit is contained in:
parent
12dad6399f
commit
a4101b73fc
2 changed files with 43 additions and 2 deletions
|
|
@ -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 table’s 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
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue