Three clean eliminations on the live-RIO fault, all on the ack-fixed emulator: not the ack heuristic (reproduces after the fix), not the debug logging (pod_render_quiet faults identically with no BT_* env), and not the failed test-mode handshake (the quiet run's init PASSED and it faulted anyway). The Thrustmaster isolator -- L4CONTROLS=THRUSTMASTER so the game never opens the RIO while vRIO keeps streaming into serial1 -- was blocked by its own discovery: TM mode dies at boot in ControlsInstanceDirectOf<int>::Update+0x6, mov eax,[eax+0x1c] with EAX=0, at guest 00485E1A. That address resolves cleanly in our map and the loader names BTL4REC.EXE CODE 0x75E1A directly: a real defect in our controls wiring for the non-RIO path, and its own reconstruction brick. Standing facts for the hunt: our exe + live vRIO = fault in ~30-40s; shipped exe + the same stream on the same emulator = fine (two baselines). The ISR and LBE4ControlsManager are archive code; ours in the per-event path are the mapper (MECHMPPR) and the event/receiver plumbing. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
13 lines
588 B
Plaintext
13 lines
588 B
Plaintext
BattleTech v4.10
|
|
BTL4Application::BTL4Application
|
|
GaugeInterpreter: undefined label 'Initialization'
|
|
ColorMapperArmor warning: damage zone dz_missle not found
|
|
ColorMapperArmor warning: damage zone dz_missle not found
|
|
ColorMapperArmor warning: damage zone dz_lmissle not found
|
|
ColorMapperArmor warning: damage zone dz_rmissle not found
|
|
ColorMapperArmor warning: damage zone dz_ftorso not found
|
|
ColorMapperArmor warning: damage zone dz_btorso not found
|
|
Reference to a page you don't own
|
|
PF cr2= 7000 FA64 at 00FF 0000 66D9
|
|
Unhandled exception 000E at 00FF 66D9 ErrCode 0004
|