Bind non-direct infrastructure collection helpers
This commit is contained in:
parent
cf2e6cb6ad
commit
647c0e9265
3 changed files with 32 additions and 5 deletions
|
|
@ -2919,6 +2919,13 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
|
|||
`0x0048dcf0` after restoring one shared owner-local dword into the `0x90/0x94` lane. That means
|
||||
the `0x38a5` side-buffer seam is now a proven direct upstream feed into the child-stream restore
|
||||
owner rather than only a candidate cache or serializer-side neighbor.
|
||||
The collection helpers above that handoff are bounded now too: `0x00518140` resolves a non-direct
|
||||
live entry through the tombstone bitset and returns the first dword of a `12`-byte row from
|
||||
`[collection+0x3c]`, while `0x00518680` loads the non-direct collection header, tombstone bitset,
|
||||
and live-id-bound-scaled `12`-byte tables before `0x00493be0` starts iterating. So the remaining
|
||||
infrastructure mapping problem is no longer “which generic collection helper is involved?” but
|
||||
which fields inside those `12`-byte live-entry rows drive the child-count stream, saved
|
||||
primary-child ordinal stream, and per-child tagged callback payloads.
|
||||
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
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue