But another similar and extremely annoying thing happens quite often to me: I write a long reply that took me quite some time to write nicely, then click the reply button and the forum says: "Access denied, you don't have permission to post" and I'm logged out of the forum. After that, I lose motivation to write it again and simply do not reply..
Best is to make a report in our forum. Then we will deal with it. You can find forum link by typing !forum in the chat, then use arrow keys to find the text and ctrl+c to copy it. Or use !discord and report it there under reports.
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.