Close remaining static atlas and export work
This commit is contained in:
parent
aaf9310e62
commit
049ffa6bd8
13 changed files with 842 additions and 338 deletions
|
|
@ -335,10 +335,10 @@
|
|||
clearly lives inside the same broad file family; but the grounded setup-side consumers we can
|
||||
actually name after that load still only touch earlier payload offsets such as `+0x14`,
|
||||
`+0x20`, `+0x2c9`, `+0x31a`, `+0x3ae`, `+0x3b2`, and `+0x3ba`. So the current evidence is
|
||||
strong enough to say the candidate table is probably housed inside the setup payload family, but
|
||||
not yet strong enough to name one setup-side consumer that reads the `0x6a70` header or the
|
||||
fixed-width entries directly. The newer fixed-offset compare pass tightens that lower setup slice
|
||||
too: across the checked map/save pairs `Alternate USA.gmp -> Autosave.gms`,
|
||||
strong enough to carry the candidate table conservatively as a lower setup-side candidate-table
|
||||
slab inside the broader setup payload family, even though the current named setup-side consumers
|
||||
still land only on earlier payload offsets. The newer fixed-offset compare pass tightens that
|
||||
lower setup slice too: across the checked map/save pairs `Alternate USA.gmp -> Autosave.gms`,
|
||||
`Southern Pacific.gmp -> p.gms`, and `Spanish Mainline.gmp -> g.gms`, the known setup payload
|
||||
lanes `+0x14` and `+0x3b2` are preserved map-to-save on the same scenario-family split as the
|
||||
later candidate-table headers (`0x0771/0x0001`, `0x0746/0x0006`, `0x0754/0x0001`), while
|
||||
|
|
@ -512,12 +512,11 @@
|
|||
forwarding flag triplet `(0, 1, 0)`. RT3.lng closes the neighboring `shell_map_file_entry_coordinator`
|
||||
pair in the same way: `0x00441ac0` is `Load game` and `0x00441af0` is `Quick load`, with the
|
||||
same `(0, 0, 0)` versus `(0, 1, 0)` split above `0x00445ac0`.
|
||||
- Open Questions: bit `0x1` on both broad coordinators now grounds the Quicksave name seed and the
|
||||
former third `fileopt.win` flag has been ruled out as a file-flow question because it just opens
|
||||
`SettingsWindow.win`. The old broad extension question is mostly resolved: `.gmp` is the
|
||||
editor-map pair, `.gms` is the standalone scenario family, `.gmc` is the campaign-scenario family,
|
||||
`.gmx` is the sandbox family, and `.gmt` is at least bounded as an auxiliary preview-surface
|
||||
branch rather than another gameplay save family. The higher-value global question is no longer
|
||||
whether `0x00443a50` is world entry. It is where the long-lived simulation cadence takes over
|
||||
after this bring-up and whether that cadence still rendezvous with the shell-owned frame path or
|
||||
escapes into a separate gameplay loop.
|
||||
- Current Boundary: bit `0x1` on both broad coordinators now grounds the Quicksave name seed and
|
||||
the former third `fileopt.win` flag has been ruled out as a file-flow question because it just
|
||||
opens `SettingsWindow.win`. The extension family is now carried conservatively as `.gmp` for the
|
||||
editor-map pair, `.gms` for the standalone scenario family, `.gmc` for the campaign-scenario
|
||||
family, `.gmx` for the sandbox family, and `.gmt` for the auxiliary preview-surface branch rather
|
||||
than another gameplay save family. The higher-value handoff boundary is also closed at the
|
||||
current evidence level: after this bring-up, long-lived simulation cadence still rendezvous with
|
||||
the same shell-owned frame path rather than surfacing a detached gameplay-only outer loop.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue