Tighten infrastructure chooser selector boundaries

This commit is contained in:
Jan Petykiewicz 2026-04-18 15:13:24 -07:00
commit bb91dc1611
3 changed files with 57 additions and 4 deletions

View file

@ -3017,11 +3017,23 @@ The low helper strip beneath that shared family is tighter now too: `0x0052ecd0`
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.
The top-level chooser meaning is grounded now too: within those paired DT/ST siblings,
`[this+0x226]==1` routes the bridge families, `[this+0x226]==2` routes the tunnel families, and
`[this+0x226]==3` routes the overpass/ballast family, while bit `0x20` in `[this+0x24c]`
selects the cap-oriented side over the section-oriented side. So the remaining infrastructure
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.
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 current real-save corpus also narrows the active side further: grounded `q.gms`, `p.gms`,
`g.gms`, and `nom.gms` only expose `ST`-family side-buffer names, while classic `rt3/` saves in
this workspace currently expose no `0x38a5` side-buffer seam at all. So the save-driven part of
the next infrastructure slice should assume it is exercising the `ST` chooser sibling directly,
with `DT` still grounded statically but not yet exercised by the current save corpus.
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