Bind infrastructure live-entry directory layout

This commit is contained in:
Jan Petykiewicz 2026-04-18 13:44:59 -07:00
commit 68a2a3401e
3 changed files with 23 additions and 9 deletions

View file

@ -2928,9 +2928,11 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
ordinal-to-live-id-to-payload-pointer walk through `0x00518380(ordinal, 0)` then
`0x00518140(live_id)`. That narrows the remaining infrastructure mapping problem further:
the first dword of each `12`-byte live-entry row is already spoken for as the per-entry payload
pointer, so the next unknowns are which remaining dwords in that row still matter and how the
payload streams they point to align with the save-side `0x55f1` name-pair groups and compact
prefix regimes.
pointer, and `0x005181f0/0x00518260` now also read as the live-entry unlink/link owners that use
the same rows as `(payload pointer, previous live id, next live id)` directory triplets. So the
next unknowns are no longer inside that row layout itself; they are in the payload streams those
rows point at, and how those streams align with the save-side `0x55f1` name-pair groups and
compact prefix regimes.
The child loader family is explicit now too: local `.rdata` at `0x005cfd00` proves the
`Infrastructure` child vtable uses the shared tagged callback strip directly, with
`+0x40 = 0x00455fc0`, `+0x48 = 0x00455870`, and `+0x4c = 0x00455930`. So the remaining

View file

@ -60,10 +60,12 @@ Working rule:
while `0x00518680` loads that non-direct table family before `0x00493be0` starts iterating, and
`0x00493be0` itself now reads as an ordinal-to-live-id-to-payload-pointer walk through
`0x00518380(ordinal, 0)` then `0x00518140(live_id)`. So the next infrastructure question is no
longer “which row owns the payload pointer?” but which remaining dwords in those `12`-byte
live-entry rows still matter after the first dword resolves the per-entry payload pointer, and
longer “which row owns the payload pointer?”. Direct disassembly of `0x005181f0/0x00518260` now
also treats those `12`-byte rows as a live-entry directory with
`(payload pointer, previous live id, next live id)`, so the next infrastructure question is only
how those payload streams align with the embedded `0x55f1` name-pair groups and compact-prefix
regimes.
regimes, and which tagged values inside each payload stream become the child count, optional
primary-child ordinal, and per-child callback sequence that `0x0048dcf0` consumes.
- The child loader identity is closed now too: local `.rdata` at `0x005cfd00` proves the
`Infrastructure` child vtable uses the shared tagged callback strip directly, with
`+0x40 = 0x00455fc0`, `+0x48 = 0x00455870`, and `+0x4c = 0x00455930`. So the remaining