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

Correlate infrastructure prelude candidate classes

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-18 14:51:27 -07:00
commit 5219d5a9ce
3 changed files with 187 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -2992,6 +2992,14 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
`TrackCapST_Cap.3dp / Infrastructure` row with compact prefix `0xff0000ff / 0x0001 / 0xff`.
So the next infrastructure pass should target the `BallastCap` outlier family first instead of
spending time on the already-dominant bridge-section class.
The candidate-pattern classes are explicit now too: `0x0055 / 0x00` is a pure
`BallastCapST_Cap.3dp / Infrastructure` class across `18` rows, always preceded by a zero-length
prior profile span, while `0x0002 / 0xff` is a pure
`BridgeSTWood_Section.3dp / Infrastructure` class across `18` rows with dominant prior profile
span `0x06` (`10` rows). So the next infrastructure pass should split its owner questions the
same way: treat `0x0055 / 0x00` as a `BallastCap`-specific boundary artifact class, and treat
`0x0002 / 0xff` as the likely bridge-specific two-child / clone-path class above
`0x0048a1e0/0x0048dcf0`.
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