From 2555c34a44e75c234ffd3f1a64e2b7ea6b38da88 Mon Sep 17 00:00:00 2001 From: Cyd Date: Thu, 9 Jul 2026 14:00:36 -0500 Subject: [PATCH] Egress hold: CLOSED (won-t-fix) -- floor lamps gone from surviving cockpits; findings preserved Co-Authored-By: Claude Fable 5 --- emulator/EGRESS-HOLD-FIX-PLAN.md | 16 ++++++++++++++-- emulator/NET-NOTES.md | 27 ++++++++++++++++++--------- 2 files changed, 32 insertions(+), 11 deletions(-) diff --git a/emulator/EGRESS-HOLD-FIX-PLAN.md b/emulator/EGRESS-HOLD-FIX-PLAN.md index c6aa3bf..7324dd5 100644 --- a/emulator/EGRESS-HOLD-FIX-PLAN.md +++ b/emulator/EGRESS-HOLD-FIX-PLAN.md @@ -1,6 +1,18 @@ -# Back-burner plan: honor the ~30s customer-egress hold +# Egress-hold / floor-lighting — CLOSED (won't-fix), findings preserved + +Status: **CLOSED 2026-07-10 — WILL NOT FIX** (operator decision). The floor +egress lights were a curiosity only: no surviving Tesla cockpit still has the +floor lamps installed, so reproducing the ~30s hold has no restoration value. +The investigation is fully documented here and in NET-NOTES.md for the record; +we will likely not return to it. The Step 1 patch below is a COMPLETE, ready +recipe if a future need ever arises — it is not planned work. + +Summary of the closed finding: the pod's post-mission egress window is a +compiled ~3s (the game exits at its stage-1 timer; the deeper 30s timer is +never reached). It is byte-identical across all four BTL4OPT builds +(May-96..Rel410) = NOT a Rel410 regression. Effective behavior is authentic +as-is; the ~3s is what the game does. -Status: BACK BURNER. Step 0 DONE 2026-07-10 -> Step 1 is the confirmed fix. Context in NET-NOTES.md ("EGRESS DELAY = COMPILED IN, TWO-PHASE"). ## Step 0 RESULT (2026-07-10, net_full.conf single-shot, RIO tap) diff --git a/emulator/NET-NOTES.md b/emulator/NET-NOTES.md index e6c7727..b62fba3 100644 --- a/emulator/NET-NOTES.md +++ b/emulator/NET-NOTES.md @@ -642,15 +642,24 @@ 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 +lamp-on->off exactly). Step 0 diagnostic (net_full single-shot, no +loop, 2026-07-10) PROVED this is the game's own behavior, not a +GO.BAT-loop artifact: with only a DOS `pause` waiting, the floor lamp +held 3.9s (mission-end 108.8s -> off 112.7s) and btl4opt EXITED itself +to COMMAND. The process exits AT the stage-1 (3.0f) timer; the deeper +30s timer is never reached. The operator's remembered ~20-30s "lights +on" is the ENTRY lighting (floor lamp on game-ready->drop, measured +15.9-21s across runs) plus the between-games boot/idle gap, NOT the +post-mission egress phase. Tools: scratchpad btdis2.py + +stopmission_cmp3.py + lamp_read.py (pefile+capstone, py -3.13). + +**ISSUE CLOSED 2026-07-10 (WON'T-FIX, operator decision):** the floor +egress lights are a curiosity only -- no surviving Tesla cockpit still +has the floor lamps installed, so reproducing the ~30s hold has no +restoration value. The ~3s behavior is authentic and left as-is. Full +findings + a ready (unplanned) Step 1 patch recipe in +emulator/EGRESS-HOLD-FIX-PLAN.md. Supersedes the earlier "3.4s = print +time" AND "authentic 30s hold" readings; not revisiting. 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).