BT410 5.3.135: the HUD page was never on -- two watcher fixes later, the cockpit has a page again

Chasing what 5.3.132 and 5.3.133 actually turned on found a visible
consequence nobody was looking for.

HeatWatcher::WatchSimulation mirrors the watched subsystem's temperature
into the watcher's own heat alarm.  With every link NULL that mirror was
dead -- the gyro never felt a hot avionics bus, the torso never felt hot
myomers, no ammo bin ever felt its own gun's heat.  It is now live for
all seven watchers.

And the HUD gates its page visibility on the watchdog reading Ready.
Unbound, the watchdog read 0, so the page was hidden.  Bound but with
the percent bug, it read 1, so the page was still hidden.  It took both
fixes to reach 4, and the page now draws:

  [hud] page_visible=1 watchdog=4 heat=0

Flagged in the notes for the next cockpit A/B session: the gauge-ab rig
last scored 98.9% identical against the shipped binary with this page
missing on our side.  If the shipped exe draws it, part of that residual
should close on its own -- so the comparison wants re-running rather
than trusting the old number.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

emulator/render-bridge/pod_render_hud.conf

@@ -0,0 +1,89 @@
+# pod_render_norio.conf -- pod_render_rec with the RIO serial port OFF.
+#
+# The emulator log shows a steady stream of serial1 RX OVERRUN errors on
+# the RIO pipe, and controls post their events at HighEventPriority
+# UNCONDITIONALLY (CONTROLS.HPP:250) -- so a chattering RIO port would
+# flood a priority the background pump always serves first, starving the
+# priority-0 renderer events the load gate waits on.  This conf tests that
+# by removing the port entirely.  Everything else is identical to the rec
+# conf, so a launch here and a hang there isolates the RIO.
+#
+[sdl]
+output=opengl
+# higher,higher not highest: HIGH_PRIORITY_CLASS starved the host desktop;
+# with the retry patches a rare dropout self-recovers (see gauge_rio.conf).
+priority=higher,higher
+[dosbox]
+memsize=32
+machine=svga_s3
+[cpu]
+core=dynamic
+cputype=pentium
+cycles=max
+[sblaster]
+sbtype=sb16
+sbbase=220
+irq=5
+dma=1
+hdma=5
+[mixer]
+# match the EMU8000s' native rate (no resample) and buffer ~60ms so brief
+# emulation-thread stalls (RIO retry recovery) don't audibly chop
+rate=44100
+blocksize=1024
+prebuffer=60
+[serial]
+# RIO on COM1 with the low-latency options (rxpollus/rxburst) so the board's
+# few-ms ACK deadline is met; plasma display on COM2 (real pod has both).
+# VWE fork namedpipe backend (com0com/realport retired -- COM1/COM2 gone):
+# DOSBox = pipe client (retry), vRIO/vPLASMA apps = servers; an unconnected
+# pipe behaves as an unplugged cable so the mission still runs. serialnamedpipe.h
+serial1=disabled
+serial2=namedpipe pipe:vplasma
+# live UNBUFFERED game output: DOS char devices are not buffered, so
+# redirecting stdout to COM3 lands every line immediately.  A normal
+# '> file' redirect stays 0 bytes until the process exits, which hides
+# all progress on a run that does NOT crash.
+serial3=file file:C:\VWE\TeslaRel410\emulator\render-bridge\podlog.txt
+[autoexec]
+mount c "C:\VWE\TeslaRel410\ALPHA_1"
+c:
+cd \REL410\BT
+set VIDEOFORMAT=svga
+rem production pod card init (PARAMETR.BAT:181-186): DIAGNOSE + AWEUTIL per
+rem card -- AWEUTIL /S does the EMU8000 bring-up and DRAM detect the HMI SOS
+rem driver relies on; skipping it left the cards uninitialized (silent).
+rem aweutil /s SKIPPED for now: it verifies the AWE32 GM ROM, which the
+rem emulated cards lack (hangs in a retry loop) -- restore once the ROM is
+rem dumped from a real card. diagnose /s kept (passes, sets mixer config).
+set BLASTER=A220 I5 D1 H5 P330 T6
+c:\sb16\diagnose /s
+set BLASTER=A240 I7 D3 H6 P300 T6
+c:\sb16\diagnose /s
+set BLASTER=A220 I5 D1 H5 P330 T6
+set TEMP=c:\
+rem arena1 city mission (TESTARN.EGG: map=arena1, time=day) with the RIO
+rem attached; stdout redirected so mission-load progress survives kills.
+set BT_JOINTS=1
+set L4VIEWEXT=1
+set BT_STACK_LOG=1
+set BT_MECH_LOG=1
+
+set BT_HUD_LOG=1
+
+
+set BT_GAUGE_LOG=1
+
+set BT_FORCE_TURN=0
+set BT_FORCE_THROTTLE=1.0
+set HEAPSIZE=15000000
+set L4GAUGE=640x480x16
+call setenv.bat r s n p
+32rtm.exe -x
+BTL4REC.EXE -egg testarn.egg > COM3
+
+echo GAME-RC=%errorlevel% >> RC.TXT
+32rtm.exe -u
+echo ALPHA1-RUN-DONE
+pause
+

restoration/source410/BT/HUD.CPP

@@ -151,6 +151,18 @@ void
 		page_visible = False;
 	}
 
+	if (getenv("BT_HUD_LOG"))
+	{
+		static int s_lastVisible = -1;
+		if ((int)page_visible != s_lastVisible)
+		{
+			s_lastVisible = (int)page_visible;
+			DEBUG_STREAM << "[hud] page_visible=" << (int)page_visible
+				<< " watchdog=" << watchdogAlarm.GetLevel()
+				<< " heat=" << heatAlarm.GetLevel() << endl << flush;
+		}
+	}
+
 	//
 	// The blink.
 	//

restoration/source410/BT/MECH4.NOTES.md

@@ -630,3 +630,33 @@ the result into the notes, a commit message and memory as an open defect.
 The hedge ("authentic or shortfall?") was the only thing that saved it
 from becoming received wisdom.  Before recording a number as evidence,
 check what else the conf is driving.
+
+## 5.3.135 -- WHAT THE WATCHER FIXES ACTUALLY TURNED ON
+
+Chasing the downstream of 5.3.132/133 (watchers bound, brownout unit bug
+fixed) found a user-VISIBLE consequence nobody was looking for.
+
+`HeatWatcher::WatchSimulation` mirrors the WATCHED subsystem's temperature
+into the watcher's own 3-level heat alarm.  With every link NULL it held
+NormalHeat forever, so the mirror was dead: the gyro never felt a hot
+avionics bus, the torso never felt hot myomers, no ammo bin ever felt its
+own gun's heat.  That mirror is now live for all seven watchers.
+
+**THE HUD PAGE WAS PERMANENTLY HIDDEN.**  `HUD.CPP:145` gates page
+visibility on `watchdogAlarm.GetLevel() != PoweredSubsystem::Ready`
+(4).  Unbound, the watchdog read 0 -> hidden.  Bound but with the percent
+bug, it read 1 -> still hidden.  It took BOTH fixes to reach 4:
+
+    [hud] page_visible=1 watchdog=4 heat=0
+
+So the HUD page is drawing for the first time.  **Flag for the next
+cockpit A/B session**: the gauge-ab rig last scored 98.9% identical
+against the shipped binary with this page missing on our side -- if the
+shipped exe draws it, some of that residual 1.1% should close on its own,
+and the comparison needs re-running rather than trusted from the old
+number.
+
+Still worth exercising now that the mirror is live: what an AmmoBin does
+with its gun's heat alarm (a cook-off or a feed lockout would be the
+obvious candidates, and the binary is the place to check before assuming
+either).