Decode infrastructure fixed policy lanes

This commit is contained in:
Jan Petykiewicz 2026-04-18 14:15:08 -07:00
commit 3c09482b71
3 changed files with 193 additions and 0 deletions

View file

@ -2952,6 +2952,14 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
infrastructure question is no longer whether a short trailing lane exists; it is how those
compact-prefix regimes and short flag-byte pairs feed the child-count / primary-child restore
state above `0x0048dcf0`.
The fixed policy lane is tighter now too: direct disassembly of
`0x00455870/0x00455930` shows the `+0x48/+0x4c` strip loading and serializing six `u32` lanes
from the fixed `0x55f2` chunk, forwarding them through `0x00530720` and `0x0052e8b0`. Grounded
`q.gms` save-side probes now show every embedded `0x55f2` row using the same trailing word
`0x0101` while the six dword lanes vary by asset row. So the remaining infrastructure question
is no longer whether `0x55f2` is a fixed-format child lane; it is which of those two dword
triplets correspond to the later child-count / primary-child restore state and which only seed
published anchor or position bands.
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