Joe DiPrimaandClaude Opus 5 566daf358f #191 FIXED + 2-node benched: peers can see a coolant flush again. The manual promises it (p24 'other pilots will see steam rise from your Mech on the battlefield') and on the machine it was FREE: BTL4VID.CPP built a mode-1 effect renderable per Reservoir on its ReservoirState ATTRIBUTE (part_014.c:10308 -- FUN_0041bfc0(sub,'ReservoirState') resolves to the alarm's own address) and the renderable's tick started the pfx when the watched state changed to 1, on whichever node it was built on. The port consolidated those renderables into the psfx layer and hung the spawn off Reservoir::InjectCoolantMessageHandler, which mech4 dispatches for the VIEWPOINT mech only and delivers with a local Dispatch -- so nothing about a flush ever left the flusher's machine. ...

Fixed the way the binary does subsystem replication (MechWeapon::WriteUpdateRecord @004b9690, Emitter @004ba65c, already mirrored in emitter.cpp): extend the record, set recordLength, append the field; the receive half applies it on the EDGE only, so a long flush spawns ONE cloud rather than one per packet.

TRAP AVOIDED, worth recording: the obvious route was Simulation::simulationState, which every subsystem record already carries -- but on a MechSubsystem that cell is the TECH STATUS vocabulary (StateCount 7) and state 1 is DestroyedState, which btl4gaug.cpp:427 paints as a full critical tint. Publishing the flush there would have drawn the reservoir as DESTROYED on every damage schematic for the duration of a flush. Surfaced only because a [flush-tx] probe read the state back as 0 and I went looking for why.

Bench (scratchpad/night18/mp_flush7.sh, madcat/grass, A flushes at frame 900 under BT_FLUSH_TEST): before = A logs the cloud, B logs nothing; after = B spawns the cloud at A's exact position (-241.894,7,-904.136) with a clean STARTED/ended pair.

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

2026-08-15 10:44:58 -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

#191 FIXED + 2-node benched: peers can see a coolant flush again. The manual promises it (p24 'other pilots will see steam rise from your Mech on the battlefield') and on the machine it was FREE: BTL4VID.CPP built a mode-1 effect renderable per Reservoir on its ReservoirState ATTRIBUTE (part_014.c:10308 -- FUN_0041bfc0(sub,'ReservoirState') resolves to the alarm's own address) and the renderable's tick started the pfx when the watched state changed to 1, on whichever node it was built on. The port consolidated those renderables into the psfx layer and hung the spawn off Reservoir::InjectCoolantMessageHandler, which mech4 dispatches for the VIEWPOINT mech only and delivers with a local Dispatch -- so nothing about a flush ever left the flusher's machine.

2026-08-15 10:44:58 -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