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

Ground infrastructure material selector roles

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-18 15:15:52 -07:00
commit d8e6eac810
3 changed files with 34 additions and 7 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

@ -3024,6 +3024,14 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
selector problem is below that top-level split: the exact `[this+0x219]/[this+0x251]` values
that choose the decoded family entries and how those values surface in the save-side `0x38a5`
classes.
Those material selectors are grounded now too: within the bridge branch, `[this+0x219]`
selects `steel`, `stone`, `suspension`, or `wood`, with value `2` taking the special
suspension-cap path through `[this+0x252]`; within the tunnel branch, `[this+0x251]` selects
`brick` versus `concrete`, while bit `0x20` chooses cap versus section by switching between the
base and `+0x8` table entry families. So the remaining infrastructure selector problem is no
longer “what do these bytes mean?” but “how do those already-grounded selector values surface in
the save-side `0x38a5` classes, especially the `0x0002 / 0xff` bridge class and the
`0x0055 / 0x00` BallastCap class?”.
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`.