Bind non-direct infrastructure collection helpers

This commit is contained in:
Jan Petykiewicz 2026-04-18 13:41:21 -07:00
commit 647c0e9265
3 changed files with 32 additions and 5 deletions

View file

@ -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