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

CORRECTION: EJECT tap IS the in-mission unjam (EjectAmmo @004bb9b8 decoded)

Browse Source 
Old-timer testimony (tap = eject one round, hold = eject the bay, eject
clears a jam) checked against the binary: raw disasm of the export-gap
handler @004bb9b8 confirms it byte-for-byte.  PRESS arms the ~3s
UpdateEject countdown (hold-to-completion = DumpAmmo whole bay ->
NoAmmo); RELEASE before completion (TAP) ejects ONE round (@004bd4f4)
and, with ammo remaining, sets weaponAlarm 3 + restarts the reload --
the weapon returns to service.  A tap even recovers a FailureHeat
level-7 launcher while rounds remain (empty-bin gate 2 re-pins 7 only
when the bay is dry).

The earlier 'jams are mission-permanent / no unjam exists' claim read
only the HOLD path -- corrected + swept: projweap.cpp case-5/jam-log/
CheckForJam comments, players/README.txt, decomp-reference.md
(message-tables entry), open-questions.md (state-7 recovery note).
Gitea #31 updated; wiring the handler now restores the pod's actual
jam-recovery mechanic.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
arcattack
2026-07-23 12:21:06 -05:00
co-authored by Claude Opus 4.8
parent a999e5c49f
commit 225fe43f0c
4 changed files with 39 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files
context/decomp-reference.md
+13 -1
View File
@@ -273,7 +273,19 @@ From the weapon `.SUB` records + the charge-curve `.data` constants (PE-parsed a
novice + @4ad7d4 heat-model + press-only, then idx@0x320=(idx+1)%(max@0x32C+1), NO
ResetFiringState); Emitter's faithful body existed as the orphaned "AdvanceSeekVoltage" (zero
callers) -- both registered via MESSAGE_ENTRY (ids 9/0xb). Verify: BT_SEEKTEST=1 +
BT_SEEK_LOG=1 → `[seek] <name> -> gear N` cycling. EjectAmmo remains unwired.
BT_SEEK_LOG=1 → `[seek] <name> -> gear N` cycling. EjectAmmo remains unwired (#31).
**EjectAmmo @004bb9b8 DECODED 2026-07-23 (raw disasm; the fn sits in a Ghidra export gap)
[T1]** — old-timer testimony ("tap ejects a round, hold ejects the bay, eject clears a jam")
matched the bytes exactly: novice guard @4ac9c8 → **PRESS** (`msg+0xc > 0`): bin alarm
(`bin+0x194`) → 3, `timeToEject=total`, `percentOfEject=0`, `ejectState=0` (UpdateEject
@004bbb50 runs the ~3 s countdown; completion = DumpAmmo @004bd588 whole-bay →
weaponAlarm 7). **RELEASE** with the countdown still live (**TAP**): bin alarm 4→1,
`EjectOneRound` @004bd4f4 (`count--`, feedTimer reset, count<1 → bin state 2); bin
empty → weaponAlarm 7, else **weaponAlarm 3 (Loading) + reloadTimer restart — the
weapon RETURNS TO SERVICE. A TAP is the in-mission UNJAM** (state 5 has no exit inside
the Execute machine, but this handler overwrites it). The earlier "jams are
mission-permanent / no unjam" claim was WRONG (read only the hold path) — corrected +
swept 2026-07-23 (projweap.cpp case-5/jam-log comments, players/README.txt).
**LATENT ARCADE BUG found + diverged (issue #21, 2026-07-21) [T1 byte-verified + T2 repro]:**
the Emitter charge integrates toward the GENERATOR voltage (@004ba838 `fld [src+0x1dc]`), full
is detected only inside the +-1% snap window around `seekVoltage[idx]` (ComputeOutputVoltage