Hi!

Got into LFS many many years ago (probably around 2006-2008), when I even was driving a bit using the mouse hehe. Then I got Logitech cheap wheel (with a spring, no FF), then Momo, then G25, and finally now I have Thrustmaster T300 coupled with G25 pedals. I also drive all sims in VR, with Quest 2.

I really struggle to find ANY info on FF settings, especially regarding FF Steps and FF Rate. I'm currently using 200/100, but I can only feel the wheel resistance, almost no effects like bumps, rumble shaking, etc etc, especially if I reduce FF to 20-30%. I can barely feel fumble strip FX when I bump up FF to 80%, but then I must fight with a wheel pretty hard. MAybe I tested it on wrong tracks, can't tell.
So, what are the best settings for T300, in both Thrustmaster app and in LFS? Any CFG file where I can fine tune FF effects?

Regarding VR, I'm quite familiar with 100hz LFS rate creating stuttering in VR (not matching FPS in the headset). I can see stuttering even on my monitor, vsync or not at 60hz. I limited the game FPS to 200fps to minimize the stuttering, it's almost as smooth as other sims with vsync.
In VR I tested 72hz and 120hz, both produced really bad micro stuttering, and my eyes can't stand that. Tonight I will test 90hz, as it's closest number to 100hz that LFS uses. Wish me luck. If not, I will use 2D exclusively, which is a shame.

My second question is for Scawen - when will LFS be updated to 1000hz? I'm seeing replies mentioning 1000hz in summer 2022. Any update on that is welcomed.

Thank you!

Congrats on the S3, it only took you a decade .

For the force feedback, I personally prefer it to be less than 30%. Anything above that and I believe it's not-competitive and playing the game becomes a workout.

Other settings: Do some trial & error and find what works for you and your gear!

Refresh rates: Go with the highest you can, for your headset, you've mentioned 120, I believe the higher the better. If you do experience fatigue then just swap back to your regular monitor, also if you have the cash you can consider a 144 or 165hz display, they're inexpensive and a huge leap from 60hz in terms of game feel and smoothness.

Hi Pelle, zemljače, you did the right thing by buying S3, it's well worth it.

I have the same wheel as you, the settings are everything to 100% in the driver, in LFS you should set FFB rate 100Hz, FFB steps to 10000, for most details (with 200 you had before, it's extremely low res, you can't feel anything). In LFS, you should set FFB strength for each car differently, but generally around 20% for GTi and TBO and about 10% for GTR and fast openwheelers. You have to experiment and set a comfortable level for each car, but these are a rough baseline. I use XFG 22%, XRG 17%, RB4 14%, XRR 7% and so on..

As for VR, you should have LFS take care of the fps and screen refresh rate. Ideally, you want vsinc for this as that way lfs will set 90Hz or whatever is the optimal refresh rate for your display, this will minimize stuttering, but may also introduce some input lag. It will be noticeable at 60Hz (16ms), but already at 90Hz it's somewhat more than 10ms which is very little to be bothered about.

Once more, we have a situation where a wheel user is struggling to set FFB correctly because we don't have any way of visualizing the FFB signal sent to the wheel. At the same time this makes me angry, but also more motivated to continue my efforts to develop a stand-alone app that will utilize outSim packets for the real-time FFB monitor.

Quote from rane_nbg :

Once more, we have a situation where a wheel user is struggling to set FFB correctly because we don't have any way of visualizing the FFB signal sent to the wheel. At the same time this makes me angry, but also more motivated to continue my efforts to develop a stand-alone app that will utilize outSim packets for the real-time FFB monitor.

I agree that it would be very useful to have it natively in LFS.

Do you use the SteerTorque OutSim property to visualise it?

Having a way to understand if the wheel is clipping would be nice.

Quote from Flame CZE :

I agree that it would be very useful to have it natively in LFS.

Do you use the SteerTorque OutSim property to visualise it?

float SteerTorque; // Nm : steering torque on front wheels (proportional to force feedback)

That is exactly correct However, after playing with it and after rigorous testing and comparing it with real FFB signals that LFS actually outputs, I must say that the SteerTorque value is pretty much useless for this purpose The numbers I'm getting there can go as high as 300 or more. This is under normal driving conditions for example XFG in BL1, while under heavy crash into the wall can give 1000 or so. This is for sure not Nm and it doesn't show any clipping. This value is independent of the FFB strength slider in LFS and shows a clean signal even when I observe a clipped FFB signal sent to the wheel. To make matters even more complicated, the value is different for each car as well, so there is no way to scale it correctly since there is no common reference point.

Luckily, there is one more spare 4-byte variable in this packet, that Scawen may actually put something useful inside. For example, a raw value of the FFB signal sent to the wheel (after the FFB strength slider scaling). I'd prefer if Scawen could put in this spare variable a raw FFB signal in the units of the FFB steps we set in the settings (+-10000 for example), as Nm units are not relevant for us at all, since each wheel has its own max torque values and it certainly can't reproduce requested FFB values in these units. Having access to the raw FFB signal value, with clear limits will unambiguously help us to get the real-time FFB monitor.

Quote from rane_nbg :

The numbers I'm getting there can go as high as 300 or more. This is under normal driving conditions for example XFG in BL1, while under heavy crash into the wall can give 1000 or so. This is for sure not Nm and it doesn't show any clipping.

I assume it's the actual torque applied to the car's front wheels, hence the absence of clipping and differences between cars.

Yeah, given that cars can have hydraulic servo-assisted steering, that is quite possible. It's just that such value is of no use to us

Maybe I should make a new thread and give this as an inSim update suggestion? It may have better visibility to Scawen.

Quote from rane_nbg :

Hi Pelle, zemljače, you did the right thing by buying S3, it's well worth it.

I have the same wheel as you, the settings are everything to 100% in the driver, in LFS you should set FFB rate 100Hz, FFB steps to 10000, for most details (with 200 you had before, it's extremely low res, you can't feel anything). In LFS, you should set FFB strength for each car differently, but generally around 20% for GTi and TBO and about 10% for GTR and fast openwheelers. You have to experiment and set a comfortable level for each car, but these are a rough baseline. I use XFG 22%, XRG 17%, RB4 14%, XRR 7% and so on..

As for VR, you should have LFS take care of the fps and screen refresh rate. Ideally, you want vsinc for this as that way lfs will set 90Hz or whatever is the optimal refresh rate for your display, this will minimize stuttering, but may also introduce some input lag. It will be noticeable at 60Hz (16ms), but already at 90Hz it's somewhat more than 10ms which is very little to be bothered about.

Once more, we have a situation where a wheel user is struggling to set FFB correctly because we don't have any way of visualizing the FFB signal sent to the wheel. At the same time this makes me angry, but also more motivated to continue my efforts to develop a stand-alone app that will utilize outSim packets for the real-time FFB monitor.

Hvala za info.
Thank you for the info Rane :)_

Will try again 10000/100, but I remember getting absolutely no effects with these settings. Can't tell why. I will certainly test them again on the same track.

Regarding VR, none of you guys here seem to understand how VR works. First of all, LFS can't adjust Quest 2 refresh rate. I must select refresh rate in the Oculus app, prior to connecting Quest 2 via link cable. Also, in VR mode, LFS greyes out vsync and frame limiter options.

So, VR doesn't work like the monitor whatsoever. Means, I can't see significant micro stuttering on my 60hz monitor, at 60, 75, 90, 120, or 200fps. Doesn't matter. Yes, 200fps vsync off is smoother than 60 with vsync on, because LFS engine works at 100hz, and simple math doing its thing (2x or 1/2x).
LFS is the only sim that I can't have smooth results with vsync on, simply because 100hz doesn't match 60hz/60fps, again vsync on or off. But again, 200fps is closest to vsync on, and I will keep that in 2D.

Stuttering is multiplied in a VR headset. It has two screens that must match the refresh rate, so I guess amount of stuttering is doubled. I tried 72hz, 80hz, 90hz and 120hz, and logically smoothest results are at 90hz, simply because it's the closest number to 100hz. I see a lot of frame skipping, but no suttering, that happens when your fps is close to refresh rate. The best result I'd have at 50hz, 150 or 200hz, but no headset supports that. Actually, luckily no headset support 50hz, as my eyes would melt. I tried 60hz couple of times in the Quest 2, couldn't stand it for more than 2 minutes.

Quote from Pelle79 :

Will try again 10000/100, but I remember getting absolutely no effects with these settings. Can't tell why. I will certainly test them again on the same track.

Each time you ALT+TAB from lfs and open TM control panel to adjust wheel settings, you have to press SHIFT+c in lfs to reinitialize controllers and reset the ffb protocol.

Quote from Pelle79 :

Regarding VR, none of you guys here seem to understand how VR works. First of all, LFS can't adjust Quest 2

We do understand well how it works It is pretty much the same as any other monitor. After all, every VR headset has those same screens inside, with a little bit different specs regarding resolution and pixel size, and refresh rate (but very similar to mobile phone displays). They operate at a certain refresh rate and each app must match it, that's why you get the best results in LFS at its native 90Hz. You are correct about lfs engine running at 100Hz, this is indeed the cause of microstuttering. It's a synchronization problem. Once we have a new update, the lfs engine will run at 1000Hz and then the stuttering will probably not be noticeable at all, hopefully.

I can't give any better estimate when the 1000 Hz update will be released. Eric is currently working on significant updates for Kyoto and I am trying to finish an intermediate semi-compatible release of the public version with improved mods support.

After that release I'll be trying to finish the new tyre physics and the plan is to release that with the new graphics, as both are in the separate development branch of LFS. I have no more information that that, at this time.

---

About the FF display, I seem to remember someone did a mockup of a way that a native FF display could work. Can anyone remember that, or does anyone have a good idea for it, how it could look, how it should be enabled? Should it be something like the display you can see when you click the small car button in Misc or Graphics options (a lateral graph moving up the screen).

Half the issue implementing something like this is the general design and the interface for it. Another significant problem with adding things to the screen are all the situations that can come up when trying to display the new feature at the same time as other things on the screen, so if you could help sort out the details that would be helpful.

I have a slight issue at the moment that whenever I try implementing some "simple feature that would be very useful" I end up spending several days or weeks sorting out all the repercussions that arise. So the thought of taking on yet another task is a bit nerve wracking right now.

By the way, in the development version I do have a simple "MAX FF" red text that comes up in the middle of the screen in the same place as the usual large text. It might be a bit too raw for a public release. Obviously this would be a lot simpler to implement than a graph. So that approach would avoid delays but I'm not sure how useful that would be, compared with the full graph display. Also would it need an option, like "Show FF clipping" NO / YES.

Could it be displayed as a bar in the "pedals" bars at the bottom right of the screen? Since the introduction of EV charge/discharge power bar, it's no longer just pedals there anyway, so maybe it could be used as general place for such info. If needed, it could be accompanied with a new display option to toggle the FF bar on/off, so people don't have to see it all the time even with the pedals shown.

The important thing is being able to see the current FF value and if it's clipping or not.

I see... no graph and just using a bit of the pedal space, if pedals are displayed and FF is enabled. That sounds simple enough.

Something like the attached images? (without the text)

That looks nice What I originally had in mind was a single vertical bar for the force, but the left/right separation is a good idea.

Quote from Pelle79 :

Regarding VR, none of you guys here seem to understand how VR works. First of all, LFS can't adjust Quest 2 refresh rate. I must select refresh rate in the Oculus app, prior to connecting Quest 2 via link cable. Also, in VR mode, LFS greyes out vsync and frame limiter options.

Quote from rane_nbg :

We do understand well how it works It is pretty much the same as any other monitor.

I think the point Pelle is trying to make with this statement is that once you start a VR session with a Quest 2, the headset's refresh rate cannot be changed without backing out of LFS (and the SteamVR connection) entirely. It's the same on the Pico 4 -- standalone headsets which connect to PCs via a video stream simply cannot (currently) change resolution and refresh rate variables on the fly, so there's no way for LFS to "take care" of the refresh rate, unless you are referring to something other than what I am understand as "letting LFS adjust the setting".

----

That force readout looks great! I mean, it looks very simple and barebones, but it's very welcome especially being as unobtrusive as it is. I've used a large graph via SimHub but that's quite a bit less elegant of a solution, although the force-over-time view of a graph has been helpful in diagnosing some odd force/suspension glitches of mods. I think ideally a toggle between showing instantaneous L/R force (as depicted) and a more comprehensive force/time graph would be present, but either's good.

Thanks, you can try the FF display in Test Patch D36.
https://www.lfs.net/forum/thread/102117

Quote from Zopiac :

I think the point Pelle is trying to make with this statement is that once you start a VR session with a Quest 2, the headset's refresh rate cannot be changed without backing out of LFS (and the SteamVR connection) entirely. It's the same on the Pico 4 -- standalone headsets which connect to PCs via a video stream simply cannot (currently) change resolution and refresh rate variables on the fly, so there's no way for LFS to "take care" of the refresh rate, unless you are referring to something other than what I am understand as "letting LFS adjust the setting".

Exactly what I meant. LFS tries to lock the fps to match the refresh rate. I can also try to use frame reprojection (36, 40, or 45fps, times 2 equals refresh rate), maybe that way I can remove the frame skipping/stuttering because of LFS 100hz.
But generally speaking, fast paced games, in this case simracing titles are best running at native fps without frame reprojection, as fast moving scenes and objects create very visible visual artefacts. Frame reprojection is made for flight simming for example, I use it in every single flight sim.

Congratulations! Now you can sit around with the rest of us and whine for S4... Wait. Is there gonna be an S4?

i dont drive on whel i drive on mouse

idk how it works on Thrustmaster, but I had good luck disabling the damping force (and all others if present, excluding spring force, in the wheel software) on some logitech wheels with LFS

LFS uses only constant force, this is one out of 12 possible ffb effects in directInput protocol, a part of Microsoft directX.

You can lower the gain to 0 for all other effects except for constant force and no difference will be felt in LFS. Using autocenter spring will only apply an allways on spring effect, regardless if a game or app is sending ffb. I do not recommend to use it, even thougn it fills with something a huge dead zone at low forces with non-direct drive logi wheels. Problem is that for medium or high forces it becomes stronger than actual ffb from LFS and game experience for ffb wheel users suffers due to it. It's a common pitfall and many players blame it on a bad or dull ffb in LFS, when in fact it was just about poorly setup ffb settings in the wheel software.