Categories
News

RumiCar Simulator v8.7.0 released

We have released RumiCar Simulator v8.7.0. The release notes below are also available on GitHub.


v8.7.0

Three display and input defects fixed (Stage BD; the driving physics are unchanged). (1) Editing the walls of a saved course could leave the “can it drive?” notice stale — after saving a course, adding or removing walls in the editor and pressing ✔ Apply without renaming it made ▶ and 🏁 report the answer for the course before the edit. Measured: closing a corridor with a single wall still reported “it can start”, with no notice, while the actual run dropped from a maximum displacement of 7.370 car lengths to 0.789 car lengths (essentially stuck). The memo behind that answer is now keyed by the shape of the course itself rather than its name, so editing walls without renaming returns the correct answer. (2) The standings table overhung the left edge on narrow screens — below 360 px the frame had a fixed width, so text was cut off on the left (measured: 52/32/12 px of overhang at window widths of 280/300/320 px). When the available width falls short, the padding inside the frame and the gaps between columns are squeezed first, and only then are the glyphs and colour dots scaled down (text stops at 10 px). Overhang is now 0.00 px across all 24 samples of 280–1000 px x Japanese/English. Where there is room to spare the code takes exactly the path it took before, so the drawing does not change: measured across 68 courses at 390/1440/1920 px, the bounding boxes of all three instrument groups match the previous version, and so do the pixels except on elevation courses, whose 3D rendering varies from capture to capture. On extremely narrow screens the frame still overhangs: the squeeze has a floor — measured in Japanese, the frame will not go below 160.8 px — so once the course view drops under 172.8 px wide (roughly a 233 px window) the overhang returns. In English the labels are longer, so it returns on a slightly wider screen. At 280 px, the narrowest width the app ships for, about 43 px remain before that cliff. (3) On devices with both a mouse and a touchscreen, a finger tap hijacked the mouse gesture — tapping the screen while panning with the mouse (or dragging a car, or drawing a run of walls in the editor) threw the view or the car to the tapped point (measured at 390×844: the pan moved (-104.00, 76.00) instead of the uninterrupted (44.00, 33.00), the car (-336.38, -215.26) instead of (123.80, 80.16), and a run of 8 walls became 0). The app now recognises and discards only the “pretend mouse” events a tap emits underneath, so all three match the uninterrupted case (difference 0.00). Note: that recognition relies on the sourceCapabilities signal the browser reports. Where a browser does not report it, behaviour is unchanged — not fixed, but no worse. The same change also fixes a pre-existing defect where a stranded mouse gesture stopped touch drag and pan from working (taps still worked) — after releasing the button off-screen, interrupting with a right click, or switching to another window. That part works even in browsers without the signal above. The permanent verification gates went from 68 to 69, and the real-browser checks from 29 to 30.


Verifying this release yourself

git clone https://github.com/RumiCar-group/RumiCar-Simulator.git
cd RumiCar-Simulator
node wf_run_all.mjs        # the full assertion-gate suite

The suite runs from a fresh clone with no dependencies beyond Node.js.
The real-browser checks under browser/ additionally need npm install and a display.

How this site is built (v1.4.0)

Some components are open source:

Enjoyed the machinery? The main event is our autonomous-driving simulator — it runs in your browser.
Try the simulator → / GitHub →