diff --git a/context/decomp-reference.md b/context/decomp-reference.md index 6f11a2a..0351db7 100644 --- a/context/decomp-reference.md +++ b/context/decomp-reference.md @@ -430,6 +430,31 @@ From the weapon `.SUB` records + the charge-curve `.data` constants (PE-parsed a recomputes output via `(1 − damage) × rated` and zeroes it. stateAlarm 4's producer = the THERMAL BREAKER in GeneratorSimulation itself; a 2026-08-03 destruction→state-4 bridge was removed as unfounded. +- **THE CONDITION FLAGS ARE ROUTINE, NOT ALARMS — field-verified 2026-08-08 [T2]:** a + `[techstat] condition SET` is an *operating* flag ("this component is above + nominal / browned out RIGHT NOW"), not a fault report. Census over a full Steam match + (`steam_20260806_c_michael_XIAOLONG.log`): cond 3 **Overheating** fires 33× on LLaser_2, + 31× LLaser_1, 26× SRM4, 18× PPC_2 — every weapon trips it on each volley and clears it on + cooldown; cond 6 **BadPower** fires 8× on Myomers, 3× each on SLaser_1/PPC_1/MLaser_1 as + the bus browns out under simultaneous draw. **Every subsystem's SET/CLEARED counts are + balanced** (GeneratorD 5/4, GeneratorA 8/7, Myomers 5/4, Condenser5 1/1 — the odd extra SET + is only the log ending mid-heat). Nothing latches. **Never read a post-respawn `condition 3 + SET` as a reset failure** — that inference cost a full two-sided reset audit (#137 below). + Diagnose a heat complaint from the SET/CLEARED *balance* and the throttle state, not from + the presence of a SET. +- **#137 "respawn came back with MYOMERS heat MAXED" = NOT A BUG, closed 2026-08-08 [T2]:** + `Mech::Reset` is clean on both sides — bench: every roster subsystem incl. all six + Condensers at `T=77 start=77`; field log: every live condition CLEARs 12–16 lines after each + reset. The heat is real and immediate because **the mech respawns still under power**: at the + reset the log reads `thr=1`, `cycleSpeed=14.6`, gait state 12 (running), and the myomers → + Condenser5 → GeneratorD trip Overheating within ~1–2 s. `Mech::Reset`'s subsystem loop starts + at **index 2** and the ControlsMapper is **index 0**, so the throttle is never reset — and the + binary does the same, which is correct for a pod whose throttle is a PHYSICAL lever still + under the pilot's hand. **Desktop caveat (real, and separate):** the glass bridge emulates + that lever with a file-static ramp accumulator `sLever` (mech4.cpp:3250), zeroed ONLY by the + X all-stop and a direction-crossing snap — so a pad/keyboard pilot, who is physically holding + nothing, likewise respawns at speed with the lever state invisible. Port-layer question, not + a heat bug. - **DEATH SCORE COST decoded 2026-08-02 (#118 tail) [T1]:** the death handler tail `@004c07cd-0x4c0828` (inside the @004c05c4 export gap — missing from the #52 reconstruction) gates on `advancedDamageOn`(+0x264) and hands the ENGINE base diff --git a/context/gauges-hud.md b/context/gauges-hud.md index 55d65a7..84be613 100644 --- a/context/gauges-hud.md +++ b/context/gauges-hud.md @@ -414,6 +414,14 @@ Verified live: bay fire → lamp 0xD (the LRM's select button) flashes 0x37 + en on detonation/purge. Diagnostics: `BT_LAMP_LOG` → `[techstat]`/`[galarm]`/`[lamp]`. Details + the four load-bearing fixes en route: [[open-questions]] + [[decomp-reference]] §GaugeAlarm. +**These conditions are ROUTINE and SELF-CLEARING [T2, field-verified 2026-08-08].** A `SET` is an +operating state, not a fault: every laser volley trips Overheating (cond 3) and clears it on +cooldown (33× on one LLaser in a single match), and BadPower (cond 6) flickers whenever +simultaneous draw browns the bus. Across a full match every subsystem's SET/CLEARED counts are +balanced — nothing latches. So a lamp flashing after a respawn is the mech *operating*, not a +failed reset; diagnose from the SET/CLEARED balance, never from a lone SET. Full census + the +#137 post-mortem it settled: [[decomp-reference]] §TechStatus. + ## ConfigMapGauge (the weapon panel's trigger-config joystick) — LIVE via LinkToEntity (2026-07-21) The per-weapon btjoy.pcc joystick image + 4 cm_* state lamps (off/other/only/both) showing, for each mappable fire button (Pinky/ThumbLow/Trigger/ThumbHigh), whether THIS panel's weapon diff --git a/game/reconstructed/heat.cpp b/game/reconstructed/heat.cpp index 107d68b..0a3aea9 100644 --- a/game/reconstructed/heat.cpp +++ b/game/reconstructed/heat.cpp @@ -1446,3 +1446,43 @@ int BTHeatSinkBankCoolantFraction(Subsystem *sub, Scalar *out) *out = bank->CoolantFractionOf(); return 1; } + +//===========================================================================// +// BTReportHeatAtReset -- #137 forensic (ungated when BT_HEAT_LOG is set). +// +// The [heat-t] census runs on a 5-second per-instance timer, which is far too +// coarse to answer the question #137 actually poses: "respawn came back with +// MYOMERS heat MAXED". Is the temperature high BECAUSE the reset did not +// clear it, or because it climbs again within the first second? Those need a +// sample taken AT the reset, which is what this is. Called from Mech::Reset +// immediately after the subsystem sweep, so every heat-bearing subsystem +// reports the temperature the reset actually left it at. +//===========================================================================// +void BTReportHeatAtReset(void *mech_v) +{ + if (mech_v == 0 || getenv("BT_HEAT_LOG") == 0) + return; + Entity *mech = (Entity *)mech_v; + const int count = mech->GetSubsystemCount(); + for (int i = 0; i < count; ++i) + { + Subsystem *s = mech->GetSubsystem(i); + if (s == 0) + continue; + // UNFILTERED first: the earlier pass filtered on IsDerivedFrom(HeatSink) + // and reported no Condensers. That test rides a hand-built Derivation + // chain, so a false negative there is indistinguishable from "not in the + // roster" -- name every roster entry and say whether the test passed. + if (!s->IsDerivedFrom(*HeatableSubsystem::GetClassDerivations())) + { + DEBUG_STREAM << "[heat-reset] roster[" << i << "] " + << (s->GetName() ? s->GetName() : "?") + << " (not HeatSink-derived)" << "\n" << std::flush; + continue; + } + HeatableSubsystem *sink = (HeatableSubsystem *)s; + DEBUG_STREAM << "[heat-reset] " << (s->GetName() ? s->GetName() : "?") + << " T=" << (float)sink->currentTemperature + << "\n" << std::flush; + } +} diff --git a/game/reconstructed/mech4.cpp b/game/reconstructed/mech4.cpp index 9c2360c..b4346c2 100644 --- a/game/reconstructed/mech4.cpp +++ b/game/reconstructed/mech4.cpp @@ -2249,6 +2249,54 @@ void BTRecomputeCondenserValves((Entity *)this); } + // #137 forensic: sample every heat-bearing subsystem's temperature AT the + // reset, so "respawn came back with heat MAXED" can be split into "the + // reset did not clear it" vs "it climbs again immediately". + { + extern void BTReportHeatAtReset(void *mech_v); + BTReportHeatAtReset((void *)this); + } + + // --- DESKTOP THROTTLE RELEASE (#146) -- PORT LAYER, desktop-only --------- + // The pod's throttle is a PHYSICAL lever and the binary deliberately + // leaves it alone across a respawn: Reset's subsystem loop starts at + // index 2 and the ControlsMapper is index 0, so a pod pilot comes back + // under whatever power their hand is still holding. Authentic; it stays. + // + // The desktop bridge only EMULATES that lever, with the persistent ramp + // accumulator sLever below -- and a pad/keyboard pilot is physically + // holding nothing, with the lever position invisible to them. So they + // respawned at speed for no reason they could see, and the mech earned a + // real heat load straight out of the drop zone (myomers -> Condenser5 -> + // GeneratorD all tripping Overheating inside 1-2s). That is the true + // cause of the "#137 respawn came back with heat MAXED" reports -- the + // reset itself was always clean. Field-diagnosed from Sauron's + // 2026-08-06 log, which reads thr=1 / cycleSpeed=14.6 AT the reset. + // + // Reuse the existing all-stop path instead of touching sLever directly: + // it already zeroes the lever AND clears the zero-crossing detent, and it + // lives inside the virtual-controls block that owns that state. + // + // LOCAL VIEWPOINT MECH ONLY -- gBTDrive is the local bridge's state and + // Reset also runs for replicants, so an ungated write here would all-stop + // the player every time a REMOTE mech respawned. (Same guard idiom as + // the isPlayerMech test in PerformAndWatch.) Pod-safe besides: with a RIO + // present mechmppr's key bridge is off (BTRIODevicePresent, mechmppr.cpp + // :672) and gBTDrive.throttle is never read at all. + // BT_NO_RESPAWN_THROTTLE_RELEASE=1 reverts. + if (application != 0 && (Entity *)this == application->GetViewpointEntity()) + { + static const int s_releaseThrottle = + getenv("BT_NO_RESPAWN_THROTTLE_RELEASE") ? 0 : 1; + if (s_releaseThrottle) + { + gBTDrive.allStop = 1; + if (getenv("BT_DEATH_LOG")) + DEBUG_STREAM << "[respawn] desktop throttle released (all-stop queued)\n" + << std::flush; + } + } + // --- locomotion pre-run + interest gates (a reset master must tick) --- SetPreRunFlag(); if (interestCount == 0) interestCount = 1; diff --git a/scratchpad/night13/close137.py b/scratchpad/night13/close137.py new file mode 100644 index 0000000..82cea0f --- /dev/null +++ b/scratchpad/night13/close137.py @@ -0,0 +1,127 @@ +"""Night 13: close #137 (not a bug) and file the desktop throttle-latch follow-up. ASCII only.""" +import sys +sys.path.insert(0, r"C:\git\bt411\scratchpad\night7") +import gitea + +BODY_137 = """**NOT A BUG -- closing (2026-08-08).** The reset is correct on both sides. The +heat is real, and the mech earned it: it respawns still under power. + +## What the field log actually shows + +From Sauron's match log (`steam_20260806_c_michael_XIAOLONG.log`), the respawn at line 39450: + +``` +39450 [respawn] Mech::Reset 3:30 healed+moved to (...) alive=1 zones=21 subsys=33 + [techstat] SLaser_1 / LLaser_1 / HUD / Gyroscope / Avionics / GeneratorA / HeatSink + ... condition CLEARED <- every live condition clears + [techstat] Myomers condition 3 SET <- Overheating, immediately + [mppr] in thr=1 pre=1 -> ... + [gaitSM] cycleSpeed=14.6 legCycle=14.6 state=12 <- already RUNNING + [techstat] Condenser5 condition 3 SET <- "dumping into coolant loop 5" +39519 [techstat] GeneratorD condition 3 SET <- Sauron's generator D +``` + +`[rstat]` fires about once per second (98 frames @ 10.2ms), and the reset plus the myomers trip sit +inside one rstat block -- so myomers overheat in well under a second, generator D in one to two. + +The reset itself is clean: **every** live condition CLEARs 12-16 lines after each `Mech::Reset`, at +every respawn in the log. The synthetic bench agrees -- every roster subsystem, including all six +Condensers, reads `T=77 start=77` at the reset. + +## Why it looked like maxed heat + +**`condition 3` is an operating flag, not an alarm.** Census over the whole match: + +| subsystem | cond 3 SET | CLEARED | +|---|---|---| +| LLaser_2 | 33 | 33 | +| LLaser_1 | 31 | 31 | +| SRM4 | 26 | 26 | +| PPC_2 | 18 | 18 | +| GeneratorD | 5 | 4 | +| Myomers | 5 | 4 | +| Condenser5 | 1 | 1 | + +Every weapon trips Overheating on each volley and clears it on cooldown. **Every subsystem is +balanced** -- the odd extra SET is only the log ending mid-heat. Nothing latches, nothing sticks. +`condition 6` (BadPower) behaves the same way (Myomers 8/8, PPC_1 3/3, MLaser_1 3/3) as the bus +browns out under simultaneous draw. GeneratorD's longest continuous overheat came out normally. + +So the post-respawn SET is the mech *operating*, not a failed reset. + +## Why the heat arrives instantly + +The mech comes back **at whatever throttle the pilot left**: `thr=1`, `cycleSpeed=14.6`, gait state +12 at the instant of reset. `Mech::Reset`'s subsystem loop starts at **index 2**, and the +ControlsMapper is **index 0** -- so the throttle is never reset. + +**The binary does exactly the same.** That is correct for a pod: the throttle is a physical lever +still under the pilot's hand. Respawning under power is authentic behaviour. + +Oracle's read that the myomer heat rate "felt right" was correct, and matches the data. + +## Ruled out along the way + +`Mech::Reset` dispatch, the full subsystem RTIS chain (Generator `@004b215c` is an +instruction-for-instruction match; HeatSink `@004ad760` faithful; every RTIS class has a +DeathReset), stale coolant-loop links (`linkedSinks` is written only in the streaming ctor and +cannot drift), and the valve fractions (`BTRecomputeCondenserValves == @0049f788`). + +## Follow-up + +The one genuine defect found is a desktop-only input issue, filed separately -- see the throttle +latch ticket. It does not affect the pod. + +Knowledge base updated so this is not re-chased: `context/decomp-reference.md` §TechStatus (the +routine/self-clearing semantics + this post-mortem) and `context/gauges-hud.md`.""" + +TITLE_NEW = "Desktop/Steam: virtual throttle lever survives death -- you respawn already running" + +BODY_NEW = """Split out of #137, which was closed as not-a-bug. The heat model and the reset are +both correct; this is a port-layer input issue and it affects **desktop/Steam only, never the pod**. + +## The defect + +On the pod the throttle is a physical lever. Respawning under power is authentic -- the pilot's hand +is on it, they can see and feel where it is, and `Mech::Reset` deliberately does not touch it (the +subsystem loop starts at index 2; the ControlsMapper is index 0). The binary behaves the same way. + +The desktop glass bridge emulates that lever with a **file-static ramp accumulator**: + +* `sLever` -- `static float sLever = 0.0f;` (`game/reconstructed/mech4.cpp:3250`) +* published each frame as `gBTDrive.throttle = sLever` (mech4.cpp:3892/3897) +* consumed as `key_throttle` -> `throttlePosition` (mechmppr.cpp:677, :780) + +The only things that zero `sLever` are the **X-button all-stop** (mech4.cpp:3754) and a +direction-crossing snap (:3842). **Nothing on death or respawn touches it.** + +So a pad/keyboard pilot who dies at speed respawns at speed -- while physically holding nothing, and +with the lever position invisible to them. The pod's authenticity argument does not cover this case: +there is no lever to feel, and a gamepad stick self-centers, so the input affordance actively +contradicts the latched state. + +Observed consequence in the field (Sauron's log, the #137 evidence): the mech leaves the drop zone +at `thr=1` / `cycleSpeed=14.6` the instant it spawns, and the myomers, Condenser5 and GeneratorD all +trip Overheating within one to two seconds. Reads to the player as "respawned with heat maxed". + +Note this is **not** the same as the Thrustmaster/RIO path, which is already correct: +`MechThrustmasterMapper::InterpretControls` (`@004d2150`) recomputes `throttlePosition` from scratch +every frame off the live `throttleForward`/`throttleReverse` states, and `throttleForward` is +databound (written by the input layer each frame). Only the desktop `sLever` accumulator latches. + +## Suggested fix + +Zero `sLever` (and the detent) on respawn in the desktop bridge only -- the same treatment the +X all-stop already applies -- so a desktop pilot comes back stopped. Gate it so pod builds keep the +authentic physical-lever behaviour. + +This is a gameplay-behaviour decision as much as a bug fix: it changes whether desktop players +respawn moving or stopped. Worth a call before it ships. + +## Not yet done + +Not fixed, not benched. Filed from a static read of the input path plus the field log.""" + +gitea.close(137, BODY_137) +num = gitea.create(TITLE_NEW, BODY_NEW) +print("closed 137; created:", num) diff --git a/scratchpad/night13/throttlerespawn.sh b/scratchpad/night13/throttlerespawn.sh new file mode 100644 index 0000000..43f5a5d --- /dev/null +++ b/scratchpad/night13/throttlerespawn.sh @@ -0,0 +1,68 @@ +#!/usr/bin/env bash +# ========================================================================= +# #146 -- desktop virtual throttle must be RELEASED on respawn. +# +# The pod's throttle is a physical lever and Mech::Reset deliberately leaves +# it alone (subsystem loop starts at index 2; ControlsMapper is index 0) -- +# authentic, kept. The desktop bridge only EMULATES that lever with the +# static ramp accumulator sLever, so a pad/keyboard pilot respawned at speed +# while holding nothing. Fix: queue the existing all-stop at Mech::Reset, +# LOCAL VIEWPOINT MECH ONLY. +# +# WHAT THIS BENCH ACTUALLY TESTS. It does NOT test "does zeroing sLever +# stop the mech" -- that path is the X all-stop button, proven in the field +# every day, and BT_AUTODRIVE cannot exercise it anyway (forced mode reads +# gBTDrive.forcedThrottle, never sLever -- mechmppr.cpp:677). +# +# It tests the one thing the fix could genuinely get WRONG: the viewpoint +# gate. Mech::Reset also runs for REPLICANTS, so an ungated write to the +# global gBTDrive would all-stop the local player every time a REMOTE mech +# respawned -- a far worse bug than the one being fixed. +# +# PASS: A (who dies) logs "[respawn] desktop throttle released" once per +# Mech::Reset, and B logs it ZERO times while A is respawning. +# FAIL: any occurrence in B's log -> the gate leaks and remote respawns +# stop the local pilot. +# +# A self-damages to death on a timer; B just flies and watches. +# ========================================================================= +set -x +. /c/git/bt411/scratchpad/night6/bench_common.sh +cd /c/git/bt411/content || exit 1 +taskkill //F //IM btl4.exe > /dev/null 2>&1 +sleep 2 +rm -f tr_a.log tr_b.log tr_relay.log +bt_expert_egg MP.EGG TR.EGG +sed -i "s/^map=.*/map=grass/; s/^time=.*/time=day/; s/^vehicle=.*/vehicle=madcat/" TR.EGG + +# B: the OBSERVER. Also driving, so a leaked all-stop would be doubly visible. +( export BT_AUTODRIVE=0.6 + export BT_DEATH_LOG=1 BT_MP_LOG=1 BT_KEY_LOG=1 + bt_launch tr_b.log TR.EGG 0x0C -net 1601 ) +sleep 2 +# A: drives, dies repeatedly, respawns. +( export BT_AUTODRIVE=0.8 BT_SELF_DAMAGE=8 + export BT_DEATH_LOG=1 BT_MP_LOG=1 BT_KEY_LOG=1 + bt_launch tr_a.log TR.EGG 0x03 -net 1501 ) +sleep 5 +python ../tools/btconsole.py TR.EGG 127.0.0.1:1501 127.0.0.1:1601 > tr_relay.log 2>&1 & +RELAY=$! +sleep 280 +kill $RELAY 2>/dev/null +sleep 3 +bt_kill_ours; sleep 2; taskkill //F //IM btl4.exe > /dev/null 2>&1; sleep 3 + +echo "=================== #146 THROTTLE RELEASE ON RESPAWN ===================" +echo "--- A: how many respawns, how many releases? (must be 1:1) ---" +echo -n " A Mech::Reset .......... "; grep -ac "Mech::Reset" tr_a.log +echo -n " A throttle released .... "; grep -ac "desktop throttle released" tr_a.log +echo +echo "--- B: the VIEWPOINT GATE. Must be 0 releases despite seeing A respawn. ---" +echo -n " B Mech::Reset (incl. replicant) .... "; grep -ac "Mech::Reset" tr_b.log +echo -n " B throttle released (MUST BE 0) .... "; grep -ac "desktop throttle released" tr_b.log +echo +echo "--- A: the release must sit INSIDE the reset block ---" +grep -aE "Mech::Reset|desktop throttle released" tr_a.log | head -8 +echo +echo "--- B: same window, to show B saw the respawn and still did not release ---" +grep -aE "Mech::Reset|desktop throttle released" tr_b.log | head -8