Multiply the amount of money by about 100x and you'll maybe get someone to do it. What you are asking takes a lot of time to program.
No need to do anything special with controller settings, just reduce the max lock under steering tab in car setup in the garage and you are good to go. Set wheel turn compensation in options/controls to 0.
For XFG in BL1 you can use as little as 12deg max lock (30 is the default), but you can find something small enough to give you precision and at the same time big enough that you can still do tight turns or exit pit.
For XFG in BL1 you can use as little as 12deg max lock (30 is the default), but you can find something small enough to give you precision and at the same time big enough that you can still do tight turns or exit pit.
Last edited by rane_nbg, .
Nice, keep it up dude.
Hi, I'm using the same wheel in the latest version of LFS 0.7D with no issues whatsoever.
First of all, download the latest windows drivers for your wheel, then update the wheel firmware, latest is v34. You may only set 1080deg in driver and set overall force to 100%, the rest is fine. Second, you should configure LFS like this:
First of all, download the latest windows drivers for your wheel, then update the wheel firmware, latest is v34. You may only set 1080deg in driver and set overall force to 100%, the rest is fine. Second, you should configure LFS like this:
Last edited by rane_nbg, .
Ah, I lived through those 1992-1995, it was a mess. I was just a kid at the time, but remember that I had to stand in line for a few hours in front of a supermarket just to buy 1 bread and 1L of sunflower oil, which together cost an entire 1month salary of my dad at the time. By the end of 1994, the inflation was so high that we had paper bills with 12 zeros on them. Good old sanction days 
Last edited by rane_nbg, .
Yeah, they also sent us an invoice. I then canceled our services, it took one day to pass. Funny, we still have access to their control panel and we could still run the servers, but we are not doing it. We have already changed to a new host for airio, so far so good. This only goes to show how much RS care about hosting stuff for LFS.
Let's say hypothetically, that I could be able to help. How would you send me back the money? Or is this more of "buy me a license please" type of request?
Or is this more of "buy me a license please" type of request?only 1380hp, are you sure this is enough?
+1, wise words man
Which mod did you try? I'll try to recreate the issue.
AI will start with as much fuel as needed for the number of laps that you set. No less, no more.
Hi guys,
Thank you very much for all your suggestions. We'll probably cash out for some of the VPS options for about 5eur/month.
Number, I do not think that would work so easily. Each airio instance has its own configuration files and we all setup them differently. That is not a problem, but not a small amount of space is needed for airio backups and replays.
Thank you very much for all your suggestions. We'll probably cash out for some of the VPS options for about 5eur/month.
Number, I do not think that would work so easily. Each airio instance has its own configuration files and we all setup them differently. That is not a problem, but not a small amount of space is needed for airio backups and replays.
Tnx for the suggestion man, but that is not an option for us, because no one has a static IP address and we need a system where a few people would be able to connect remotely and do some changes/uploads in airio files.
We already did something like that using a TeamViewer with one of our members and his personal PC, but it just was not viable for the longrun.
We already did something like that using a TeamViewer with one of our members and his personal PC, but it just was not viable for the longrun.
Hi man, tnx for reply.
I asked them if it's possible to only rent one demo LFS server in order to host airio and they replied that they will stop the service for LFS completely, as soon as our current rent expires. For us that is in a few days, 25th April. I think that it doesn't pay off for them anymore and therefore they are droping the LFS support.
Tnx for suggestions, I'll check them out.
I asked them if it's possible to only rent one demo LFS server in order to host airio and they replied that they will stop the service for LFS completely, as soon as our current rent expires. For us that is in a few days, 25th April. I think that it doesn't pay off for them anymore and therefore they are droping the LFS support.
Tnx for suggestions, I'll check them out.
He is asking how did you complete a lap if formula cars are not allowed on rally tracks. You should be a bit more specific when you are requesting something. Being a snob will not get you anywhere.
If you have set it to chinese, good luck
Finding reasonable alternative to RackService for inSim hosting
Hi guys, many of you probably face the same situation as we at AirAttack, where the previous server host provider RackService does not want to continue renting servers to be used to host inSim apps only.
My question is, have you found an alternative host for inSim with a reasonable price?
A question for developers, are there any plans for integrating this feature within your hosting options?
My question is, have you found an alternative host for inSim with a reasonable price?
A question for developers, are there any plans for integrating this feature within your hosting options?
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.
FGED GREDG RDFGDR GSFDG