NET-NOTES: egress delay is compiled + two-phase; cross-build identical (no regression)

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>
This commit is contained in:
Cyd
2026-07-09 13:17:13 -05:00
co-authored by Claude Fable 5
parent 6a4a46c897
commit c93b2ed786
+29 -19
View File
@@ -622,25 +622,35 @@ MEASURED BOTH CONSOLES: TeslaConsole = 3.4s AND Console 4.10 = 3.4s
(lamp-ON to full-sweep-off). No egress-delay key exists in
Console.ini / venue INIs (checked).
**EGRESS DELAY FOUND IN THE BINARY (2026-07-10 disasm):** it is a
HARDCODED ~30s constant in BTL4OPT.EXE's `StopMissionMessageHandler`
@ 0x47b864 -- NOT an INI/env value. The handler: (1) calls
mission-shutdown/EndMission (0x44eeb4); (2) calls the lamp routine
(0x47bba8, named by the "LightsOut" string @0x4fd5ac) with flag=1 ->
egress lamps 0x16/0x17/0x1e ON; (3) schedules a delayed state block
(0xc,0xc,1) for `now + 30.0*timebase + 0.5` (30.0f @0x47b8e4, 0.5f
@0x47b8e8, timebase global @0x52140c read across the whole sim) -- at
which the lamps go off and the game exits into GO.BAT. Matches the
operator's memory exactly: StopMission -> floor lights on -> ~30s hold
-> lights off -> exit -> BAT restart. The LightsOut lamp-off helper
(0x47bb34, flag=0 branch) sweeps 0x16/0x17/0x1e off. RECONCILE: this
30s vs the measured 3.4s -- the 154.9s full-lamp SWEEP we tapped was
likely the teardown GeneralReset (a different event), with the true 30s
timer firing past our tap window; timebase multiplier is runtime-set so
wall-time can't be proven statically. TEST TO SETTLE: one mission with
a 90s+ RIO tap window past mission end. Disasm tool: scratchpad
btdis2.py (pefile+capstone, py -3.13). This is the authentic egress
window; the earlier "print time" theory is superseded. Lamp
**EGRESS DELAY = COMPILED IN, TWO-PHASE (2026-07-10 disasm; cross-build
verified) -- NOT an INI/env value, and NOT a Rel410 regression.** The
StopMission close path in BTL4OPT.EXE uses nested class handlers:
- OUTER handler (runs for the pod, Rel410 @0x47c2c4) is re-entrant on a
flag @[this+0xd4]: FIRST call schedules ITSELF to re-fire in
`3.0*timebase + 0.5` ≈ **3 seconds** (3.0f @0x47c350) and returns;
the RE-ENTRY (3s later) runs cleanup (0x44e13c/0x44fa6c) then calls
the inner handler.
- INNER handler (L4Application, Rel410 @0x47b864) calls base shutdown
(0x44eeb4), lights egress lamps 0x16/0x17/0x1e ON (0x47bba8 flag=1,
the "LightsOut"-named routine @0x4fd5ac), and schedules a **30.0s**
timer (30.0f @0x47b8e4) for lamps-off/exit.
- timebase global @0x52140c (runtime-set, read sim-wide); ftol @0x4dcd94.
**CROSS-BUILD: byte-identical in ALL four binaries** -- BTLIVE (May-96,
handlers @0x489a08/0x48a3c0), BTRAVINE (Sep-96, @0x47b850/0x47c2b0),
BTDAVE (@0x489a08/0x48a3c0), Rel410 (@0x47b864/0x47c2c4). So Rel410 did
NOT cut a 30s hold; every build has both the 3.0 and 30.0 constants.
**EFFECTIVE behavior = the 3s phase** (matches the measured 3.4s
lamp-on->off exactly). The 30s phase-2 timer is scheduled AFTER cleanup
has begun tearing the exe down, so the process is recycled by netnub
before it fires -- true in every build, so the 30s is effectively dead
in the actual run. The operator's remembered ~20-30s "lights on" is the
ENTRY lighting (floor lamp on game-ready->drop, MEASURED 21s in our tap:
1207s->1228s) plus the between-games boot/idle gap, NOT the post-mission
egress phase. Tools: scratchpad btdis2.py + stopmission_cmp3.py
(pefile+capstone, py -3.13). Supersedes the earlier "3.4s = print time"
AND "authentic 30s hold" readings. Lamp
state byte: flash bits0-1 (solid/slow/med/fast), ch1 bits2-3
(off/dim/bright), ch2 bits4-5. Extraction tool: scratchpad
lamp_read.py pattern (tap lines are one byte each).