This is an old revision of the document!
Table of Contents
v6.7.23: Results-screen intermission
Scheduled, not live at the October 5, 2026, 17:47 PDT review. This compatible room update follows successful activation of the pending supervisor upgrade. All four rooms currently run the maintenance bridge.
What players will notice
- If you are alone and still viewing results, automatic start timing waits for you to return to the lobby.
- The same hold applies when every active gameplay player remains post-game.
- As soon as any active player returns to Idle or Ready, the ordinary pre-countdown wait starts fresh. Time spent viewing results does not consume that wait.
- Spectators and the referee do not count toward the hold.
- Existing readiness rules remain: Idle does not automatically mean Ready. Ready-based early starts still work, and a lone player still needs READY for automatic starting.
- Explicit
.start, optional.wait, score processing and the configured numeric countdown retain their existing behavior.
This is an automatic-start pacing change, not a new command or a forced minimum break. A player explicitly requesting .start keeps its existing override behavior, subject to map, readiness and referee checks.
How the bot knows
The referee API does not expose lazer's separate native Results state. It reports finished_play after gameplay, suppresses the intermediate Results transition, and reports idle or ready when the player returns. The bot uses that already-received post-game status as the hold signal; it does not inspect a player's screen or infer it from inactivity.
No additional API polling, recurring requests or account connections are added. Existing player-status events and the cached roster supply the information. See the official referee status mapping. Unknown states are not guessed to be results.
Current operator timing, unchanged by this patch
| Setting | Effective value in all four rooms | Purpose |
|---|---|---|
score_delay_seconds | 4 seconds | Initial wait before score fetching; absent scores can keep scoring active for up to 20 seconds after completion |
auto_start_seconds | 10 seconds | Ordinary idle/pre-countdown wait; Ready-based early starts may shorten it |
countdown_seconds | 10 seconds | Numeric countdown before gameplay; existing extensions can still apply |
start_wait_seconds | 10 seconds | Extra delay per eligible .wait request, once per player per map |
rating_window_seconds | 90 seconds | Feedback window, not a pause before the next match |
These are reviewed live operator values, not new immutable defaults. Universal settings override older values in individual room JSON files. The new hold postpones automatic timing while all gameplay players remain post-game; downloads, readiness, optional waits and safety checks can also extend a transition. Map duration settings are unrelated and unchanged.
Validation and rollout
789 offline tests passed, including solo/all-player holds, the actual finished_play → idle event sequence, release when one player returns, spectators/referees, departures, unknown states and absence of API calls. The immutable release is compatible with v6.7.22, and all four rooms passed the owner-approved duration guard.
A durable follow-on job waits for the v6.7.22 maintenance job to complete, a fresh v6.7.22 supervisor status and all four healthy v6.7.22 workers without pending targets. Only then does it submit the guarded ordinary empty-safe v6.7.23 rollout. It does not force occupied rooms to close. A scheduled job or accepted deployment request is not evidence that a room already has this behavior.
Includes earlier cumulative Jump and supervisor work. Collection, the separate research candidate database and live map catalogs are unchanged by this patch.
Release history · Match lifecycle · Readiness rules · Update safety · Live lobbies