feat(build): this PC's build estimate, and a time left that learns its pace #28

Merged

HumanBean merged 2 commits from HumanBean/LongshotLauncher:fix/build-time-estimates into main

2026-11-13 10:55:15 +00:00

HumanBean commented

2026-11-13 10:54:38 +00:00

Owner

Why

Step 2 said "About 45 min, shaders included" (37 without) to every player, a 2.x Builder figure that was never measured. Step 3's bar gave the shaders 8% of the build when they are about a third, and its time left said "Working out the time left" until the build had run a while.

What changed

Core/MakeGameRun.cs, BuildForecast (new):
- Each step's measured time: two player builds of nightly-56 on a Ryzen 9 7900X (24 threads) with an RTX 3090.
- The steps that use every thread (the lift, the compile, the shaders) scale by this PC's threads as (24 / threads)^0.85. The read, finish and download steps keep their measured times.
App/ViewModels/SettingsStepViewModel.cs:
- Step 2 shows this PC's estimate: "About 14 min on this PC, shaders included" on the measured PC, about 23 min on 12 threads and about 31 min on 8.
- The Build workers setting, when set, takes the place of the thread count.
BuildClock gets better as the build runs:
- It starts from the forecast.
- The steps still to come run at this PC's pace, which is how long the finished steps took against their forecast, kept within 0.25-4×.
- A running step counts down from its own progress once it has 10% and 10 s.
- The compile keeps make_game's @@eta.
- Each row's "~N min" uses the same numbers.
Core/MakeGameProtocol.cs: BuildProgress's step weights are the measured shares:
- with shaders: download 2%, read 9%, translate 7%, compile 37%, finish 8%, shaders 37%;
- without shaders: 2 / 15 / 11 / 59 / 13%.
README (Build, Time estimates): where the numbers come from, and when to measure them again: after a change to the lift, the compile flags, the shader preparation or the toolchain, and before each release.
App/Views/HomeView.axaml: "about 15 to 30 minutes" instead of 45.

The Longshot side, the Builders' own estimates and the measurements, is in MagicBeanDev/Longshot#175.

Measurements

Step	nightly-56 @ e7ed2f7a, run 1	nightly-56 @ e7ed2f7a, run 2 (empty NVIDIA cache)
Download (100 MB) and verify	3 s	4 s
Unpack, install the build tools	6 s	7 s
Read the game files	64 s	89 s
Translate (the lift)	56 s	58 s
Compile and link	5 min 11 s	4 min 59 s
Finish the game folder	67 s	65 s
Prepare shaders, Most	5 min 0 s	5 min 22 s
In all	13 min 30 s	14 min 7 s

The forecast uses the mean of the two runs. The scaling with threads is an estimate, not a measurement: Longshot#175's test request T-KQH4 asks for builds on 6- and 8-core PCs to check it.

Testing

Tested:

tests/test_launcher_core.py: 608 checks passed. The new checks cover the forecast on the measured PC, the thread scaling, the pace learned from the finished steps, a running step's countdown, and the compile's @@eta.
tests/test_release.py: OK.
The app builds (Release, Linux).

Not tested:

The window itself in a real build: step 2's text and step 3's countdown were not watched through a build.
Windows.
A PC with fewer threads, where the scaling is the estimate above.

Risk and rollback

Only the text and the bar's shares change; the build does not. Reverting the two commits brings back the fixed 45 minutes.

## Why Step 2 said "About 45 min, shaders included" (37 without) to every player, a 2.x Builder figure that was never measured. Step 3's bar gave the shaders 8% of the build when they are about a third, and its time left said "Working out the time left" until the build had run a while. ## What changed - **Core/MakeGameRun.cs, `BuildForecast` (new):** - Each step's measured time: two player builds of nightly-56 on a Ryzen 9 7900X (24 threads) with an RTX 3090. - The steps that use every thread (the lift, the compile, the shaders) scale by this PC's threads as (24 / threads)^0.85. The read, finish and download steps keep their measured times. - **App/ViewModels/SettingsStepViewModel.cs:** - Step 2 shows this PC's estimate: "About 14 min on this PC, shaders included" on the measured PC, about 23 min on 12 threads and about 31 min on 8. - The Build workers setting, when set, takes the place of the thread count. - **`BuildClock` gets better as the build runs:** - It starts from the forecast. - The steps still to come run at this PC's pace, which is how long the finished steps took against their forecast, kept within 0.25-4×. - A running step counts down from its own progress once it has 10% and 10 s. - The compile keeps make_game's `@@eta`. - Each row's "~N min" uses the same numbers. - **Core/MakeGameProtocol.cs:** `BuildProgress`'s step weights are the measured shares: - with shaders: download 2%, read 9%, translate 7%, compile 37%, finish 8%, shaders 37%; - without shaders: 2 / 15 / 11 / 59 / 13%. - **README** (Build, Time estimates): where the numbers come from, and when to measure them again: after a change to the lift, the compile flags, the shader preparation or the toolchain, and before each release. - **App/Views/HomeView.axaml:** "about 15 to 30 minutes" instead of 45. The Longshot side, the Builders' own estimates and the measurements, is in MagicBeanDev/Longshot#175. ## Measurements | Step | nightly-56 @ e7ed2f7a, run 1 | nightly-56 @ e7ed2f7a, run 2 (empty NVIDIA cache) | |---|---|---| | Download (100 MB) and verify | 3 s | 4 s | | Unpack, install the build tools | 6 s | 7 s | | Read the game files | 64 s | 89 s | | Translate (the lift) | 56 s | 58 s | | Compile and link | 5 min 11 s | 4 min 59 s | | Finish the game folder | 67 s | 65 s | | Prepare shaders, Most | 5 min 0 s | 5 min 22 s | | **In all** | **13 min 30 s** | **14 min 7 s** | The forecast uses the mean of the two runs. The scaling with threads is an estimate, not a measurement: Longshot#175's test request T-KQH4 asks for builds on 6- and 8-core PCs to check it. ## Testing **Tested:** - `tests/test_launcher_core.py`: 608 checks passed. The new checks cover the forecast on the measured PC, the thread scaling, the pace learned from the finished steps, a running step's countdown, and the compile's `@@eta`. - `tests/test_release.py`: OK. - The app builds (Release, Linux). **Not tested:** - The window itself in a real build: step 2's text and step 3's countdown were not watched through a build. - Windows. - A PC with fewer threads, where the scaling is the estimate above. ## Risk and rollback Only the text and the bar's shares change; the build does not. Reverting the two commits brings back the fixed 45 minutes.

HumanBean added 2 commits

2026-11-13 10:54:38 +00:00

fix(build): time estimates and step weights measured on nightly-56 b252a82c02

Step 2 said "About 45 min, shaders included" (37 without), the 2.x Builders'
figure, never measured, and step 3's bar gave the shaders 8% of the build.
Two player builds of nightly-56 on a Ryzen 9 7900X and an RTX 3090 took
13 min 30 s and 14 min 7 s; the shaders on Most were 5-5.5 min of it, about
a third, and the compile about 5 min.

The estimate is now "About 15-30 min, shaders included" (10-20 without); the
top of each range is for slower PCs. BuildProgress's weights are the measured
shares, and the README says where they come from and when to measure again.

Co-Authored-By: Claude Fable 5.2 <[email protected]>

feat(build): the estimate is this PC's, and the time left learns its pace as the build runs

CI / Compile and test (pull_request) Has been skipped

Details

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

Details

7809eab5b0

Step 2's estimate was one figure for every PC. BuildForecast keeps the
measured time of each step (two builds of nightly-56 on a 24-thread Ryzen 9
7900X) and scales the steps that use every thread (the lift, the compile, the
shaders) by this PC's threads, or the Build workers setting: "About 14 min on
this PC, shaders included" there, about 31 on 8 threads.

Step 3 starts from that forecast instead of "Working out the time left", and
corrects it as it goes: the steps still to come run at the pace the finished
ones showed against their forecast, a running step counts down from its own
progress once it has some, and the compile keeps make_game's @@eta.

Co-Authored-By: Claude Fable 5.2 <[email protected]>

HumanBean referenced this pull request from MagicBeanDev/Longshot

2026-11-13 10:54:48 +00:00

fix(builder): build times measured on nightly-56: the docs, the Builders' estimates and when to measure again #175

HumanBean referenced this pull request from MagicBeanDev/Longshot

2026-11-13 10:54:53 +00:00

fix(builder): build times measured on nightly-56: the docs, the Builders' estimates and when to measure again #175

HumanBean merged commit 3cae845d53 into main

2026-11-13 10:55:15 +00:00

HumanBean deleted branch fix/build-time-estimates

2026-11-13 10:55:15 +00:00

HumanBean referenced this pull request from a commit

2026-11-13 10:55:16 +00:00