The online racing simulator
Annoying behavior, not really a bug but could be done better
(17 posts, started , go to first unread)
Annoying behavior, not really a bug but could be done better
When switching from 3D (VR) View to 2D, it keeps an axis view and as the headset is not working, the axis is not center resulting as a 45degrees (more or less, might be fov/2) view on one side, it feels like having one monitor of a twin monitor setup.
I know the issue so I can correct it pretty fast, but people than dont know they have to remove the look axis will go mad.
Hi, thanks for the report. I've heard from someone about a view that was looking one way, and saw it in a video the other day, but can't remember any other cases. I don't know if they are related to each other, or related to your report in some way.

But I can't understand the problem yet.

Is it related to "Options - View - Look function" ? By default that is set to "joystick" but then "Joystick Look X/Y" must be assigned in Axes/FF.

Or it could be that Look function is set to "axis" but in that case, "Look Heading/Pitch/Roll" must be assigned in Axes/FF.

I've never seen the view stuck in one direction after leaving 3D VR view, so maybe it's something to do with your Look function or assigned axes. Can you tell me these settings? And what is it that you do to correct the problem when it happens?
What I can't explain or reproduce:

At this point in the video, Jimmy's view is looking left.

Soon after, he appears to have corrected the view.
BUT when we see his option screen, he has actually rotated the view 45 degrees right!
The problem is not really solved, he's just added 45 degrees to cancel out the issue.

So what is making the view look left? It can't be the ordinary look keys or buttons being pressed - they override the view rotation (not add to it). And it can't be the 'joystick look' as it is too unlikely to be exactly 45 degrees.
Ok I will answer on the second one first. Well it looks like he is suffering this exact same issue. For some unknown reason he has view on a not used axis which is set at 0 or max. The good way to solve this issue is to remove the view axis assignment. It is the good way but it is not an easy thing to even think about. My first idea at troubleshooting this was oh shit it is acting as if I had a two monitor setup. Wrong. Then I did like him and turned the view 45 which is OK in some situation. Some view will be turned anyway. May be a workaround would be to detect this behavior and propose a solution: if view axis is set and fixed value at 0 or max then disable it or propose to disable to the user.
It might happen to people who have a VR setup or maybe who had a VR at some point. Because when switching to VR lfs automatically assign axis view form axis VR. When VR is unplugged or removed or not used the controller configuration change and the axis are randomly assigned to what s left causing this issue.

To answer the first one.
I play 99% VR now but I can do some test later this week. It is linked to changing configuration VR wise and controller wise. I try to keep separate configuration to avoid issue. For lfs I usually have 3 controllers plugged (wheels buttons pedals) plus VR. I also have a setup for flight sims and for other games I use one or two Xbox controller.

Edit: It is look heading that get assigned.
Well I did the following.
Lfs used yesterday with 3 controllers in VR.
Today, freshly booted pc.
Turn LFS on with 2 controllers Simucube (diy) wheel off. (steamVR goes auto on)
Switch to 2D mode. Control axis are clean (heading, roll, pitch: -,-,-) nothing in the view axis. Side note I didnot close steam VR, stand by mode.
Close LFS
Turn on Simucube.
Run LFS and look at the screenshot, it is all messed up.
Attached images
When I remove simucube the configuration is then clean, but I prefer to play with my steering wheel!
Attached images
Well I manually removed these axis, and now I cannot trigger the behavior anymore. Tried simucube on off, 2D/3D/2D Remove steamVR standby, keeps being clean. But anyway but the view is twisted it is hard to figure out that reason first.

Edit: looks like same issue here:
Attached images
OK, thank you for these tests.

Now I understand what is happening. You and Jimmy both have a Simucube as the first controller in the list.

And there is something we might call a 'bug' in the Simucube drivers.
The device type is reported as DI8DEVTYPE_1STPERSON - LFS displays 'First person controller'.
I would expect them to report DI8DEVTYPE_DRIVING - LFS would display 'Steering wheel'.
Maybe they have a good reason for that, but it's confusing the LFS code.

In this case, LFS assumes that the first person controller is something like a gamepad so it sets up as if it is a gamepad, and that is why the Look Heading and Pitch are assigned.

I'm not quite sure what would be a good solution. I have an XBox controller here and it also reports as DI8DEVTYPE_1STPERSON so that's why LFS sets up that controller type like a gamepad. It's nice to automatically assign the right joystick to view control.

Anyway, at least we know the reason now. Thanks! Smile
Well the simucube is one ffb wheel plus a bunch of axis (1+5) and buttons (32).
The idea is to have everything setup with only one controller. I personnaly only use it for the ffb wheel even though everything else is DIY too.
I don't know if you could add some line of code specific for simucube... But yeah it is not perfect. I can try to ask Granite Device if you want...

Maybe you could run the test for DI8DEVTYPE_1STPERSON but only auto assign looking axis if they seem to be centered. GamepAd would be fine this way and simucube like controller would be discarded as gamepad...
Hey, well, I have only VR on the rig so even my Simucube is also, the first device and like Scawen said, fasly reported as 1stperson type, I dont have this bug, as the VR headset control the camera.
We should ask granite device to fix that, should be just 1 flag to fix somewhere. when the device is registering to windows
OK, I've submitted a support ticket at Granite Devices. Maybe they can change the reported device type, unless it needs to be this way for a good reason.
Ok it might be better but it might not solve the problem for other complex controllers, joystick (a friend reported me the same isssue on plugging Virpil joystick and pedals...)...
Thanks for that report. I was thinking that too. I did get a reply from Granite. The trouble is they are using the default Microsoft driver and it's not obvious how to set the controller type. They don't want to develop and maintain their own driver, as the default one works well. They aren't sure yet but may be able to make it report as a wheel.

But, as you point out, this may be more of a common problem. I am starting to think now that view axes (Look heading etc) should not be automatically set at all, except in specific cases e.g. the device name is "Controller (XBox One for Windows)" or whatever exact text describes other gamepads (I'll need to ask the community).
Yeah a whitelist approach would make sense.
FYI I have the same issue with a different steering wheel (VRS DirectForce Pro + Ascher wheel rim)
Thanks, I've disabled the automatic assignment of Look Heading and Look Pitch.

That's the most important step. At some point I might add some code to allow the automatic assignment for known game controller names. I'd like the view controls to be assigned but it's low priority at the moment.

List of known game controller names so far:
- Controller (XBox One for Windows)

Just for info, I have the following controllers in my MISC folder (I had some controllers from 2006...) directory that are gamepads:

Priority 0 ;-)

Annoying behavior, not really a bug but could be done better
(17 posts, started )