fix(saves): every Windows build shares one save folder, and the Start menu shortcut survives launcher updates #43

Merged

HumanBean merged 1 commit from HumanBean/LongshotLauncher:fix/shared-saves into main

2026-11-13 15:40:17 +00:00

HumanBean commented

2026-11-13 15:38:18 +00:00

Owner

Why

Players on Windows are losing their saves when they update Longshot or move to the launcher: each Windows build kept its own saves in its own folder, so a new version started empty unless Move my saves ran, and picking "Start with no saves" once turned it off for every later update. Players also report that the launcher's Start menu shortcut is gone after the launcher updated itself.

What changed

One save folder for every build, on Windows as on Linux.

Saves live in %APPDATA%\Longshot\save\<user id>\ on Windows (SaveEnvironment.LongshotUser; a portable launcher keeps them in LongshotLauncher-data\user\). Linux is unchanged: $XDG_DATA_HOME/longshot.
The launcher starts every Windows build with --user <that folder> (GamePlay.StartInfo). Every Windows build of the game already takes --user (host/hos_main.c), the ones from before this change too, so no game release is needed for launcher starts.
Saves from before are brought in by themselves (Saves.Gather), when the window opens and before a game starts (Play, --play, the shortcuts):
- from every build in the list, every Longshot game folder in the builds folder (a version an update already replaced is no longer listed, but its saves are still there: the players hit by the bug), and the 2.x Builder's %USERPROFILE%\Games\Longshot\user (not for a portable launcher);
- the save with the newest progress of them all, the shared one included, is kept (its newest progress.sav; a tie keeps the shared one, so a save an old build just made, with nothing played, never replaces it);
- every one is backed up whole first, to oot-save-backups\gather-<stamp>\<game folder name>;
- nothing is deleted: each old save folder is renamed save.moved-<stamp>, so the game no longer finds it;
- a user or save folder that is a link (a player's synced folder, or the shared one itself) is left alone;
- the kept save's mouse_sens.txt and present.txt come along when the shared folder has none;
- never while Longshot runs (the next start tries again); a failure changes nothing and the home says why. The home says which save was kept and where the backup is, at start or after Play.
Removed, since there is nothing left to copy between builds: Copy saves from another build on the Saves page and its build picker, Move my saves in the wizard's second step (and the moveSaves setting, which was what made "Start with no saves" stick), the move on the Ready screen, the "its saves go with it" warning when deleting a build, and the saves count on each version's row. The Saves page, the wizard's saves card and the delete dialog now read the same on Windows as on Linux. A settings.json with moveSaves is still read.
Hookshot import goes into the shared save on both systems, and no longer needs a build first on Windows.

The Start menu shortcut after the launcher's own update. Installer.Refresh: at the first start of another launcher version (the Apps & features entry names another one), an installed launcher makes its Start menu shortcut again, and the Longshot shortcuts it made that are there. Once per version: a shortcut the player deleted stays deleted, and the entry is written after the shortcut, so one that could not be made is tried again at the next start. The update moves the running program aside to LongshotLauncher.exe.old before the new one takes its name, and Windows' shortcut tracking can follow it there; the next update deletes that .old, and the Start menu drops a shortcut to nothing. I couldn't confirm that this is the exact cause without a Windows PC; making the shortcut again on each new version fixes it whatever the cause, and costs one hidden PowerShell start per update.

Docs: docs/saves.md (where saves are, "Saves from before (Windows)"), README.

Follow-up, not in this PR: Longshot's game, started on its own (bin\longshot.exe double-clicked rather than through the launcher), still uses its folder's user\. The launcher brings such saves in at its next start (newest wins), so nothing is lost, but a Longshot PR should make %APPDATA%\Longshot the game's own default on Windows, as ~/.local/share/longshot is on Linux, and update Longshot's docs/saves.md and docs/updates-and-saves.md.

Testing

python -I tests/test_launcher_core.py: 658 checks passed (635 on main). New checks: the shared folder on Windows and Linux and a portable one; --user on Windows only; import into the shared save; Hookshot import with no build; Saves.Gather: the old folders found once each, none on Linux, never the shared one, nothing while Longshot runs (an emulator running doesn't stop it), the newest kept, every one backed up, the old ones renamed aside, done once, an old build saving again later (newer wins, shared one backed up), an older one (shared kept), a swap that fails half-way (everything as it was), a shared save left aside by a gather cut short (backed up), a save with nothing played (never wins), a linked save folder (left alone), mouse_sens.txt brought along; Installer.Refresh: made again after an update, left alone otherwise (a deleted shortcut stays deleted), retried after a failure; an old settings.json with moveSaves.
python -I tests/test_release.py: 28 tests OK.
dotnet build App/LongshotLauncher.csproj -c Release: 0 errors, no new warning (the existing TextBox.Watermark one).
Self-review by a separate agent on the diff; its findings (progress-only comparison, links, the set-aside save, per-player files, an uncaught exception on Play, the shortcut's retry, stale README lines) are fixed here.
Linux, CachyOS: builds and checks only.
Not run on Windows yet: the gather on a real PC with a 2.x Builder folder and two launcher versions, a game started with --user, and the Start menu shortcut after a launcher update. A test request asks for it.

Screenshots

None yet: what changes on screen is Windows' Saves page (no build picker, no From another version…), the wizard's saves card and the delete dialog, which now look as Linux's already do. The Windows test run will add them.

🤖 Generated with Claude Code

## Why Players on Windows are losing their saves when they update Longshot or move to the launcher: each Windows build kept its own saves in its own folder, so a new version started empty unless *Move my saves* ran, and picking "Start with no saves" once turned it off for every later update. Players also report that the launcher's Start menu shortcut is gone after the launcher updated itself. ## What changed **One save folder for every build, on Windows as on Linux.** - Saves live in `%APPDATA%\Longshot\save\<user id>\` on Windows (`SaveEnvironment.LongshotUser`; a portable launcher keeps them in `LongshotLauncher-data\user\`). Linux is unchanged: `$XDG_DATA_HOME/longshot`. - The launcher starts every Windows build with `--user <that folder>` (`GamePlay.StartInfo`). Every Windows build of the game already takes `--user` (`host/hos_main.c`), the ones from before this change too, so no game release is needed for launcher starts. - **Saves from before are brought in by themselves** (`Saves.Gather`), when the window opens and before a game starts (Play, `--play`, the shortcuts): - from every build in the list, every Longshot game folder in the builds folder (a version an update already replaced is no longer listed, but its saves are still there: the players hit by the bug), and the 2.x Builder's `%USERPROFILE%\Games\Longshot\user` (not for a portable launcher); - the save with the newest progress of them all, the shared one included, is kept (its newest `progress.sav`; a tie keeps the shared one, so a save an old build just made, with nothing played, never replaces it); - every one is backed up whole first, to `oot-save-backups\gather-<stamp>\<game folder name>`; - nothing is deleted: each old `save` folder is renamed `save.moved-<stamp>`, so the game no longer finds it; - a `user` or `save` folder that is a link (a player's synced folder, or the shared one itself) is left alone; - the kept save's `mouse_sens.txt` and `present.txt` come along when the shared folder has none; - never while Longshot runs (the next start tries again); a failure changes nothing and the home says why. The home says which save was kept and where the backup is, at start or after Play. - Removed, since there is nothing left to copy between builds: *Copy saves from another build* on the Saves page and its build picker, *Move my saves* in the wizard's second step (and the `moveSaves` setting, which was what made "Start with no saves" stick), the move on the Ready screen, the "its saves go with it" warning when deleting a build, and the saves count on each version's row. The Saves page, the wizard's saves card and the delete dialog now read the same on Windows as on Linux. A `settings.json` with `moveSaves` is still read. - Hookshot import goes into the shared save on both systems, and no longer needs a build first on Windows. **The Start menu shortcut after the launcher's own update.** `Installer.Refresh`: at the first start of another launcher version (the Apps & features entry names another one), an installed launcher makes its Start menu shortcut again, and the *Longshot* shortcuts it made that are there. Once per version: a shortcut the player deleted stays deleted, and the entry is written after the shortcut, so one that could not be made is tried again at the next start. The update moves the running program aside to `LongshotLauncher.exe.old` before the new one takes its name, and Windows' shortcut tracking can follow it there; the next update deletes that `.old`, and the Start menu drops a shortcut to nothing. I couldn't confirm that this is the exact cause without a Windows PC; making the shortcut again on each new version fixes it whatever the cause, and costs one hidden PowerShell start per update. **Docs:** `docs/saves.md` (where saves are, "Saves from before (Windows)"), README. **Follow-up, not in this PR:** Longshot's game, started on its own (`bin\longshot.exe` double-clicked rather than through the launcher), still uses its folder's `user\`. The launcher brings such saves in at its next start (newest wins), so nothing is lost, but a Longshot PR should make `%APPDATA%\Longshot` the game's own default on Windows, as `~/.local/share/longshot` is on Linux, and update Longshot's `docs/saves.md` and `docs/updates-and-saves.md`. ## Testing - `python -I tests/test_launcher_core.py`: 658 checks passed (635 on `main`). New checks: the shared folder on Windows and Linux and a portable one; `--user` on Windows only; import into the shared save; Hookshot import with no build; `Saves.Gather`: the old folders found once each, none on Linux, never the shared one, nothing while Longshot runs (an emulator running doesn't stop it), the newest kept, every one backed up, the old ones renamed aside, done once, an old build saving again later (newer wins, shared one backed up), an older one (shared kept), a swap that fails half-way (everything as it was), a shared save left aside by a gather cut short (backed up), a save with nothing played (never wins), a linked `save` folder (left alone), `mouse_sens.txt` brought along; `Installer.Refresh`: made again after an update, left alone otherwise (a deleted shortcut stays deleted), retried after a failure; an old `settings.json` with `moveSaves`. - `python -I tests/test_release.py`: 28 tests OK. - `dotnet build App/LongshotLauncher.csproj -c Release`: 0 errors, no new warning (the existing `TextBox.Watermark` one). - Self-review by a separate agent on the diff; its findings (progress-only comparison, links, the set-aside save, per-player files, an uncaught exception on Play, the shortcut's retry, stale README lines) are fixed here. - Linux, CachyOS: builds and checks only. - **Not run on Windows yet**: the gather on a real PC with a 2.x Builder folder and two launcher versions, a game started with `--user`, and the Start menu shortcut after a launcher update. A test request asks for it. ## Screenshots None yet: what changes on screen is Windows' Saves page (no build picker, no *From another version…*), the wizard's saves card and the delete dialog, which now look as Linux's already do. The Windows test run will add them. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

HumanBean added 1 commit

2026-11-13 15:38:19 +00:00

fix(saves): one save folder for every build on Windows, as on Linux; the Start menu shortcut survives the launcher's update

CI / Compile and test (pull_request) Has been skipped

Details

CI / Conventional Commit title (pull_request) Successful in 7s

Details

f93e00e450

Windows builds kept their saves each in its own folder, so an update or a new version started empty unless Move my saves
ran, and "Start with no saves" turned it off for good. The launcher now starts every Windows build with --user
%APPDATA%\Longshot and brings the saves builds kept before (and the 2.x Builder's) into it once, keeping the newest
progress after backing them all up. An installed launcher makes its Start menu shortcut again at the first start of a
new version.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

HumanBean changed title from ~~WIP: fix(saves): every Windows build shares one save folder, and the Start menu shortcut survives launcher updates~~ to fix(saves): every Windows build shares one save folder, and the Start menu shortcut survives launcher updates

2026-11-13 15:40:11 +00:00

HumanBean merged commit 9e0d2a8456 into main

2026-11-13 15:40:17 +00:00

HumanBean deleted branch fix/shared-saves

2026-11-13 15:40:18 +00:00

HumanBean referenced this pull request from a commit

2026-11-13 15:40:19 +00:00

fix(saves): every Windows build shares one save folder, and the Start menu shortcut survives launcher updates (#43)