fix(build): the time left waits for this PC's pace, and scales the CPU's stages and the disk's apart

HumanBean commented

2026-11-15 17:39:53 +00:00

Owner

Some players still see a time left that's far off. It's said from the first second, from one PC's build times scaled only by thread count, and a single pace is applied to every stage, so a slow disk makes the compile look slow (and a slow CPU the read).

What changed

Core/MakeGameRun.cs, BuildClock:

It waits before saying a time. The build screen says "Working out the time left" (and no "~N min" on the rows) until make_game has run 20 s and this PC has shown its pace: 30 forecast seconds of measured work, make_game's own @@eta for the compile, or a running stage's rate. With none of those (a build where every stage keeps earlier work), it says the forecast after 2 minutes. Once a number is shown it isn't taken back.
Two paces, scaled apart. The threaded stages (lift, compile, shaders: BuildForecast.Parallel) go at the CPU's pace, the read and the finish at the disk's. Each is measured from that kind's finished stages, plus the running stage's own rate weighted by how far it has got, so the pace improves during a stage, not only after it. A kind with nothing measured keeps the thread-scaled forecast rather than borrowing the other kind's pace. The clamp is 0.2–5 (was 0.25–4).
Kept work is forecast as kept. A compile of 300 changed files out of 579 is forecast at that share of a full compile (at least 3%, for the link), and a stage known to keep an earlier build's work at a tenth. Before, both counted as a full stage. With updates now built in place (#104), this is the common case.
Unchanged: the compile's countdown from @@eta, a running stage's countdown from its own progress, and the forecast's reference times and thread scaling.

tests/launcher_core/ScreenChecks.cs: ClockChecks is rewritten for these: no time at the start or during the first seconds, the disk's pace not touching the CPU's stages, a running stage counting toward its kind's pace, a compile's share of changed files, the 2-minute fallback, and the time not being taken back once shown.

Testing

Linux (CachyOS), .NET SDK 10.0.404, on main @ 5ee7c174.

python -I tests/test_launcher_core.py: 1213 checks passed.
python -I tests/test_release.py: OK.
dotnet build App/LongshotLauncher.csproj: 0 warnings, 0 errors.

Not tested: no real build was run here (no game dump on this PC), so the thresholds (20 s, 30 forecast seconds, 2 minutes) are judgement, not measured. A log of a build where the time was wrong would help tune them. No screenshot: the screen is unchanged apart from saying "Working out the time left" for longer, an existing text.

🤖 Generated with Claude Code

Some players still see a time left that's far off. It's said from the first second, from one PC's build times scaled only by thread count, and a single pace is applied to every stage, so a slow disk makes the compile look slow (and a slow CPU the read). ## What changed `Core/MakeGameRun.cs`, `BuildClock`: - **It waits before saying a time.** The build screen says "Working out the time left" (and no "~N min" on the rows) until make_game has run 20 s *and* this PC has shown its pace: 30 forecast seconds of measured work, make_game's own `@@eta` for the compile, or a running stage's rate. With none of those (a build where every stage keeps earlier work), it says the forecast after 2 minutes. Once a number is shown it isn't taken back. - **Two paces, scaled apart.** The threaded stages (lift, compile, shaders: `BuildForecast.Parallel`) go at the CPU's pace, the read and the finish at the disk's. Each is measured from that kind's finished stages, plus the running stage's own rate weighted by how far it has got, so the pace improves during a stage, not only after it. A kind with nothing measured keeps the thread-scaled forecast rather than borrowing the other kind's pace. The clamp is 0.2–5 (was 0.25–4). - **Kept work is forecast as kept.** A compile of 300 changed files out of 579 is forecast at that share of a full compile (at least 3%, for the link), and a stage known to keep an earlier build's work at a tenth. Before, both counted as a full stage. With updates now built in place (#104), this is the common case. - Unchanged: the compile's countdown from `@@eta`, a running stage's countdown from its own progress, and the forecast's reference times and thread scaling. `tests/launcher_core/ScreenChecks.cs`: `ClockChecks` is rewritten for these: no time at the start or during the first seconds, the disk's pace not touching the CPU's stages, a running stage counting toward its kind's pace, a compile's share of changed files, the 2-minute fallback, and the time not being taken back once shown. ## Testing Linux (CachyOS), .NET SDK 10.0.404, on main @ 5ee7c174. - `python -I tests/test_launcher_core.py`: 1213 checks passed. - `python -I tests/test_release.py`: OK. - `dotnet build App/LongshotLauncher.csproj`: 0 warnings, 0 errors. Not tested: no real build was run here (no game dump on this PC), so the thresholds (20 s, 30 forecast seconds, 2 minutes) are judgement, not measured. A log of a build where the time was wrong would help tune them. No screenshot: the screen is unchanged apart from saying "Working out the time left" for longer, an existing text. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

HumanBean added 1 commit

2026-11-15 17:39:54 +00:00

fix(build): the time left waits for this PC's pace, and scales the CPU's stages and the disk's apart

CI / Compile and test (pull_request) Has been skipped

Details

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

Details

9c60b6ff8c

The time left was said from the first second, from one PC's times scaled by threads, and one pace for every stage: a slow
disk made the compile look slow, a slow CPU the read. It now says "Working out the time left" until make_game has run
20 s and this PC has shown its pace (30 forecast seconds measured, make_game's @@eta, or a running stage's rate), or for
2 minutes at most. The lift, the compile and the shaders go at the CPU's pace, the read and the finish at the disk's, each
from its finished stages and its running stage's rate. A compile of some files is forecast at their share, a stage that
keeps an earlier build's work at a tenth.

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