Answering "why doesn't the binary honor the 30s -- it exits in a few seconds":
disassembled the StopMission close in all four BTL4OPT builds (BTLIVE May-96,
BTRAVINE Sep-96, BTDAVE, Rel410) -- BYTE-IDENTICAL, so nothing regressed. The
dispatched (outer) handler is a re-entrant two-stage close: first StopMission
schedules itself +~3s (3.0f) and returns; the +3s re-entry runs cleanup then
calls the inner L4Application handler which lights the egress lamps and
schedules a +30s LightsOut/exit (30.0f). The 30s is scheduled after teardown
begins, so the exe is recycled by GO.BAT before it fires -- observed egress
window = ~3.4s = the 3.0f stage. The operator's remembered ~20-30s "lights on"
is entry lighting (floor lamp on game-ready->drop, 21s measured) + the
between-games boot gap, not a post-mission hold. Corrects my earlier
"authentic 30s hold" note. Tools: scratchpad btdis2.py + stopmission_cmp3.py.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
CydandClaude Fable 5
c93b2ed786
