agent: loading a save gives up after one 30 s press while the game is still building its pipelines #10

New issue

Closed

opened 2026-11-15 17:48:32 +00:00 by jabbaxipil · 0 comments

jabbaxipil commented

2026-11-15 17:48:32 +00:00

Beanstalk #3's notes list MagicBeanDev/Longshot#718's "the game did not read the controller" as being looked into; this is what I found on that PC.

What happens: On a Linux PC (RTX 4070, NVIDIA 615.71.09, Ubuntu 26.04, agent dev-0e7d3e7), every job whose scenario starts from a save ends as error: "no scenario could be judged: a step ran out of time: timeout: the game did not read the controller". Five jobs so far: MagicBeanDev/Longshot#718 (rp_bca2d31bcc9a4c8a), MagicBeanDev/Longshot#461 (rp_dddd96501f6e43e3), MagicBeanDev/Longshot#772 twice (rp_20b7db7482e51065, rp_a4aeeeca85a2bbee), MagicBeanDev/Longshot#751 (rp_f4802f1a59caacba). Each run lasts about 34 s from start to give-up.

Why (from the reports' log tails): when the agent gives up, the game is still preparing pipelines at start-up, e.g. "noted pipelines: 1360 of 32390 pipelines in 24 s, about 547 s left" (MagicBeanDev/Longshot#751), "2046 of 32390 ... about 459 s left" (MagicBeanDev/Longshot#718), "1979 of 24448 ... about 367 s left" (MagicBeanDev/Longshot#461). The driver shader cache starts empty in every run ("driver shader cache at the start: 0 MB (no folder found)"), so every run pays the whole preparation.

Where: IntoPlayAsync in agent/Core/ScenarioRunner.cs (main 720f8a1) presses A about once a second until the game is in play, with a 600 s limit. Each press is a bridge press, which waits 30 s for the game to read it (ControlClient.cs, Input(); Longshot's host/control.c input_done replies "the game did not read the controller" when the input was never taken). The first press's timeout leaves the loop as a BridgeError, so the run ends after about 30 s instead of 600 s. NewGameAsync presses the same way (not seen in a run here).

By contrast, MagicBeanDev/Longshot#345's startup-and-field (starts at the title with the boot_time probe, which first waits up to 600 s for a present) booted in about 564 s, 558 s of it shader compile, and was judged.

Suggested change (not built or tested here):

if ((string?)status["state"] != "play")
{
    try { await Step(bridge, game, press, cancel); }
    catch (BridgeError e) when (e.Error == "timeout") { }   // not read yet: the game is still starting; the 600 s limit decides
}

and the same around the presses in NewGameAsync. Or wait for the first present (up to 600 s) before the first press, as the boot_time probe does. Keeping a driver shader cache between runs on the same PC would also shorten every start (untested).

Not tested: dev-ee5fd24, Windows, a patched agent.

Beanstalk #3's notes list MagicBeanDev/Longshot#718's "the game did not read the controller" as being looked into; this is what I found on that PC. **What happens:** On a Linux PC (RTX 4070, NVIDIA 615.71.09, Ubuntu 26.04, agent dev-0e7d3e7), every job whose scenario starts from a save ends as error: "no scenario could be judged: a step ran out of time: timeout: the game did not read the controller". Five jobs so far: MagicBeanDev/Longshot#718 (rp_bca2d31bcc9a4c8a), MagicBeanDev/Longshot#461 (rp_dddd96501f6e43e3), MagicBeanDev/Longshot#772 twice (rp_20b7db7482e51065, rp_a4aeeeca85a2bbee), MagicBeanDev/Longshot#751 (rp_f4802f1a59caacba). Each run lasts about 34 s from start to give-up. **Why (from the reports' log tails):** when the agent gives up, the game is still preparing pipelines at start-up, e.g. "noted pipelines: 1360 of 32390 pipelines in 24 s, about 547 s left" (MagicBeanDev/Longshot#751), "2046 of 32390 ... about 459 s left" (MagicBeanDev/Longshot#718), "1979 of 24448 ... about 367 s left" (MagicBeanDev/Longshot#461). The driver shader cache starts empty in every run ("driver shader cache at the start: 0 MB (no folder found)"), so every run pays the whole preparation. **Where:** `IntoPlayAsync` in `agent/Core/ScenarioRunner.cs` (main 720f8a1) presses A about once a second until the game is in play, with a 600 s limit. Each press is a bridge `press`, which waits 30 s for the game to read it (`ControlClient.cs`, `Input()`; Longshot's `host/control.c` `input_done` replies "the game did not read the controller" when the input was never taken). The first press's timeout leaves the loop as a `BridgeError`, so the run ends after about 30 s instead of 600 s. `NewGameAsync` presses the same way (not seen in a run here). By contrast, MagicBeanDev/Longshot#345's `startup-and-field` (starts at the title with the `boot_time` probe, which first waits up to 600 s for a present) booted in about 564 s, 558 s of it shader compile, and was judged. **Suggested change** (not built or tested here): ```csharp if ((string?)status["state"] != "play") { try { await Step(bridge, game, press, cancel); } catch (BridgeError e) when (e.Error == "timeout") { } // not read yet: the game is still starting; the 600 s limit decides } ``` and the same around the presses in `NewGameAsync`. Or wait for the first present (up to 600 s) before the first press, as the `boot_time` probe does. Keeping a driver shader cache between runs on the same PC would also shorten every start (untested). **Not tested:** dev-ee5fd24, Windows, a patched agent.