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

Egress hold: CLOSED (won-t-fix) -- floor lamps gone from surviving cockpits; findings preserved

Browse Source 
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Cyd
2026-07-09 14:00:36 -05:00
co-authored by Claude Fable 5
parent f1fdc68f5d
commit 2555c34a44
2 changed files with 32 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files
emulator/EGRESS-HOLD-FIX-PLAN.md
+14 -2
View File
@@ -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)
emulator/NET-NOTES.md
+18 -9
View File
@@ -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).