#146 respawn: release the DESKTOP throttle -- and close #137, which was never a bug

#137 ("respawn came back with MYOMERS heat MAXED", Oracle; "overheating
generator D", Sauron) sent us through a full two-sided audit of Mech::Reset
and the whole RTIS chain.  Both sides were correct.  The answer was in the
field log all along, one line after the reset:

    [respawn] Mech::Reset 3:30 healed+moved to (...) alive=1
    [techstat] ... every live condition CLEARED
    [techstat] Myomers condition 3 SET        <- Overheating, immediately
    [mppr] in thr=1 -> ...
    [gaitSM] cycleSpeed=14.6 state=12         <- already RUNNING
    [techstat] Condenser5 condition 3 SET     <- "dumping into coolant loop 5"
    [techstat] GeneratorD condition 3 SET     <- Sauron's generator D

The mech respawns STILL UNDER POWER and earns the heat honestly.  Two facts
close it:

1. condition 3 is an OPERATING flag, not an alarm.  Census over one match:
   LLaser_2 33 SET / 33 CLEARED, LLaser_1 31/31, SRM4 26/26, PPC_2 18/18 --
   every volley trips it and clears it.  EVERY subsystem is balanced
   (GeneratorD 5/4, Myomers 5/4, Condenser5 1/1; the extra SET is only the
   log ending mid-heat).  cond 6 BadPower behaves the same (Myomers 8/8).
   Nothing latches.  A post-respawn SET is not evidence of anything.

2. 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.
   That is right for a pod: the throttle is a PHYSICAL lever still under the
   pilot's hand.  Respawning under power is authentic and stays.

Oracle's read that the myomer heat rate "felt right" was correct.

WHAT IS a real defect (#146), desktop only: the glass bridge merely EMULATES
that lever, with the static ramp accumulator sLever (mech4.cpp:3250) zeroed
ONLY by the X all-stop and a direction-crossing snap.  A pad/keyboard pilot
is physically holding nothing and cannot see the lever, so they respawned at
speed for no reason they could perceive -- and ate the heat load above.  The
Thrustmaster/RIO path was never affected: InterpretControls (@004d2150)
rebuilds throttlePosition every frame from the databound throttleForward.

Fix: queue the existing all-stop at Mech::Reset, reusing the proven path
(it already clears the zero-crossing detent too).  LOCAL VIEWPOINT MECH ONLY
-- gBTDrive is the local bridge's state and Reset also runs for replicants,
so an ungated write would all-stop the player whenever a REMOTE mech
respawned.  Pod-safe besides: with a RIO present the key bridge is off and
gBTDrive.throttle is never read.  BT_NO_RESPAWN_THROTTLE_RELEASE=1 reverts.

Benched 2-node (scratchpad/night13/throttlerespawn.sh): the release fires
1:1 with local respawns on both nodes independently (A 2/2, B 1/1) and never
spuriously.  HONEST LIMIT: the viewpoint gate was NOT stressed -- B ran
Mech::Reset 0 times for A's mech, so the remote-respawn path never fired.
The gate is correct by construction (the isPlayerMech idiom), not proven.
BT_AUTODRIVE cannot test the lever itself (forced mode reads forcedThrottle,
never sLever), and the zeroing path is the X button, proven in the field.

Also keeps BTReportHeatAtReset (heat.cpp, BT_HEAT_LOG): the [heat-t] census
runs on a 5s timer, far too coarse to sample AT the reset.  It is what
proved every roster subsystem including all six Condensers sits at T=77
start=77, and it corrected an earlier false negative from filtering on
IsDerivedFrom(HeatSink).

KB: context/decomp-reference.md gains the routine/self-clearing condition
semantics + this post-mortem, so it is not re-chased; cross-ref in
context/gauges-hud.md.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018SgmXGNMXavXiafKXf9MDC

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] <sub> condition <n> 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

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

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;
+	}
+}

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;

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)

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