Answering "did you check the decomp or disassembly?" -- I had not. I had checked
the authored data (BTL4.RES) and the MUNGA engine source and called it authentic
on source lineage alone. Now verified in BTL4OPT.EXE:
same sources compiled in : d:\tesla_bt\munga\AUDSEQ.CPP / AUDWTHR.CPP strings
object factory : @00466184 case 0x4b -> alloc 0x5C -> ctor @0043ccec
vtable : 0x4ead48
ReceiveControl : @0043d3a4 -- switch on control IDs 1 / 2 / 9 / 12,
which is exactly our enum Start / Stop / Idle / Tempo
Stop case : @0043d3ca -> unconditional call StopSequence @0043d2d4
StopSequence : tests only its OWN isRunning (+0x28) then the Chase
loop -- NO refcount, NO awareness of other leak sources
Structurally identical to engine/MUNGA/AUDSEQ.cpp. So the arcade behaved the same
way: with 19 subsystems sharing one alarm sequence, any one of them clearing its
leak silences the alarm while the others still leak. AUTHENTIC -- do not "fix".
(The tempo bound check could not be used as an anchor: Verify() compiles out of the
retail build, so the AUDSEQ.CPP assert strings are present in .data but unreferenced
by code and invisible to the decomp export -- gotcha 21 again. The object-factory
route via the numeric ClassID is what actually located the class.)
Recorded in context/gauges-hud.md with the full chain and the address table, so the
next person does not re-chase it or "fix" it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
