jan/rrt
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Bind infrastructure live-entry walk semantics

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-18 13:43:04 -07:00
commit a899622070
3 changed files with 23 additions and 7 deletions
Download patch file Download diff file Expand all files Collapse all files

9
docs/control-loop-atlas/runtime-roots-camera-and-support-families.md
View file

@ -2924,8 +2924,13 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
`[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.
how those helpers compose in the actual load loop: `0x00493be0` now reads as an
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.
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