fix(build): the time left counts down between the compile's estimates and ignores skipped work #45

Merged

HumanBean merged 1 commit from HumanBean/LongshotLauncher:fix/build-time-left into main

2026-11-13 17:05:18 +00:00

HumanBean commented

2026-11-13 16:15:26 +00:00

Owner

The build step's time left was way off: it froze for minutes during the compile, showed minutes for a read that had seconds left, and on rebuilds showed later stages at about 4× their real length.

Why (causes)

The compile's time left froze. BuildClock used @@eta as it arrived, and nx2/build.py only sends one when a file finishes; it compiles the biggest files first, so lines can be minutes apart.
The read step showed minutes when seconds were left. A stage's rate was measured from the stage's start, but the read reports progress only during its final file check, after a long unpack that reports nothing (the shaders step likewise reports only once the game has started).
Skipped work skewed the pace. On a rebuild or an update, make_game skips the read and the translation and compiles only changed files. Those stages took seconds against minutes forecast, so Pace() hit its 0.25 floor and every later stage was shown at a quarter of its time.
The bar's shares were fixed for a 24-thread PC, while the time estimate (BuildForecast) scales with threads, so on fewer threads the bar and the time left disagreed.
(small) The tools download, done in step 1, stayed running and added about 10 s.

What changed

Core/MakeGameRun.cs (BuildClock): the compile counts down from the last @@eta; once that runs out (the link, or a slower PC than build.py expects) it uses the compile's own progress rate, with a 10% floor while that can't be measured. Other stages measure their rate from when their progress first moves. Pace() leaves out stages marked Kept.
Core/MakeGameProtocol.cs: each stage's share of the bar comes from BuildForecast.Seconds(id, threads) (identical to the old fixed shares at 24 threads). New BuildStage.Kept, set by make_game's two "skipped" lines, by @@plan changed < total, and for an update's read. Download(1) marks the download done.
App/ViewModels/BuildStepViewModel.cs: passes the build's thread count to BuildProgress.
Tests: tests/launcher_core/Program.cs takes the bar's expected values from the forecast and checks shares at 8 vs 24 threads, Kept and the eta count; tests/launcher_core/ScreenChecks.cs adds a scenario for the read's rate, skipped stages, the eta countdown and its fallback.

Testing

python -I tests/test_launcher_core.py and python -I tests/test_release.py: pass.
Not yet run on a real build. WIP until a first build and a rebuild show the time left counting down smoothly.

Open, needing timestamped build logs: the forecast's stage times and its threads^0.85 scaling on 8–16 thread CPUs; the link time (the 10% floor is a guess); build.py's first-build @@eta assumes a 7900X's speed (a Longshot change, not here); a rebuild starts at the full first-build forecast until make_game says what it skipped.

🤖 Generated with Claude Code

The build step's time left was way off: it froze for minutes during the compile, showed minutes for a read that had seconds left, and on rebuilds showed later stages at about 4× their real length. ## Why (causes) 1. **The compile's time left froze.** `BuildClock` used `@@eta` as it arrived, and `nx2/build.py` only sends one when a file finishes; it compiles the biggest files first, so lines can be minutes apart. 2. **The read step showed minutes when seconds were left.** A stage's rate was measured from the stage's start, but the read reports progress only during its final file check, after a long unpack that reports nothing (the shaders step likewise reports only once the game has started). 3. **Skipped work skewed the pace.** On a rebuild or an update, make_game skips the read and the translation and compiles only changed files. Those stages took seconds against minutes forecast, so `Pace()` hit its 0.25 floor and every later stage was shown at a quarter of its time. 4. **The bar's shares were fixed for a 24-thread PC,** while the time estimate (`BuildForecast`) scales with threads, so on fewer threads the bar and the time left disagreed. 5. (small) The tools download, done in step 1, stayed running and added about 10 s. ## What changed - `Core/MakeGameRun.cs` (`BuildClock`): the compile counts down from the last `@@eta`; once that runs out (the link, or a slower PC than build.py expects) it uses the compile's own progress rate, with a 10% floor while that can't be measured. Other stages measure their rate from when their progress first moves. `Pace()` leaves out stages marked `Kept`. - `Core/MakeGameProtocol.cs`: each stage's share of the bar comes from `BuildForecast.Seconds(id, threads)` (identical to the old fixed shares at 24 threads). New `BuildStage.Kept`, set by make_game's two "skipped" lines, by `@@plan changed < total`, and for an update's read. `Download(1)` marks the download done. - `App/ViewModels/BuildStepViewModel.cs`: passes the build's thread count to `BuildProgress`. - Tests: `tests/launcher_core/Program.cs` takes the bar's expected values from the forecast and checks shares at 8 vs 24 threads, `Kept` and the eta count; `tests/launcher_core/ScreenChecks.cs` adds a scenario for the read's rate, skipped stages, the eta countdown and its fallback. ## Testing - `python -I tests/test_launcher_core.py` and `python -I tests/test_release.py`: pass. - **Not yet run on a real build.** WIP until a first build and a rebuild show the time left counting down smoothly. Open, needing timestamped build logs: the forecast's stage times and its threads^0.85 scaling on 8–16 thread CPUs; the link time (the 10% floor is a guess); build.py's first-build `@@eta` assumes a 7900X's speed (a Longshot change, not here); a rebuild starts at the full first-build forecast until make_game says what it skipped. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

HumanBean added 1 commit

2026-11-13 16:15:26 +00:00

fix(build): the time left counts down between the compile's estimates and ignores skipped work

CI / Compile and test (pull_request) Has been skipped

Details

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

Details

6bd88bf092

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

HumanBean changed title from ~~WIP: fix(build): the time left counts down between the compile's estimates and ignores skipped work~~ to fix(build): the time left counts down between the compile's estimates and ignores skipped work

2026-11-13 17:02:32 +00:00

HumanBean merged commit f8dc247d56 into main

2026-11-13 17:05:18 +00:00

HumanBean referenced this pull request from a commit

2026-11-13 17:05:19 +00:00

fix(build): the time left counts down between the compile's estimates and ignores skipped work (#45)

HumanBean deleted branch fix/build-time-left

2026-11-13 17:05:22 +00:00