vwemirror/TeslaRel410
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

BT410 5.3.60: first rendered frame from a running reconstructed mission

Browse Source 
emulator/render-bridge/first_mission_frame.png -- arena city, textured
buildings, horizon, 28fps, captured from the GL bridge while our build ran a
live mission with the mech walking.  The skeleton went in with it:
[skl] video\mad.skl -> 26 nodes, 19 objects.

Corrects yesterday's RIO framing.  I called serial1 an unplugged cable.  Wrong
twice: VRio.App is running on this rig (the dev-rig default since 7/17), and
the emulator log recorded real byte counts on that port -- RX overruns of 471,
503, 528 -- which an unconnected pipe cannot produce.  The port was LIVE and
streaming during every crashing run.

So the defect is not that we mishandle a disconnected port, it is that we
mishandle a live RIO stream, which is worse: every production pod has a real
RIO.  The shipped binary on the same rig logs 'lost RIO analog request', keeps
sending characters, and runs the mission; ours logs 'RIO never came back from
test mode!' and dies partway through the load.  The overrun counts say the
guest is not draining the port fast enough.  L4RIO.CPP's handshake is authentic
archive code, but MechRIOMapper (BT/MECHMPPR.CPP) is ours -- that is the thread.

pod_render_norio.conf stays the way to get a running mission today, but it is a
workaround: it disables the cockpit's primary input device.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Cyd
2026-07-28 23:33:08 -05:00
co-authored by Claude Fable 5
parent 475ae3106e
commit 9c959e6891
6 changed files with 1095 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files
restoration/source410/RENDER-ROADMAP.NOTES.md
+30
View File
@@ -1072,3 +1072,33 @@ STILL OPEN. The wild reference at EulerAngles::operator=(const LinearMatrix&)
probe shows stable, and all three call sites of that operator pass stack
locals. It is now reproducible on demand (enable serial1) rather than
intermittent, which makes it a tractable hunt instead of a coin flip.
--------------------------------------------------------------------------------
FIRST RENDERED FRAME FROM A RUNNING RECONSTRUCTED MISSION
--------------------------------------------------------------------------------
emulator/render-bridge/first_mission_frame.png -- the arena city, textured
buildings, horizon, 28fps, captured from the GL bridge while our build ran a
live mission with the mech walking under forced throttle. The skeleton went in
with it: [skl] video\mad.skl -> 26 nodes, 19 objects.
CORRECTION TO THE RIO FINDING. I wrote that serial1 pointed at a pipe with no
server and called it an unplugged cable. That is wrong twice over:
* VRio.App is RUNNING on this rig (vRIO v2026.07.16), so the pipe has a
server -- the dev-rig default since 7/17.
* The emulator log recorded real byte counts on that port (RX overruns of
471, 503, 528). An unconnected pipe delivers nothing, so the port was
live and streaming during the crashing runs.
So the defect is NOT "we mishandle a disconnected port". It is "we mishandle a
LIVE RIO stream", which is worse: every production pod has a real RIO. The
shipped binary on the same rig prints "LBE4ControlsManager::Execute, lost RIO
analog request", keeps sending characters (18848 by the time it was killed),
and runs the mission. Ours prints "RIO never came back from test mode!" and
then dies partway through the load. The RX OVERRUN counts say the guest is not
draining the port fast enough, which is the thread to pull: L4RIO.CPP's
init handshake is authentic archive code, but MechRIOMapper (BT/MECHMPPR.CPP)
is ours.
pod_render_norio.conf remains the way to get a running mission today, but it is
a WORKAROUND, not the fix -- it disables the cockpit's primary input device.