We have released RumiCar Simulator v7.8.0. The release notes below are also available on GitHub.
v7.8.0
The final consistency audit of Stage AV (loose surfaces v7.6.0, four-wheel friction brakes v7.7.0) and rulings on its seven carry-overs. The driving physics is unchanged down to the byte (the frozen benchmarks f0–f3, official-race verifyHash values and existing share URLs are all unchanged). (1) The HUD and race-report “friction-circle usage” is now normalized by the peak. The display is the normalized slip σ shown as a percentage; on tarmac the peak is at σ=1, so “100% = the limit” reads correctly, but on a loose surface the peak is at σ=3, so in v7.6.0/v7.7.0 a car running at maximum grip displayed 300%. On digging surfaces the display now divides by the actual peak σ of that surface’s tire law (exactly 3 with the built-in tires’ default muDecay), so “100% = the peak, over 100% = sliding past the peak” reads the same on tarmac and on loose. It is a display-layer change: tarmac goes through the same expression as before, so its value is unchanged, and the physics state does not move (6 assertions added to the standing gate wf_av1_loose.mjs: 39 → 45, including that swapping the peak σ leaves the physics state bit-identical while only the display scales — on both the tarmac and the tabletop semi-implicit braking paths — and, as a static check on the source, that the only line reading sigPk is the display assignment). The race report’s suitability label (“a lot of sliding” at a peak usage of 150% or more) is also judged on the normalized value. (2) We measured why four-wheel friction brakes brake weaker on the tabletop / mid-scale, and hand the fix over as a carry-forward. (The figures in this item come from a one-off measurement harness that is not shipped in the repository.) The mechanism written in v7.7.0 (“the semi-implicit wheel ODE uses a safe-side tire stiffness”) is not the main cause — moving the damping to the local slope does not fix it (friction/motor ratio 0.758 → 0.685, computed from the actual final speed; the 0.77 printed by the standing gate uses the target final speed). The real cause is the operator split that freezes the ground-contact speed during the implicit update, and the error scales with the substep width. Conversely, the current tabletop / mid-scale precision-v2 engine brakes about 36% weaker on the tabletop and about 32% weaker at mid-scale than the reference solution with the motor brake (the explicit integration used before v4.0.0, converged to within 0.1% when the substep cap is raised from 256 to 4096; decelerations computed from the actual final speed: 2.34 vs 3.65 and 2.49 vs 3.65 m/s²), and running the current semi-implicit scheme with 4096 substeps converges to the reference — the difference is purely splitting error. This quantity was not part of the v4.0.0-era A/B characterization. A naive fix — predicting the change of ground speed from the previous substep and integrating the slip variable implicitly — brings the motor brake back to within −5% of the reference, but for four-wheel braking it turns into a period-2 numerical oscillation at the production substep width (the body is pushed forward in 22% of substeps), so it is not a valid measurement — a real fix has to solve the wheel–body coupling within the same substep. Because a fix changes the default tabletop v2 physics (and so the reproducibility of practice records), it is not implemented in this version; the mechanism and the numbers are recorded in §13.16 of the physics notes (adoption is a decision for a separate version). (3) The case where one wheel’s command turns drive-side during braking on LSD-equipped cars is left as is. The differential’s transfer cap is an absolute value (8, mass-normalized), so it happens where the axle’s braking force is small (the tabletop), but it happens with the default motor brake too (85 of 504 runs), the totals and energy invariants hold, and it is the same thing as differential wind-up in a real car. (4) The brake-split presets are not made drivetrain-dependent. That an FR car never loses a recovery cell while FF/AWD cars do (measured in v7.7.0) is now stated in the equipment selector’s tooltip and in the physics notes; a per-drivetrain default would make the same equipment name mean different things per car, unreadable in a record’s conditions. (5) The four deliberately unasserted lines of v7.6.0 (in physics_v2.js: CaTot, dFxdvw, kD and the reversing-mode CaF/CaR — the places that estimate the digging-inclusive longitudinal tire stiffness on the linear-region, safe side) were re-examined by breaking them one at a time across a sweep of 3 regimes × 2 surfaces (the built-in loose surface and a test surface whose digging ramp dig/digSat is 10× steeper, i.e. +37% longitudinal stiffness versus tarmac for the normal tire and +35% for the rain tire) × 3 grips × 3 car types × 4 commands × 3 steering states × 3 equipment sets = 1,944 traces (a harness that is not shipped): no non-finite values, no yaw blow-up and no surge of κ clamping, and although the trajectories do change (so the mutations are live), nothing detectable changed (the friction circle and dissipativity are structurally guaranteed quantities and cannot break in principle). They therefore stay unasserted — measured, and recorded as out of reach. (5′) The v7.6.0 loose-surface sweep was widened once to 18 cells (3 corners × 2 angles × 3 car types, --full). The widening of the feasible region survives (drift runs that get round without breaking 74→754; cells with a solution 6/18→9/18), but the aggregate sign of “more deep-slip solutions” depends on the sweep (it falls 28→18 over the default 6 cells and rises 58→234 over 18 cells) — so expectation ② that v7.6.0 called “does not hold in aggregate” is grid-dependent just like ① (§13.15 of the physics notes corrected). (6) The “38 assertions” in the v7.6.0 changelog was a miscount (measured 39) and is corrected. (7) A design flaw in the standing gate wf_ap19_noise.mjs (sensor outlier rate) that made it go red about 5% of the time is fixed: the reference “true” reading was taken once with outlier injection still enabled and before seeding the random generator, so whenever that one reading happened to be an outlier, all 50,000 subsequent readings counted as “different” (observed during this audit in 1 of 4 full-suite runs and 1 of 12 standalone repeats). The reference is now read with outliers set to 0; after the fix it passed 20 consecutive runs. The product code under test is unchanged.
Verifying this release yourself
cd Simulator
node wf_run_all.mjs # the full assertion-gate suiteThe suite runs from a fresh clone with no dependencies beyond Node.js.
The real-browser checks under Simulator/browser/ additionally need npm install and a display.