Joe DiPrimaandClaude Opus 5 86c1f54644 #183 FIXED: the ENG-page BAY FIRE icon could never light -- the gauge cluster's ammo-bin link was a RAW-OFFSET walk that resolved to NULL. Oracle reported no bay-fire icon where the jam icon shows. Everything upstream was already correct and #47-verified: the AmmoBin arms cookOffArmed on the authentic gate (heat alarm FAILURE + rounds remaining), counts a fixed 10s fuse and detonates; the widget exists (btefire.pcc, TwoState) and its coordinates are BYTE-FAITHFUL to the binary (jam 0xa0,0xb2 / fire 0x121,0xb6, part_014.c:6510-6522 -- note the machine puts them in DIFFERENT places, so the report's 'same place as the jam icon' premise is wrong). The break was BallisticWeaponCluster::Execute resolving the bin with ResolveLink(subsystem + 0x43c) -- the BINARY's layout applied to our compiled ProjectileWeapon, i.e. the databinding trap the conventions forbid. It returned NULL, so BTAmmoBinCookOffArmed(NULL) read 0 forever and the icon had no input. The typed bridge already existed: BTWeaponAmmoBin (projweap.cpp) was written in July for this exact trap when the ammo DIGITS failed to bind the same way -- these two call sites were simply missed. Both now use it; TestInstance's raw bin+0x180 round-count read replaced with a new typed BTAmmoBinRoundCount. Rig added (BT_BAYFIRE_TEST=<seconds> drives the AUTHENTIC arming condition, same hook family as BT_VALVE/BT_FLUSH_TEST) plus an edge-only [gau-fire] receipt. Measured: before, bin=00000000 cookOffArmed=0 on every cluster; after, each cluster binds a real bin and the burning rack alone reports cookOffArmed 0->1->0 across arm and detonation while its neighbours stay 0. NOTE #47's fix was correct but only 'data path rig-verified' with the pixels left to the field -- this is why that gap mattered. ...

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-15 11:04:02 -05:00

..

fwd

Initial commit: bt411 -- standalone Windows BattleTech (Tesla 4.10 port)

2026-07-05 21:03:40 -05:00

glass

#170 root-caused + fixed: the #163 SteamAPI_Shutdown was the crash -- at round end every peer's close events are ALWAYS in flight, and Shutdown tears client state down while steamclient's own service thread dispatches them (the field stack: a steamclient worker calling literal NULL, zero btl4 frames, 7 hits / 3 machines / one module-relative stack). BTSteamNet_ShutdownAll is now a QUIESCE: steamActive gated FIRST, linger closes ('round over' not timeouts), one SNS drain, 60ms grace, NO SteamAPI_Shutdown -- and every exit path dies via TerminateProcess (menu-quit no longer returns through the CRT; it uses BTOrderlyDie like everything else, so the 883 detach deadlock stays dead too). Status callback guarded for the dying window. Crash filter now names foreign DLL frames (module+offset via VirtualQuery/GetModuleFileName) so the next foreign-thread crash arrives pre-symbolized. Exit contract: steam-networking.md

2026-08-12 23:23:23 -05:00

original

SeekVoltageGraph: full reconstruction -- the eng-page POWER graph + top-box eraser (Gitea #11)

2026-07-19 20:27:39 -05:00

reconstructed

#183 FIXED: the ENG-page BAY FIRE icon could never light -- the gauge cluster's ammo-bin link was a RAW-OFFSET walk that resolved to NULL. Oracle reported no bay-fire icon where the jam icon shows. Everything upstream was already correct and #47-verified: the AmmoBin arms cookOffArmed on the authentic gate (heat alarm FAILURE + rounds remaining), counts a fixed 10s fuse and detonates; the widget exists (btefire.pcc, TwoState) and its coordinates are BYTE-FAITHFUL to the binary (jam 0xa0,0xb2 / fire 0x121,0xb6, part_014.c:6510-6522 -- note the machine puts them in DIFFERENT places, so the report's 'same place as the jam icon' premise is wrong). The break was BallisticWeaponCluster::Execute resolving the bin with ResolveLink(subsystem + 0x43c) -- the BINARY's layout applied to our compiled ProjectileWeapon, i.e. the databinding trap the conventions forbid. It returned NULL, so BTAmmoBinCookOffArmed(NULL) read 0 forever and the icon had no input. The typed bridge already existed: BTWeaponAmmoBin (projweap.cpp) was written in July for this exact trap when the ammo DIGITS failed to bind the same way -- these two call sites were simply missed. Both now use it; TestInstance's raw bin+0x180 round-count read replaced with a new typed BTAmmoBinRoundCount. Rig added (BT_BAYFIRE_TEST=<seconds> drives the AUTHENTIC arming condition, same hook family as BT_VALVE/BT_FLUSH_TEST) plus an edge-only [gau-fire] receipt. Measured: before, bin=00000000 cookOffArmed=0 on every cluster; after, each cluster binds a real bin and the burning rack alone reports cookOffArmed 0->1->0 across arm and detonation while its neighbours stay 0. NOTE #47's fix was correct but only 'data path rig-verified' with the pixels left to the field -- this is why that gap mattered.

2026-08-15 11:04:02 -05:00

btl4main.cpp

one night = ONE log file: the 8MB size roll-over retired (it cost field evidence the moment it existed -- night16: Elengil's incident window sat in an unsent pre-rotation part; testers attach 'the log' = the newest part). The 6am log-day boundary stays. Transport moves to players/SENDLOGS.bat (ships at the dist root): one double-click zips every log/matchlog/lastrun from the last 36h to a Desktop BTLOGS_<machine>_<date>.zip (~10:1 text compression -- a 13MB night = 1.8MB, well under Discord's 10MB free cap, which is what the roll-over was protecting against). Handout HOW TO REPORT updated; mkdist carries the bat

2026-08-13 00:45:21 -05:00