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

Decode infrastructure chooser asset families

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-18 15:09:08 -07:00
commit 3ae6431f74
3 changed files with 78 additions and 27 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -3001,13 +3001,27 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
`0x0002 / 0xff` as the grounded save-side bridge-specific two-child candidate class above
`0x0048a1e0/0x0048dcf0`, with the remaining unknown narrowed to the upstream chooser that emits
that class before the attach/rebuild path runs.
That upstream chooser is grounded now too: direct disassembly of `0x004a2c80..0x004a37de`
shows a dense infrastructure composition strip repeatedly calling `0x0048a1e0`, branching on
`[this+0x226]`, selector bytes `[this+0x219]/[this+0x251]`, bit `0x20` in `[this+0x24c]`, and
lookup tables `0x621a44..0x621a9c`, then routing follow-on through
`0x0048a340/0x0048f4c0/0x00490200/0x00490960`. So the remaining infrastructure question is no
longer “is there an upstream chooser?” but “which lookup-table families inside that chooser map
to the grounded `0x0002 / 0xff` bridge class and the `0x0055 / 0x00` BallastCap class?”.
That upstream chooser is grounded now too as paired siblings: direct disassembly shows
`0x004a2c80` routing the `DT` family and `0x004a34e0` routing the `ST` family, with both
repeatedly calling `0x0048a1e0`, branching on `[this+0x226]`, selector bytes
`[this+0x219]/[this+0x251]`, bit `0x20` in `[this+0x24c]`, and lookup tables `0x621a44..0x621a9c`,
then routing follow-on through `0x0048a340/0x0048f4c0/0x00490200/0x00490960`. So the remaining
infrastructure question is no longer “is there an upstream chooser?” but “how do the save-side
classes select the `DT` versus `ST` chooser sibling, and then which lookup-table families inside
that sibling map to the grounded `0x0002 / 0xff` bridge class and the `0x0055 / 0x00`
BallastCap class?”.
Those lookup tables are decoded now too: `0x621a44/0x621a54` feed `BridgeST` caps/sections,
`0x621a64` feeds `TunnelST` cap/section variants, `0x621a74/0x621a84` feed `BridgeDT`
caps/sections, and `0x621a94` feeds `TunnelDT` variants, while fixed literals
`0x5cb138/0x5cb150` are `BallastCapDT/ST` and `0x5cb168/0x5cb180` are `OverpassDT/ST`. So the
remaining infrastructure question is no longer table discovery; it is the selector-byte mapping
from `[this+0x219]/[this+0x251]/[this+0x252]` onto those decoded families and then onto the
grounded `0x38a5` prefix classes.
One selector byte is partly grounded now too: when `[this+0x219]==2`, the chooser jump tables
stop using the general bridge families and instead route `[this+0x252]` through fixed
`BridgeDT/BridgeST` suspension-cap literals for `R10`, `L10`, `12`, `14`, `16`, and `18`.
So the remaining infrastructure selector problem is mostly `[this+0x219]/[this+0x251]` family
choice plus the exact save-side class mapping for the BallastCap branch.
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