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

BT410 5.3.134: the mech could run all along -- the gait "shortfall" was my own soak harness fighting the measurement

Browse Source 
The top open question from 5.3.128 is closed, and not in my favour.  I
reported that the mech demands 35.9 u/s while the gait delivers 7.0 and
filed it as a possible gait defect.  The run I took that from was
pod_render_telem, which still had BT_SUPERSTOP_SOAK hauling the throttle
to -0.5 every six seconds: the mech was never given time to reach speed,
and every sample caught the first seconds of a climb about to be thrown
into reverse.

BT_GAIT_LOG -- new, state-change-triggered so a long run stays readable
-- on a clean full-throttle run shows the ladder working exactly as
designed: 0 -> 5.7 -> 17.0 (the walk-to-run step) -> 25.5 -> 35.7 ->
44.35 against a target of 44.837, with leg and body cycles converged and
six clip transitions along the way.  runSpeedMax reads 80.06, raised off
its unsourced default by the myomers, which is the 5.3.129 landing doing
its job.

So the instability model pinning high during a climb was correct all
along: a mech demanding far more speed than it has IS gunning the
engine.  Nothing to fix in the gait or the instability model.

Method lesson recorded in the notes: I took a measurement from a rig
whose harness was actively fighting the thing being measured, then wrote
it into the notes, a commit message and memory as an open defect.  Only
the hedge kept it from becoming received wisdom.  Check what else the
conf is driving before recording a number as evidence.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
Cyd
2026-08-12 22:41:10 -05:00
co-authored by Claude Fable 5
parent b1e9a09a6e
commit 0bc2c04b03
3 changed files with 154 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
emulator/render-bridge/pod_render_gait.conf
+89
View File
@@ -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_GAIT_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/MECH.CPP
+26
View File
@@ -1502,6 +1502,32 @@ void
<< " accel=" << bodyAcceleration.Length()
<< " unstable=" << unstablePercentage << endl << flush;
}
//
// The GAIT readout: where the speed shortfall actually lives. Prints
// only on a state change so a long run stays readable.
//
if (getenv("BT_GAIT_LOG"))
{
static int s_lastLeg = -1, s_lastBody = -1;
int leg = (int)legStateAlarm.GetLevel();
int body = (int)bodyStateAlarm.GetLevel();
if (leg != s_lastLeg || body != s_lastBody)
{
s_lastLeg = leg;
s_lastBody = body;
DEBUG_STREAM << "[gait] leg=" << leg << " body=" << body
<< " legCycle=" << legCycleSpeed
<< " bodyCycle=" << bodyCycleSpeed
<< " speed=" << currentBodySpeed
<< " target=" << bodyTargetSpeed
<< " standSpeed=" << standSpeed
<< " runCap=" << runSpeedMax
<< " clip6=" << animationClips[6]
<< " clip8=" << animationClips[8]
<< endl << flush;
}
}
}
//
restoration/source410/BT/MECH4.NOTES.md
+39
View File
@@ -591,3 +591,42 @@ NOTE ON PROVENANCE: the binary's own scale SITE was not located in code;
the /100 is inferred from the field name plus authored data that is
unambiguous. Recorded as such rather than claimed as a byte-verified
decode.
## 5.3.134 -- THE "GAIT SHORTFALL" WAS A CONFOUNDED MEASUREMENT
The top open question from 5.3.128 -- "the mech demands 35.9 u/s and the
gait delivers 7.0, authentic acceleration or a gait shortfall?" -- is
answered: **authentic acceleration, and the measurement was confounded by
my own soak harness.**
The run I drew that reading from was `pod_render_telem`, which still had
`BT_SUPERSTOP_SOAK` driving the throttle to -0.5 every six seconds. The
mech was never given time to reach top speed; every sample caught the
first seconds of a climb that was about to be thrown into reverse.
`BT_GAIT_LOG` (new, state-change-triggered) on a clean full-throttle run
shows the ladder working exactly as designed:
leg=5 speed=0 -> stand-to-walk
leg=7 speed=5.69
leg=6 speed=17.0 -> the walk-to-run step
leg=11 speed=17.7
leg=12 speed=25.5
leg=13 speed=35.7
leg=12 speed=44.35 target=44.837 legCycle=bodyCycle=44.837
The mech accelerates 0 -> 45 u/s through six clip transitions and settles
on its demand. `runSpeedMax` reads 80.06, raised off its unsourced
default by the myomers -- the 5.3.129 landing doing its job. Both
run-clip slots are bound (clip6=344, clip8=345).
So the instability model pinning high during a climb was CORRECT all
along: a mech demanding far more speed than it has IS gunning the engine.
Nothing to fix in the gait or the instability model.
**METHOD LESSON, the expensive kind:** I took a measurement from a rig
whose harness was actively fighting the thing being measured, and wrote
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.