I also think that having a fixed setup is a pretty bad idea. Different controllers require different setups and after all, every driver has different preferences when it comes to how a car should handle and feel. Those do not necessarily mean that car is faster or slower.
What mod creators can do for example is to limit the number of available values for setting a particular car setup item. It's nothing new and it has been mentioned before. The first example is gear ratios, instead of a continuously variable gear ratio for each gear, one could limit it to 5-6. The same goes for differential, suspension - spring stiffness, ride height, shock settings, and so on. Some parameters like tire pressure or steering can stay the way they are.
The hard part is agreeing on what needs to be limited and by how much, for every car. Given the number of mods, good luck with that
edit. there is no way to force fixed setups with airio, one can only force certain tires, and input help like auto clutch, auto gears, cockpit view, and so on.
What mod creators can do for example is to limit the number of available values for setting a particular car setup item. It's nothing new and it has been mentioned before. The first example is gear ratios, instead of a continuously variable gear ratio for each gear, one could limit it to 5-6. The same goes for differential, suspension - spring stiffness, ride height, shock settings, and so on. Some parameters like tire pressure or steering can stay the way they are.
The hard part is agreeing on what needs to be limited and by how much, for every car. Given the number of mods, good luck with that
edit. there is no way to force fixed setups with airio, one can only force certain tires, and input help like auto clutch, auto gears, cockpit view, and so on.
Place the patch inside the existing LFS folder and run it as an administrator. And by the way if you didn't know, the latest official LFS version is 0.7C.
Hi Scawen, I've tested the new patch and the changes with ffb are perfect. LFS is reporting AxisEnable byte as 0x04 (direction enable) and the direction is fixed at 90deg, while magnitude has both positive and negative signs for the constant force effect - resulting in a correct FFB for 2 axis FFB devices.
All good, tnx man.
All good, tnx man.
Perfect, that will do, tnx very much man. I'll report my findings in the thread for test patch, however I'm quite sure that we can close this topic as it's been solved.
Dear Scawen, thank you very much for taking the time to understand this issue, I appreciate it very much. For more details, I have attached a reference document from Microsoft that deals with PID part of HID descriptor which is implemented on the device side (FFB wheel), but the application has also to follow this protocol.
To save you some trouble, you can have a quick look through pages 6-10 and page 44.
Looking at your code, I can see that your struct DIEFFECT eff; is missing some parameters. Have a look at page 35 for "Set effect output report". There is no need to implement all of them, but byte 9 is the AxisEnable byte. The interesting thing is that LFS does send this byte correctly and sets it for 2 FFB axis devices at 0x04 (bit2 = 1 -> direction enable) and also for 1 FFB axis devices to 0x01 (bit0 = 1 -> X axis enable).
In principle fast fix is simply:
cf.lMagnitude = abs(nXForce); -> cf.lMagnitude = nXForce;
If you have any questions about this please ask, I spent the last 4 years of my life reading through this stuff while developing firmware for Arduino FFB wheel.
To save you some trouble, you can have a quick look through pages 6-10 and page 44.
Looking at your code, I can see that your struct DIEFFECT eff; is missing some parameters. Have a look at page 35 for "Set effect output report". There is no need to implement all of them, but byte 9 is the AxisEnable byte. The interesting thing is that LFS does send this byte correctly and sets it for 2 FFB axis devices at 0x04 (bit2 = 1 -> direction enable) and also for 1 FFB axis devices to 0x01 (bit0 = 1 -> X axis enable).
In principle fast fix is simply:
cf.lMagnitude = abs(nXForce); -> cf.lMagnitude = nXForce;
If you have any questions about this please ask, I spent the last 4 years of my life reading through this stuff while developing firmware for Arduino FFB wheel.
Last edited by rane_nbg, .
Hi guys, I just wanted to bump this thread since I found what was the cause of this problem and was able to fix it by adding one line of code in my Arduino FFB wheel firmware. However, the problem is in how LFS handles the FFB protocol and there is one small issue there.
The problem only occurs on FFB devices that report 2 or more FFB axis via HID descriptor. A constant force effect (the only FFB effect that LFS is using) is always sent to the wheel as 2 parameters. One is the magnitude of the force and another is the direction. I have checked, LFS does correctly send one more piece of information when doing the Set Effect Report and that is the axisEnable byte. The 3rd bit of this byte (value of 0x04) is representing direction enable information, which tells the FFB device to also include direction value in force calculation. If this is not implemented in the device firmware, then calculated constant force will only have positive values because the magnitude is always positive and direction value which is a force sign in this case is neglected. As a result, you get one-sided FFB on your wheel. A device is allways reporting the logical and physical ranges for each parameter of FFB effect. If a device reports the magnitude for CF effect to have range of -10000 to 10000, then a game should use it always in the full range, regardless of how many FFB axis are reported. Some recently apeared FFB wheel manufacturers, even if this is a 1 FFB axis device, just copy pasted the HID descriptor for Microsoft Sidewider Joystick which has 2 FFB axis, and forgot to implement the direction into calculation. In principle LFS does send all required information and that is why I was able to adapt my fimrware for it, but I doubt that any new manufacturers in the direct drive FFB wheel market will do this.
I propose the following solution that Scawen has to implement in LFS's FFB protocol if he wants to expand the support for practically all DirectInput devices including most of the commercial FFB wheels and FFB joysticks.
Solution - when you do the Set Effect Report for constant force effect, send both positive and negative magnitudes for this effect (use a full range that the device reported) and change the axisEnable byte to 0x01, to indicate usage of only the X-FFB axis to the device.
for reference, I provide a piece of my code for the FFB protocol (that follows the DirectInput documentation from Microsoft), where one can see all the parameters that an application has to communicate with the FFB device when setting up any FFB effect.
The problem only occurs on FFB devices that report 2 or more FFB axis via HID descriptor. A constant force effect (the only FFB effect that LFS is using) is always sent to the wheel as 2 parameters. One is the magnitude of the force and another is the direction. I have checked, LFS does correctly send one more piece of information when doing the Set Effect Report and that is the axisEnable byte. The 3rd bit of this byte (value of 0x04) is representing direction enable information, which tells the FFB device to also include direction value in force calculation. If this is not implemented in the device firmware, then calculated constant force will only have positive values because the magnitude is always positive and direction value which is a force sign in this case is neglected. As a result, you get one-sided FFB on your wheel. A device is allways reporting the logical and physical ranges for each parameter of FFB effect. If a device reports the magnitude for CF effect to have range of -10000 to 10000, then a game should use it always in the full range, regardless of how many FFB axis are reported. Some recently apeared FFB wheel manufacturers, even if this is a 1 FFB axis device, just copy pasted the HID descriptor for Microsoft Sidewider Joystick which has 2 FFB axis, and forgot to implement the direction into calculation. In principle LFS does send all required information and that is why I was able to adapt my fimrware for it, but I doubt that any new manufacturers in the direct drive FFB wheel market will do this.
I propose the following solution that Scawen has to implement in LFS's FFB protocol if he wants to expand the support for practically all DirectInput devices including most of the commercial FFB wheels and FFB joysticks.
Solution - when you do the Set Effect Report for constant force effect, send both positive and negative magnitudes for this effect (use a full range that the device reported) and change the axisEnable byte to 0x01, to indicate usage of only the X-FFB axis to the device.
for reference, I provide a piece of my code for the FFB protocol (that follows the DirectInput documentation from Microsoft), where one can see all the parameters that an application has to communicate with the FFB device when setting up any FFB effect.
Last edited by rane_nbg, .
You should also max out FFB steps and frequency for the highest FFB fidelity.
Hi guys, there is not much that you can do, but there are some basic stuff that you must setup. Those are wheel turn set to 900 both in logi driver and lfs, wheel turn compensation to 1.0. That way lfs will automatically adjust deg of rotation to 1:1 for each car and the steering will be fully linear.
FFB strength should be up to (18-26)% for GTi cars and up to about (8-18)% for the rest, to avoid clipping and loss of details.
FFB strength should be up to (18-26)% for GTi cars and up to about (8-18)% for the rest, to avoid clipping and loss of details.
Do not use steer smooth, just reduce the max lock in car setup and use linear steering by setting the wheel turn compensation to 0.
Hi Scawen,
You are completely right, the real situation is most probably some linear combination of all 3 points that you mentioned.
One thing that comes to my mind is the option to be reminded about the event via email if one subscribes to it, just like when we receive an email that there is a reply in one of the forum threads or posts that we posted in. Some info about the even somewhere in the multiplayer server list is also good idea.
Visibility of events on the forum here and in lfs discord is enough. One can not force people to join, who is interested in such events will find it easily.
You are completely right, the real situation is most probably some linear combination of all 3 points that you mentioned.
One thing that comes to my mind is the option to be reminded about the event via email if one subscribes to it, just like when we receive an email that there is a reply in one of the forum threads or posts that we posted in. Some info about the even somewhere in the multiplayer server list is also good idea.
Visibility of events on the forum here and in lfs discord is enough. One can not force people to join, who is interested in such events will find it easily.
Last edited by rane_nbg, .
Eh, nothing lasts forever.
Sorry man, I got nothing. It may really be an LFS bug indeed
what is your button debounce value?
Cool mod, nice work there man. I'm really not a fan of those 3 pointy lines along with the hood, but the rest seems good.
Awesome mod, very nice
Ok, what is your button debounce value? In windows mouse settings there is an option to set how many lines one notch in mouse scroll wheel will do, by default it's 3, you can try 1 there.
Hi Scawen, thx very much for this update. I'm especially grateful for what you did with the FFB strength adjustment. Increments of +-1 by keys are more than welcome and capping it to 100% is pro.
If anyone wonders if the scaling of FFB strength is changed - the answer is no. You can keep your old FFB strength %, it is just that the max value is being capped to 100. Note that most cars will clip the FFB at 20% or sooner, so be careful with it and optimize for your driving style and car/track combo.
edit: For example, for normal smooth driving XFG+BL1 you can use up to 34% FFB strength with no clipping (if you hit wall or sausage curb it will clip)
The attached figures are showing an FFB real-time monitor that I made in GUI for my FFB wheel firmware for Arduino. It is simply passing the FFB value that the LFS is sending.
If anyone wonders if the scaling of FFB strength is changed - the answer is no. You can keep your old FFB strength %, it is just that the max value is being capped to 100. Note that most cars will clip the FFB at 20% or sooner, so be careful with it and optimize for your driving style and car/track combo.
edit: For example, for normal smooth driving XFG+BL1 you can use up to 34% FFB strength with no clipping (if you hit wall or sausage curb it will clip)
The attached figures are showing an FFB real-time monitor that I made in GUI for my FFB wheel firmware for Arduino. It is simply passing the FFB value that the LFS is sending.
Last edited by rane_nbg, .
Are you using a manual or auto clutch?
Nice drive man
Mods being bad for LFS is absolutely a ridiculous claim. It allowed devs to get some more income which motivates them to continue improving the game. May I remind you that server hosts has the ability to restrict mods usage. With that being said, why don't you start paying and renting an LFS server where you will invest time and money to organize something that you and others will like.
Restricting mods is destroying user creativity and I'm happy that people make all kinds of very good mods. The devs gave us a great tool. How we use it, it's entirely on us.
For now, the biggest problem is to update AIRIO such that it fully supports moded cars. We managed to do some workarounds and make it work partially, but without access to source code, it's a dead-end, unfortunately. On the other hand, there are already some promising alternatives and with some time I'm sure that there will be something usable.
Restricting mods is destroying user creativity and I'm happy that people make all kinds of very good mods. The devs gave us a great tool. How we use it, it's entirely on us.
For now, the biggest problem is to update AIRIO such that it fully supports moded cars. We managed to do some workarounds and make it work partially, but without access to source code, it's a dead-end, unfortunately. On the other hand, there are already some promising alternatives and with some time I'm sure that there will be something usable.
Last edited by rane_nbg, .
Looking good, almost there, only a few thousands more tris
Cool mod. What is wrong with the driver? his head movement does not look healthy at all
Check out our AirAttack servers in the evening European times for everyday casual racing, or Fragmasters at Thursday and Friday. There are also some MRc events during weekends and Rony's Tuesday races. So, plenty of activity.
Last edited by rane_nbg, .
FGED GREDG RDFGDR GSFDG