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

Map infrastructure child constructor mode families

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-18 15:36:06 -07:00
commit 38546f781e
3 changed files with 61 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

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

@ -3070,6 +3070,19 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
same child payload fields that `0x004559d0` later serializes. So the remaining infrastructure
problem is which chooser branches feed `0x00490960` which stem/selector tuples for each
grounded save-side class, not where the child payload lanes come from at all.
One direct branch is grounded now too: the repeated chooser calls at
`0x004a2eba/0x004a30f9/0x004a339c` all feed `0x00490960` with mode arg `0x0a` and stem arg
`0x005cb138 = BallastCapDT_Cap.3dp`, so they bypass the selector-copy block at `0x004909e2` and
go straight into fresh child allocation/seeding. That means the remaining source-side mapping
problem is no longer generic BallastCap coverage; it is the other constructor branches,
especially the ones with mode `< 4` that actually populate the selector-byte copy block.
The broader mode family is grounded now too: a wider static callsite sweep shows mode `0x0b`
with fixed `TrackCapDT_Cap.3dp` / `TrackCapST_Cap.3dp`, mode `0x03` with
`OverpassST_section.3dp`, mode `0x02` with decoded tunnel table stems plus zero-stem fallbacks,
and mode `0x01` with decoded bridge table stems plus zero-stem fallbacks. So the remaining
infrastructure problem is no longer “what does `0x00490960` build?” but “how do those grounded
mode families collapse into the save-side compact-prefix/name-pair classes, especially the
already-grounded bridge-only `0x0002/0xff` class and BallastCap `0x0055/0x00` class?”.
The smaller attach helper `0x00490a3c` is now bounded too: it conditionally allocates one
`Infrastructure` child from a caller-supplied payload stem, attaches it to the current owner, and
then seeds three caller-supplied position lanes through `0x00539530` and `0x0053a5b0`. The

16
docs/rehost-queue.md
View file

@ -92,6 +92,22 @@ Working rule:
`0x00539530/0x0053a5b0`, and can cache it as primary child in `[this+0x248]`. The remaining
problem is no longer “where do the child payload lanes come from?” but “which chooser branches
feed `0x00490960` which caller stem and selector tuple for each grounded save-side class?”.
- One direct branch is grounded now too: the repeated chooser calls at
`0x004a2eba/0x004a30f9/0x004a339c` all feed `0x00490960` with mode arg `0x0a` and stem arg
`0x005cb138 = BallastCapDT_Cap.3dp`, which means they bypass the selector-copy block at
`0x004909e2` and go straight into fresh child allocation/seeding. So the remaining source-side
mapping problem is no longer generic BallastCap coverage; it is the other constructor branches,
especially the ones with mode `< 4` that actually populate the selector-byte copy block.
- The broader mode family is grounded now too. A wider static callsite sweep shows:
- mode `0x0b` with fixed `TrackCapDT_Cap.3dp` / `TrackCapST_Cap.3dp`
- mode `0x03` with `OverpassST_section.3dp`
- mode `0x02` with decoded tunnel table stems plus zero-stem fallbacks
- mode `0x01` with decoded bridge table stems plus zero-stem fallbacks
So the remaining infrastructure question is no longer “what does `0x00490960` build?” but “how
do those grounded mode families collapse into the save-side compact-prefix/name-pair classes,
especially the already-grounded bridge-only `0x0002/0xff` class and BallastCap `0x0055/0x00`
class?”.
- The sibling `0x00490200` is tighter now too: it reads the seeded lanes
`[this+0x206/+0x20a/+0x20e]` back through the live route collection at `0x006cfca8`, compares
them against the current owner using `[this+0x216/+0x218/+0x201/+0x202]`, and behaves like a