mirror of
https://github.com/RetroPortingToolKit/psxrecomp
synced 2026-10-28 10:59:16 -04:00
Alex Vanderveen
1102d42022
Launching from an external frontend with disc 2 or 3 chosen opened the game on disc 1 every time, and the launcher preselected disc 1 with it. settings.toml carried the right answer: [disc] path = ".../Final Fantasy VII (USA) (Disc 2).cue" with no `selected` key. The frontend writes the index only when it can work out the roster position, and it compares its stored choice path to the disc path exactly -- a .cue/.bin or normalisation difference misses, so it writes `path` alone and leaves the index out. The resolver then treated a MISSING key as selected = 1 and did what it was designed to do for a stale path: overrode disc 2 back to disc 1. `path` alone selected a disc correctly before the index existed, so this was a regression introduced with the index, not a pre-existing gap. A new field may add a way to choose a disc; it must not take away the old one. Now the index decides only when it is present. Absent it, the path decides and the index is derived from it (stem-compared, because everything downstream has been through normalize_disc_path_for_launch, which swaps a .cue for its .bin -- exactly the drift that made the frontend's own match miss). An off-roster path is not evidence for any disc and leaves the default alone. Verified all three ways against the real install's state: path=disc2 with no index boots SCUS-94164 and the launcher preselects Disc 2; path=disc2 with selected=3 still boots SCUS-94165, so an explicit index keeps overriding a stale path; the roster-derived index keeps a later save writing a consistent pair. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0194TYJAqgyG9a9PJe9uUcgQ