And you are using the clutch when you want to shift gears, but nothing happens? In some cars, like FBM, you also have to lift the throttle when you want to upshift.
I did have a problem that I was not shifting into gears correctly, or do a miss shift due to not correctly operating the clutch pedal, but I never had problems like yours on my G29 and H-shifter. I don't think there is any issue in LFS.
While we're at it, how about adding guns and weapons, such that we can use those tanks, planes, and submarines and recreate historical battles in a more immersive experience?
No tnx, this is not a good idea. Just the thought of all the technical challenges of animating a driver character makes my brain hurt.
edit: in VR you can actually step outside of your car and lie next to it for example
What are your end results? What kind of program would you like to make?
There are various approaches, you could use many different programming languages, but to make your life easier some guys already made some libraries for inSim that have all the required functions you will need. It would be smart to use that and for start just make an app that establishes the connection with inSim in LFS.
Gustavo, that's one hell of a specific request to ask from someone for free. Making such a detailed skin is a very time-consuming task, there's probably no one willing to invest their time into it just like that.
To be honest, I'm not sure if the message comes from our Airio or LFS itself. I'm more inclined to say that it's from our Airio, but I could be wrong..
Nikko, the issue is that when you join server and go to a pit right away, all cars are available, or if one just joins race without even going to pit first these messages will appear, but only if it just so happens that the previously selected car is not available in the server.
I already had that enabled, but I still don't see anything under the pedals, I have also ticked the <- -> button in extra status info.
edit: I figured it out, I had the gamepad connected as controler and it didn't show. It only started showing once I plugged in my FFB wheel.
edit2: I love this FF bar, it is exactly what we needed, tnx once again for implementing it Is it possible to have the value of this bar graph in the spare variable of the outSim packet, OSO_EXTRA_1?
// if (OSOpts & OSO_EXTRA_1)
float SteerTorque; // Nm : steering torque on front wheels (proportional to force feedback)
float Spare; // spare -> here the value of FF bar?
Yeah, we see this very common. It is probably an LFS issue. You first have to join race with the car you're sure it's available on server, then after you will have the normal choice of cars and some will be grayed out if they are not allowed.
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.
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.
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.
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.
You may want to have a look at the CPU usage as well, to see if there are any correlations between freezing and how much load there is on the CPU. But still, I'm almost sure this is due to a hard drive (SSD) type of problem, or the way OS or bios controls it.