The type of end stop (max wheel turn) can be adjusted on the Moza Pit House software by adjusting the slider from 0 Soft to 10 Hard. Make sure you are using the latest version of the Moza Pit House and your wheelbase etc is on the latest software.
What I have noticed is that sometimes an update doesn't mean all the functionality will work as expected, so be mindful when updating (and control the versions of the FW and SW to which it works without issues so you can revert to them if the update breaks something).
I'll post my Pit House settings and in-game settings, I noticed a difference that I have wheel turn compensation at 0, I am not sure why you would want it at 1. When I am playing with mouse I use 0.5 to make steering less sensitive near 0 degrees, but not sure why you would use it with a wheel.
When I set the wheel rotation manually in Moza Pit House software, it works perfectly as you describe. But I want LFS to automatically set the rotation for each car so I don't have to jump into MPH and adjust the rotation manually every time I change the car.
The wheel turn compensation set to 1.00 (max) makes sure the physical wheel turn always matches the in-car steering wheel, provided that the max is set to at the actual max angle or more.
Here's an exaplantion from Scawen. Point 1) applies in my case:
This worked well with my G27 - I could feel a bump stop when I reached the maximum lock angle of the given car.
For demonstration, here's a comparison of me turning the G27 wheel past its full lock and then the same with the MOZA R3. Pay attention to the FFB graph at the bottom right:
Thanks for the explanation, I have tried those settings, and it works as you described, each car has their own max steering lock (without going to MPHouse) and the car setup steering Max Locks works.
I have changed only to 1080 in MPHouse and LFS, and set wheel turn compensation to 1.
Okay, then something must be wrongly configured on my end and it's probably not a bug. Thanks, I will have another look. I have connected both my G27 and the Moza right now, maybe that could cause the issue?
I was looking at that and yes it raised an eyebrow....
Try disconnecting the pedals(which I am assuming is the G27) and have the wheel recognised as the only controller(wheel), then after confirming the end stops works, connect the pedals.
Somehow the wheel is being recognised as a first person controller...
I also noticed after some lfs update that I can't anymore feel endstop force generated by lfs on logi G29 wheel. Before that particulair update from a few years ago I could feel end stops in cars that had less rotation than 900deg (I used 1.0 wheel turn compensation).
However, on thrustmaster t300 I have the endstops. On my custom arduino firmware for ffb wheel, I also don't have enstops, so I have no idea what's going on. In all cases I'm using 2 ffb controlers plugged in, one of the comertial wheels + my arduino wheel firmware that I use only for load cell brake pedal. On its own, only t300 has working endstop from lfs, in its driver I have it set to 1080deg and lfs does the rest as it should.
edit.For ffb neard eyes only - the problem seems to be related in how lfs creates the endstop force. Some wheel firmware like the one in t300 which just use direct input API for ffb actualy have a few ffb effects alocated for this purpose called axis barrier and angle barrier. I have no way of telling if lfs utilizes those or just uses constant force effect to create the ilussion of endstop. In my custom arduino firmware, I can clearly observe that lfs send only constant force ffb effect. But there is nothing being sent at the moment where a full lock of particulair car is reached, this is before the wheel's actual lock (where it applies its internal endstop). If we could get more details from lfs devs about this matter, I could then test it in details and report the findings which may lead to some solution. Just like we did for issue where lfs would only send one sided ffb in some new wheels.
MOZA also just uses direct input API. If you can have a look at wheelcheck or DI view and expand the part which describe the ffb features, see what they have defined in HID descriptor. Would be interesting to see which ffb effects they have implemented. I'll show the examples of t300 and my arduino firmware soon.
The 'bug' is in the game controller driver software which is reporting DI8DEVTYPE_1STPERSON instead of DI8DEVTYPE_DRIVING.
LFS only implements self-centering when it is a wheel. There are two types of force that are only applied if it is a wheel.
1) After car is reset, the force slowly builds to try to centre the wheel.
2) Wheel out of bounds (end bump stops)
I believe I have done this as a safety measure or to stop LFS smashing up FF devices / children / etc. I don't really know what a DI8DEVTYPE_1STPERSON is but suppose it's a joystick, then applying a large force could fling the joystick right over the other side, when it could then receive the opposite force that flings it the other way, and you can end up with a wild flailing joystick.
I have to be a bit careful with FF devices and decided that these forces should be OK if the controller is a wheel. Of course we have a problem if the wheel manufacturers can't specify the correct device type.
Now I've got a vague memory of some direct drive wheels being reported as DI8DEVTYPE_GAMEPAD - not sure if I'm remembering correctly but I guess that will cause the same problem.
EDIT: Actually it was the Simucube, which was also reported as a 1st person controller. I got this as part of a reply when I contacted them in 2021:
EDIT2: I find it a bit frustrating that DEVTYPE is not a reliable way to recognise the type of device, despite the name, and that manufacturers basically aren't bothered about that. At the moment it looks like we will have to have some kind of override option:
FF device is actually a wheel although it is not reported as one: YES / NO
I wonder if you can think of a good way to add this to the interface, clearly, without taking up too much space, and such that users are unlikely to select it if they don't have a wheel.
Tnx for this info Scawen, it is very useful as it reveals the specific lfs requirement for HID descriptor of an ffb device. Manufacturers use various values for USAGE, it can be wheel, joystick or gamepad, sometimes also first person controller. I will play with my firmware and see if it makes a difference if I change the usage in HID descriptor.
In my oppinion, endstop forces are not dangerous, because this is in essence a spring force. It's intensity depends on axis position, so the user can simply stop pushing against "spring" when ever he wants and it will not fight back. The dangeous forces are the actual ffb signals, where you for example smash the car into a wall which creates a huge peak in ffb one can't do anything about, as it's often quite unexpected.
About end stop forces, I think you sort of missed my point. I'm not saying that end stop forces are dangerous for wheels, but specifically that they could cause undesirable effects for joysticks, because of the way joysticks can flick so fast from one side to the other. That's why I enabled them for wheels but not joysticks.
But you touched on a more important point about impact forces in conjunction with direct drives, though that is a different subject.
Anyway, I've thought of a possible interface, to allow the user to override the reported device type, see attachment.
Yes, let's not go off-topic now with FFB peak forces. Filtering, limiting, and compression can be done but let's leave that for some other time.
I understand well your rationale behind the decision to disable endstop forces other than wheel controllers. My point was that endstop force is not one that can cause the joystick or whatever to oscillate from side to side - actually, the ones that do are autocenter spring force or damper for example. Anyway, I respect your decision if you want to keep it that way.
Thank you for tackling the issue. What exactly will this selection of controller type do? I mean, a simple controller-type override button is enough. By default, you can leave it inactivated and the user can choose to enable it in order to get end-stop forces working.
Joystick is past right stop.
Receives strong left force.
Accelerates left for a while.
No longer past right point, but still has velocity.
In split second, exceeds left end stop.
Receives strong right force.
Accelerates right until no longer past left bump stop.
In split second, exceeds right end stop.
etc...
The problem is that to provide a strong enough force to be felt, the acceleration is quite fast, if you are not holding the joystick. And a joystick can move to extremes so fast that there is no time for the game to react before it's already off the other side.
If you have tried making a joystick move to specific locations, you may have experienced the same trouble I have, with wild oscillations being the usual result. Personally, I have not been motivated to try to solve such an issue. The simple method (plain force, available on all FF devices) worked well for a wheel so I simply limited it to a wheel.
But this is really off topic, I'm not going to start trying to control the motion of FF joysticks of unknown mass, force capabilities, etc.
I know it should be plug'n play but as way to debug quickly, uninstall all drivers and software from both wheels, plug only MOZA, install all drivers and software. I am assuming some kind of conflict, and by changing the installation order one might strike gold.
Make sure under Device Manager with View->Show hidden devices, after uninstalling both software products, no drivers (from Moza or Logitech) show up under Human Interface Devices.
I've used USBTreeView to see if the descriptor for WHEEL CONTROLLER was there, but only found generic (hexadecimal) information about the R5 Base...
Yes, those generic HEX values are what you need. There is an HID descriptor tool that can decipher easily their meaning because this is part of the DirectX standard. You can get it from here: https://usb.org/document-library/hid-descriptor-tool
You first select USAGE_PAGE (generic desktop or simulation controls), then under USAGE, you will see available types and properties like axis and so on. Once selected it will show the HEX representation and you may find if anything matches with the values you got from USBTreeView.
This is in the case where one intentionally pulls the joystick all the way until the mechanical stop, where the end-stop force is maxed out. Obviously, letting go of the stick in such a situation will not end well. But you are right, it should be kid-safe.
The ability to manually override the controller type in lfs is all we need. A simple override button + a short description of what it does is enough. We don't need an entire selection of all other types, we just need the one that makes the end-stop forces work, therefore one button instead of a drop-down menu list. For example, your auto button is renamed to override, once pressed the type will be set to wheel. Unpressed will show the original device value from the HID descriptor.
edit. the quote from SIMUCUBE is exactly what I'm thinking. I'm using such DIY project to create a wheel and having it defined by simulation controls is very limiting, because then many wheel features would not be available. Those are for example D-pad hat switch, X, Y, Z axis and so on.
Here it clearly says generic desktop and joystick. This is exactly the same as how I have it my firmware, but lfs reports is as joystick. I'm not sure why your wheel is seen in lfs as first person controler.
Anyway, that's not gonna be relevant anymore once we get the override button.
I hope to release a test patch this afternoon. In the development version I've been fixing various issues to get to the release and one thing was about Z buffers, according to a recent recommendation by Bokujishin which took me into the projection matrix. I had been doing other VR fixes recently, including something about lighting exposure, which I have recently updated for the regular monitor version too. I'll probably do a report about some of the updates, but haven't been in a mind to slow down.
Now with VR and projection matrix in my mind, I was reminded of a bug report by vRenegade and I've been looking at that.
So hopefully this afternoon I can release a VR fix and an option for user to override the controller device type.
Scawen, maybe you shouldn't examine controller type for FF stops. Just base in on wheel rotation angle set by the user. If it is set over... 120 degrees it should be treated as a wheel.
