fix(update): an update stays in its build's folder, and a new build's is named after its channel #104
No reviewers
Labels
No labels
area/build
area/install
area/saves
area/tooling
area/ui
area/updates
ci: approved
good first issue
gpu/amd
gpu/intel
gpu/nvidia
help wanted
kind
bug
kind
chore
kind
docs
kind
feature
kind
performance
kind
question
platform/linux
platform/steam-deck
platform/windows
priority
critical
priority
high
priority
low
risk
high
risk
low
risk
medium
status
blocked
status
confirmed
status
duplicate
status
invalid
status
needs-info
status
wontfix
ci: approved
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
MagicBeanDev/LongshotLauncher!104
Loading…
Reference in a new issue
No description provided.
Delete branch "HumanBean/LongshotLauncher:feat/update-in-place"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Every update built the new version into a new folder named after it and left the old one on the disk, so each update added a whole copy of the game (and moved the game's path, which the GPU driver's settings follow). This lands #57: an update now builds over its build in the same folder, and each new build gets its channel's folder (
stable,rc,nightly), so one build per channel is kept up to date in place.Supersedes #57: it's Victor's commit (authorship kept) with the review fixes from
review/pr57, rebased onto main, plus the fixes below for what landed since.What changed
From #57 (see its description for the details):
BuildRegistry.FolderOf: an update or a rebuild is built in its build's own folder; a new build goes inNewFolder, named after its channel (LauncherSettings.FolderFor), past folders other builds have or that hold other things.BuildRegistry.PickedFolder: step 2's folder picker rule, moved into Core so the tests reach it.BuildRegistry.Replace: a row named after its version takes the new version's name when the folder stays.Problems.GameRunning)..longshot_exefs/.longshot_romfs) is built in again, not passed over fornightly (2).New here, for what landed on main after #57:
BuildJob.FromreadReplaces.Versionlive, andReplacesets it to the new version first (Anarkkie's finding on #57). It's read once when the job is made.Seedno longer runsShaderCaches.Keepfrom a folder into itself; an update in place keepscache/where it is (logged). Keep still applies when the player moves an update to another folder in step 2. The README entry says so.SameGameFilesgives none when the build's own folder already holds the.nup's unpacked game files, so an update in place isn't pointed at another build's copy. The check that expected the other build there is updated, and the "never its own folder" case is still checked.scripts/forge.py login, its CONTRIBUTING.md step 2), and that itsprcommands are for Longshot only.Testing
Linux (CachyOS), .NET SDK 10.0.404.
python -I tests/test_launcher_core.py: 1203 checks passed (rebased on main @395578bf). With theSameGameFilesguard removed, the run stops at the new check.python -I tests/test_release.py: 29 tests, OK.dotnet build App/LongshotLauncher.csproj: 0 warnings, 0 errors.scripts/translations.py: the 5 missing texts per catalog are #78's and #87's, already on main.Not tested: no real update was run here (no game dump on this PC). Anarkkie's Windows run on #57 (nightly 148 to 153 in
builds/nightly, NVIDIA 3080 Ti) covers the in-place flow. Unrelated and already broken on main:tools/screenshotsdoesn't compile since #87 madeLauncherService.Gpusread-only, so there's no screenshot of the Settings hint.Follow-ups (from #57): deleting the version-named folders that earlier updates left; step 2 still asks for 45 GB for an update in place.
Issue: MagicBeanDev/Longshot#224
🤖 Generated with Claude Code