vwemirror/BT411
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Launch pend counter: no timeout, no queue entry (mid-load launch crash 2)

Browse Source 
The take-1 deferral (re-post at +1s, capped at 120) turned a SLOW load
into a crash: loads on a busy operator box measure 1-2+ minutes, the
cap expired, and the original "Not ready to run" Fail/abort fired
(field report: sound after ~1 min, crash ~2 min later; the log shows
exactly 120 deferrals all in LoadingMission).

A mid-load RunMission now just bumps gBTRunMissionPendCount -- nothing
enters the event queue and there is NO timeout to outlive -- and
CheckLoadMessageHandler drains the counter immediately after advancing
LoadingMission -> WaitingForLaunch, re-posting that many stack
RunMissionMessages (the engine's own no-console launch pattern at the
same site, which also demonstrates Post spools stack messages safely).

Verified (two-round rig, round 1): both relay launches pended through
the load, fired at load completion, the requested mech spawned and the
scene went live.  Round reset + round-2 rejoin remain verified from the
prior run; why loads take 1-2+ min on a busy box is left as an open
perf question.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
arcattack
2026-07-22 19:11:03 -05:00
co-authored by Claude Opus 4.8
parent 3a9b35fc06
commit 53c86fa1dd
3 changed files with 60 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files
context/multiplayer.md
+12
View File
@@ -425,6 +425,18 @@ phase). Plan: `~/.claude/plans/partitioned-snuggling-piglet.md`.
deferrals so a wedged load still surfaces the original Fail. `[launch] ... deferred +1s`
log per deferral. Verified: the crashing shape deferred 104x through a ~50s load, then
launched and ran clean.
- **LAUNCH/LOAD RACE take 2 -- the PEND COUNTER (2026-07-22) [T2]**: the take-1 deferral
(re-post at +1s, 120 cap) turned a SLOW load into a crash -- loads on a busy operator box
measured 1-2+ minutes, the cap expired, and the original Fail/abort fired (field-reported:
"sound after 1 min, crash 2 min later", exactly 120 deferrals in the log). Now a mid-load
RunMission just bumps `gBTRunMissionPendCount` (L4APP.cpp) -- NOTHING enters the event queue,
NO timeout -- and APP.cpp `CheckLoadMessageHandler` drains the counter right after it advances
LoadingMission->WaitingForLaunch, re-posting that many stack RunMissions (the engine's own
no-console launch pattern at the same site). Verified: both relay launches pended through the
load, fired at completion, mech spawned + scene LIVE. NOTE the queue-blocking livelock theory
from take 2's commit is UNPROVEN -- the measured fact is just that loads outlive any fixed
cap; the counter design is correct under either reading. Residual: WHY loads take 1-2+ min
on the operator box (vs ~30s earlier same day) is an open perf question ([loadobj] timings).
- **ROUND RESET (2026-07-22) [T2]**: trim/prefs FINALIZE the egg for one round -- and that used
to be permanent for the relay's lifetime, so a REJOIN after a mission (or crash) was served
the stale finalized egg and its new callsign/mech request was recorded but never applied (the