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

Egress hold: Step 0 result -- ~3s is in-game (not the loop); Step 1 (3.0f->30.0f patch) confirmed as the fix

Browse Source 
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Cyd
2026-07-09 13:52:39 -05:00
co-authored by Claude Fable 5
parent 54101957fd
commit f1fdc68f5d
1 changed files with 15 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
emulator/EGRESS-HOLD-FIX-PLAN.md
+15 -2
View File
@@ -1,7 +1,20 @@
# Back-burner plan: honor the ~30s customer-egress hold
Status: BACK BURNER (not started). Context in NET-NOTES.md
("EGRESS DELAY = COMPILED IN, TWO-PHASE").
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)
Booted single-shot (netnub then DOS `pause`, NO loop.bat). Floor lamp:
mission-end bright @108.8s -> off @112.7s = **3.9s window**, then the game
(btl4opt) EXITED on its own to the DOS `pause` (dosbox left at COMMAND).
So the ~3s egress is the GAME'S OWN behavior, NOT a GO.BAT-loop artifact --
the process exits AT the stage-1 (3.0f) timer; the inner 30s timer is never
reached. Entry lighting this run: 77.4s->93.3s = 15.9s (varies with boot).
=> Not a free conf-fix. But since the lamps stay on for exactly the stage-1
duration and the exit fires when it elapses, **Step 1 (extend the 3.0f
constant to 30.0f) directly extends the honored hold to ~30s.** Proceed to
Step 1 when picked up.
## Problem restated