Repository navigation
Cab wheel rotation: the steering wheel in the cab turns as far as the player's own - #3327
Conversation
… player's own A new setting, "Cab wheel rotation" (settings.cfg `cab_wheel_rotation`, degrees lock to lock, 180-1800 in steps of 30; 0 = the bus's own animation, the default), in the launcher's Settings > Driving > Game controllers, on the Controllers page and in the game's Options. A 900 or 1080 degree wheel on the desk and the one in the cab then reach their locks together, where the cab's wheel turned several times over (a stock SD202's 2171 degrees lock to lock: its model's factor of 1680 over a 37 degree lock). The player's bus's steering-wheel animations (`anim_rot` on `Axle_Steering_*` with a factor of 300 or more: the stock SD200's 1450, the SD202's 1680) are scaled once at vehicle load so that their lock-to-lock rotation, taken from the bus's full steering lock, equals the setting; the hub's buttons scale with the rim, the road wheels are left alone, and the driver's hands follow the scaled factor. A bus that turns its wheel from a script variable of its own keeps its own rotation, which the log says. AI and other players' buses are not touched. Tests: the scale, the animation detection, a synthetic bus (rim and button scale, road wheel stays, repeated calls do not compound, 0 restores), model reload keeps the setting, the settings default and clamp table, and the launcher round-trip.
There was a problem hiding this comment.
Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.
An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing.
Test builds for 94d9832
|
|
Thanks! #3329 just landed and touches the same files (CHANGELOG.md, locales/app.yml, USER_GUIDE.md, the launcher's controllers.js and settings-schema.js), so this one now conflicts with main. Could you merge main into the branch and resolve it? CI was green before, so it can go in right after. |
isaacsa2
left a comment
isaacsa2
left a comment
There was a problem hiding this comment.
Reviewed 94d9832. Automatic (cab_wheel_rotation=0) is the default and restores the model's original factors; choosing a degree value enables the override. The tests cover restoring zero, repeated changes without compounding, road wheels staying untouched and model reload. The opt-out requirement is met. Apple / build is still running, so approval remains pending until that check completes. I reviewed the code and supplied evidence; I have not tested a physical wheel or VR locally.
turbo-devv
left a comment
turbo-devv
left a comment
There was a problem hiding this comment.
Conflicts with main resolved (controllers.js: kept the FeedbackCard layout, added the cab_wheel_rotation row); CI green.
What changes for the player?
The steering wheel in the cab can now turn as far as your own wheel: set Cab wheel rotation (launcher: Settings › Driving › Game controllers, also under Controls › Game controllers › For every wheel; in the game: Options › Controls) to your wheel's rotation, e.g. 900° or 1080°, and the wheel on screen follows your hands turn for turn. The default, Automatic, keeps every bus exactly as it was.
How to test
~/.openomsi/settings.cfgholdscab_wheel_rotation=900(or the value set),0for Automatic; Reset wheel settings puts it back to Automatic. The log says which animation was scaled:cab wheel rotation: mesh 74 D92\D92_lenkrad_hupe.o3d anim 0 (Axle_Steering_0_L x 1680), axle lock 37.0°: 2171° lock to lock in the model, 1080° now (2 animation(s) scaled x0.498).Screenshots
Automatic (the bus's own animation) against 1080°, stock MAN SD202 standing on Grundorf, the steering taken centre → full left → full right → centre in 12 s (an offscreen run with a scripted steering profile, the same frames on both sides):
The setting in the launcher (Settings › Driving › Game controllers) and in the game's Options › Controls:
What does this change, and why?
OMSI buses animate the cab's steering wheel with
anim_rotonAxle_Steering_*using a factor of their own (1450 on the SD200 family, 1680 on the SD202/Agora/Urbino families, 972-1575 on others), which over the bus's steering lock comes to several turns, far more than a real wheel's 900-1080°, so a player with a wheel sees the wheel in the cab turn differently from the one in their hands (and the driver's hands with it). The new settingcab_wheel_rotation(degrees lock to lock; 0 = the bus's own animation, the default; otherwise 180-1800 in steps of 30) makes the cab's wheel model turn that many degrees over the bus's full steering range.crates/omsi-sim/src/vehicle/cab_wheel.rs): when the player's bus is set up, itsanim_rotanimations onAxle_Steering_*with |factor| ≥ 300 are taken as the steering wheel (the hub's buttons share the factor; road wheels use 57.3 and are left alone); their lock-to-lock rotation is factor × 2 × the bus's full steering lock (physics.max_steer_deg), and the factors are scaled once so that it equals the setting. The model's own factors are always the starting point, so repeated calls never compound and 0 restores them. The driver's hands (omsi-scenedriver rig) read the live factor, so they stay on the rim. AI and other players' buses are not touched. The log says what was scaled, or that no wheel animation was found.omsi-launcher-core(default 0; read as 0 for anything under 90, 180 for 90-180, else rounded and capped at 1800; written tosettings.cfg, with a round-trip test). Reset wheel settings resets it as well.cab_wheel_rotationinsettings.rswith the same clamp rule, the Options row next to Wheel rotation / Full lock at, applied to the player's bus at once.app.yml.CHANGELOG.mdanddocs/USER_GUIDE.mddescribe the setting.What could break?
Lenkwinkelfrom a lookup curve) keep their own rotation: the setting cannot reach them, and the log says no wheel animation was found. Reports of a bus whose wheel looks wrong with the setting on are welcome.physics.max_steer_deg(clamped 10-60°); a bus whose real lock falls outside that is slightly off.Performance
No per-frame cost: the animation factors are computed once at vehicle load (and on a devtools model reload). Measured with
OMSI_PROFILE=1 OMSI_PROFILE_JSON=<file> --exit-after 120on the same duty (Saint-Servan, Agora AL4 I line 21, the bus in service from the start), the branch built on the release's own commit (c7b54b9), two pairs of runs; the table is the second pair, the first pair gave 97.6 / 104.5 fps and p99 15.8 / 14.1 ms the other way round, so the differences are run-to-run noise.scripts/compare-performance.py: p50 9.9 → 9.9 ms, p95 13.2 → 13.4 ms, no stage of the frame changed beyond noise.Machine, map and settings: RTX 5070 12 GB, Windows 11 (NVIDIA 32.0.16.2101), Saint-Servan, Agora AL4 I line 21, Enhanced+, 4x MSAA, 1920x1080, the player's own settings (vsync on, max fps 144). The memory is the process's working set / private bytes at the end of the 120 s; the second run had driven further (8106 vs 7287 measured frames), which is where the 400 MB difference comes from.
Checklist
cargo test --workspaceandcargo build --releasepass (omsi-sim 845, omsi-scene 206, omsi-launcher-core 107 and omsi-app settings 63 tests, plus the release build, on Windows;scripts/size-budget.shandscripts/arch-guard.shpass)crates/omsi-app/locales/app.yml, in every language I can