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

Bound infrastructure payload string fallbacks

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-18 13:52:18 -07:00
commit 1873db0b08
3 changed files with 51 additions and 33 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

@ -2937,9 +2937,12 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
cached bridge bands, opens `0x55f1`, parses three len-prefixed strings through `0x00531380`,
opens `0x55f2`, seeds the child through `0x00455b70`, dispatches slot `+0x48`, runs the local
follow-on `0x0052ebd0`, and then opens `0x55f3`. The widened save-side probe currently still
sees only two embedded `0x55f1` strings on grounded `q.gms`, so the remaining payload question is
whether that third parsed string is absent on ordinary saves, hidden behind different framing, or
only populated on a narrower infrastructure subset.
sees only two embedded `0x55f1` strings on grounded `q.gms`, but `0x00455b70` now makes that
result much less mysterious: it stores the three payload strings into `[this+0x206/+0x20a/+0x20e]`,
defaulting the second lane through a fixed literal when absent and defaulting the third lane back
to the first string when absent. So the remaining payload question is no longer “where is the
third string hiding?”; it is how the current dual-name save-side rows align with the full
payload-stream grouping and the later tagged value roles.
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