Tighten infrastructure chooser selector boundaries
This commit is contained in:
parent
3ae6431f74
commit
bb91dc1611
3 changed files with 57 additions and 4 deletions
|
|
@ -168,11 +168,23 @@ Working rule:
|
|||
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.
|
||||
- Reconstruct the save-side region record body on top of the newly corrected non-direct tagged
|
||||
region seam (`0x5209/0x520a/0x520b`, stride hint `0x06`, `Marker09` record stems) now that the
|
||||
`0x55f3` payload is known to be fully consumed by the embedded profile collection on grounded
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue