Regression from d213c98 (the pod PadRIO/panel coupling fix).
BTGlassPanels_Destroy calls SaveLayout FIRST, unconditionally, before it
looks at whether any windows are left. d213c98 added a SECOND caller
(~LBE4ControlsManager) alongside the existing one in ~PadRIO, so on the
desktop path both run: ~LBE4ControlsManager does `delete rioPointer`, which
fires ~PadRIO -> destroy #1 saves the live windows and zeroes gWinCount ->
destroy #2 then rewrites the whole file from an empty list.
Why only the MFDs vanished, which is the detail that identifies it: external
windows (plasma) already cached a last-known rect (gExtern[].haveLast) and
were written from the cache; the per-display glass windows had no cache and
were simply skipped once their HWND was gone. Hence the reported signature,
"all the MFDs and secondary lines missing, but plasma was still there".
The pod was never affected -- no PadRIO there, so only one destroy, and it
runs BT_GLASS_LAYOUT=load off a frozen master regardless.
Two fixes, because the guard alone would leave the trap armed for the next
teardown-ordering change:
1. glass windows get the same remembered-geometry cache the extern windows
have, kept ACROSS teardown. The file is now monotonic -- a save can
update a line or add one, never drop one.
2. the teardown save is guarded on there being windows to report.
Also corrects the comment at the L4CTRL call site, which claimed the second
call was "a no-op on the PadRIO path". That claim is what made it look safe.
Verified (scratchpad/night13/layoutsave.sh -- the tester's round trip, not a
single launch, since the report was "saved fine, reset on relaunch"):
run 1 one "saved 8 window position(s)" line (was two, the second wiping)
cfg holds all 7 glass windows + plasma
run 2 "restored 7 window position(s)", cfg byte-identical after the trip
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NCJQkvq6G2JNrpVbA75tVZ
A replicant could not start walking between gait-change records. The port's
body case 4 (the task-#64 lockstep twin) is an INSERTION sitting between case 0
and the advance group; in the binary case 4 is a MEMBER of that group
(FUN_004a5678 @004a5678: case 2,3,4,5,8,... -- no turn block, no speed exit),
so case 0's fallthrough is meant to land on Advance(). The insertion caught it.
On a replicant that is not a race but an identity: case 0 arms walk iff
standSpeed < bodyTargetSpeed, and the inserted block resets iff standSpeed <
bspd -- where bspd IS bodyTargetSpeed for a replicant. Same expression, so arm
and reset fire on the same frame, forever, and a peer parked at Standing with a
live replicated demand never cycles. bodyCycleSpeed stays 0 while position
advances from dead reckoning: the skate.
This is the sequel to e91d447 (#82). Before it the replicant branch read the
dead local mapper cell (0 forever), the exit never fired, and the fallthrough
worked BY ACCIDENT. Fixing the dead cell closed the escape hatch.
Fix: case 0 -> goto advance_body_normally, the leg twin's own idiom, restoring
the binary's structure without touching the #64/#82 turn logic.
BT_NO_BODY_FALLTHRU=1 reverts.
Measured (2-node, scratchpad/night13/skatelock.sh):
legacy 336 consecutive locked seconds, bspd=39.2324 bts=39.2324 every line
fixed 0 locks, every pass
master body-Standing samples 52 -> 21 (it locked too, invisibly at mj=0)
turn-in-place intact: pivoter body state 4 x9 / leg state 4 x8, in lockstep
Diagnostics (both keepers): [skate] now carries bstate= -- the field lines
proved "both channels idle" but never named the state, which was the whole
answer; [bodySM]/[peergait] under BT_BODY_SM_LOG instrument the arm->reset pair
and a moving replicant's body channel.
NOT claimed: that this accounts for the night-13 field episodes. That link is
inference -- locked + translating IS the skate signature by construction, but no
bench caught the two together. bstate= settles it next playtest.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NCJQkvq6G2JNrpVbA75tVZ
