mirror of
https://github.com/RetroPortingToolKit/psxrecomp
synced 2026-10-26 02:11:36 -04:00
d53742310d
Triage of Tomba2Recomp GH issue #1 exposed three ways a release exe behaves differently on the build machine than on every user machine: - DEFAULT_BIOS_PATH baked an ABSOLUTE build-tree path into the binary, so promoted/release exes silently load the builder's BIOS wherever that path exists and the clean-install picker flow is never exercised where releases are validated. runtime.cmake now refuses absolute values (loud configure warning, converts to the relative default); dev checkouts keep prompt-free boots via a new resolve_bios_path rung that walks exe-dir ancestors for psxrecomp-v4/<relative>, a layout only dev trees have. - A settings.toml with a TOML syntax error was silently discarded wholesale (user's renderer choice, BIOS/disc paths - everything), and the next launcher save then overwrote the file with defaults. load_user_settings now reports parse_error; the runtime preserves the broken file as settings.toml.bad and warns via message box + stderr. - package_release.ps1 gains guards: fail packaging if the staged exe contains a drive-letter absolute SCPH1001.BIN path, if the stage carries BIOS/disc/save/sidecar files (SCPH*.BIN, *.cue, *.iso, *.mcd, bios.cfg, disc.cfg, settings.toml, keybinds.ini, overlay_captures.json), or if saves/ is non-empty. Verified: rebuilt Tomba2 against this tree - configure warning fires on the absolute arg, strings scan of the exe finds no drive-letter BIOS path, and a boot with no [bios] setting and no bios.cfg resolves the BIOS through the psxrecomp-v4 dev rung. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>