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.
Last edited by rane_nbg, .
Maybe I should make a new thread and give this as an inSim update suggestion? It may have better visibility to Scawen.
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
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.
Last edited by 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.
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.
Last edited by rane_nbg, .
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.
At this point, given the update progress with car mods, lighting, multithreading, and tire physics, I think it's best that Scawen only thinks about updating the inSim core in an optimal way that would allow us to create external apps.
Then, we could in a very similar way to creating mods, be able to create a plethora of different apps and offer features that Lazy had, or even more. For a long time now, I've been desperately expecting a real-time FFB graph monitor, but now I see that this can also be a feature of such apps. An example of how they made available those Python apps in Assetto Corsa, that would be awesome for LFS, a new playground for us So my suggestion for Scawen is also to think along the lines of updating inSim with the simple 2D graphical capability of drawing points, lines, circles, squares, and similar on the screen.
As mentioned by Bass-Driver, we would need a new inSim packet that contains nodes, which is automatically sent whenever any car comes into contact with it (within some predefined sphere radius). Therefore, a node packet should also contain its spacial x,y,z coordinates as well as its radius, optionally maybe even a direction (heading) vector. Each node should be a physical sphere rather than a circle, this will make our life with math calculations easier.
Bear in mind that we should not distract Scawen way too much at this moment, there are many more important things he's working on, that are highly expected from all of us.
Then, we could in a very similar way to creating mods, be able to create a plethora of different apps and offer features that Lazy had, or even more. For a long time now, I've been desperately expecting a real-time FFB graph monitor, but now I see that this can also be a feature of such apps. An example of how they made available those Python apps in Assetto Corsa, that would be awesome for LFS, a new playground for us
So my suggestion for Scawen is also to think along the lines of updating inSim with the simple 2D graphical capability of drawing points, lines, circles, squares, and similar on the screen. As mentioned by Bass-Driver, we would need a new inSim packet that contains nodes, which is automatically sent whenever any car comes into contact with it (within some predefined sphere radius). Therefore, a node packet should also contain its spacial x,y,z coordinates as well as its radius, optionally maybe even a direction (heading) vector. Each node should be a physical sphere rather than a circle, this will make our life with math calculations easier.
Bear in mind that we should not distract Scawen way too much at this moment, there are many more important things he's working on, that are highly expected from all of us.
Last edited by rane_nbg, .
A little bit of math. Say you have 2 points A(x0, y0) and B(x1, y1) and you want to get a line that is defined by them. The equation of the line is: y(x)=(y1-y0)/(x1-x0)*x+y0. If you need to find a direction that is perpendicular to this line, its coefficient of direction is kp=-(y1-y0)/(x1-x0). Using the same equation for a straight line you can get another line: yp(x)=kp*x.
In 3D space, you can get the distance d between 2 points A(x0, y0, z0) and B(x1, y1, z1) as:
d=sqrt((x1-x0)^2+(y1-y0)^2+(z1-z0)^2)
Hope this helps.
In 3D space, you can get the distance d between 2 points A(x0, y0, z0) and B(x1, y1, z1) as:
d=sqrt((x1-x0)^2+(y1-y0)^2+(z1-z0)^2)
Hope this helps.
Last edited by rane_nbg, .
Yeah, this feature will be good enough if it has at least 0.1s precision, which I think will suffice if we have at least some approximate path coordinates available or other players' data - you may add a new packet for it.
Last edited by rane_nbg, .
One thing that comes to my mind is to enable access to race line coordinates via inSim, if there is one available, it may be useful for calculations of time delta. Or access to other players' x,y,z car coordinates and vx, vy, vz velocities.
Last edited by rane_nbg, .
Unfortunately, there is no parental control in LFS whatsoever. The best thing you can do is just to block the chat completely, with a "-" button on the keyboard.
Second, join our AirAttack GTi server. It's quite child-safe and we have admins online most of the time. We have an inSim system that autokicks anyone using bad words. We try to prevent bad language and insults by moderation using punishments like kicks or bans. We also try our best to create fun and competitive casual racing for everyone, from beginners to pros. Many of our admins are patient enough to give driving lessons and share car sets. If you see anything inappropriate just contact our admins online, or use our discord.
Second, join our AirAttack GTi server. It's quite child-safe and we have admins online most of the time. We have an inSim system that autokicks anyone using bad words. We try to prevent bad language and insults by moderation using punishments like kicks or bans. We also try our best to create fun and competitive casual racing for everyone, from beginners to pros. Many of our admins are patient enough to give driving lessons and share car sets. If you see anything inappropriate just contact our admins online, or use our discord.
Last edited by rane_nbg, .
I agree, very useful feature. Once delta is implemented, a relative timing is a small upgrade which should be somewhat easier to add later on.
Well obviously, yes.
The trick is that while driving an imaginary race car, there is no real-life counterpart to compare the handling to, so in principle, we have no idea if the car behaves as it should or not. At least for me, I only care for the car to be challenging and fun to drive. Is it real or not, I don't care much After all, it's only a PC game (sim) and no matter how hard the devs try, it will only be an approximation of a real race car physics.
If we dream, consider this. Let's say you have an awesome simulator of a real car at a real track. Even after driving many laps in the simulator, after getting in a real car, there will again be quite a big learning curve, but there will be left a race craft or knowledge about how to learn to adapt to the car and how to find an optimal race line. And that's all that matters, LFS can provide that. For example, 1st time I sat in a rental karting on an unknown-to-me track, I was better than everyone that day after only 10 laps. I knew very quickly how to find the limits of the little thing and this I owe to many hours of driving various combos in LFS.
The trick is that while driving an imaginary race car, there is no real-life counterpart to compare the handling to, so in principle, we have no idea if the car behaves as it should or not. At least for me, I only care for the car to be challenging and fun to drive. Is it real or not, I don't care much
After all, it's only a PC game (sim) and no matter how hard the devs try, it will only be an approximation of a real race car physics.If we dream, consider this. Let's say you have an awesome simulator of a real car at a real track. Even after driving many laps in the simulator, after getting in a real car, there will again be quite a big learning curve, but there will be left a race craft or knowledge about how to learn to adapt to the car and how to find an optimal race line. And that's all that matters, LFS can provide that. For example, 1st time I sat in a rental karting on an unknown-to-me track, I was better than everyone that day after only 10 laps. I knew very quickly how to find the limits of the little thing and this I owe to many hours of driving various combos in LFS.
Last edited by rane_nbg, .
I wish I knew what this means. It does sound very smart, I'll give you that
He explained it already in a very detailed manner, but I'll give it a shot in layman's terms.
When you make your button, somewhere in the code you have to specify which value you want this button to display. So, instead of that value put Round(value, 0). The round function does exactly what you need, it takes the Var you input and rounds it up to the nearest integer, and returns the value.
A variable is a term in programming that is used for some quantities that are changing in real-time through various parts of the code, for short we just say Var and it can have many different types like integer, float and so on
When you make your button, somewhere in the code you have to specify which value you want this button to display. So, instead of that value put Round(value, 0). The round function does exactly what you need, it takes the Var you input and rounds it up to the nearest integer, and returns the value.
A variable is a term in programming that is used for some quantities that are changing in real-time through various parts of the code, for short we just say Var and it can have many different types like integer, float and so on
Yes, I see. Well, I think it is a nice feature, most racing sims have some form of it.
Let's see what Scawen has to say. I'm sure he will find some way to implement it quickly. However, it is far from a trivial programing task which may introduce further delays with other updates
Let's see what Scawen has to say. I'm sure he will find some way to implement it quickly. However, it is far from a trivial programing task which may introduce further delays with other updates
Last edited by rane_nbg, .
@Viperakecske
Should this delta be displayed in real-time, or is it enough if it is only shown per sector, like 3 times per lap, depending on how many sectors a particular track have?
If you want it in real-time this is in my opinion much bigger programming challenge then to just implement delta calculations for each sector, because LFS already has that and it needs only a small feature upgrade.
Our Airio can also show you the time for each sector and the delta is just the difference between that value and some reference value. If you want the simple version, then I propose that Scawen make some way of selecting what will be the reference value and display the delta somewhere. One can choose the ref between his PBs or else's or WR or current fastest player's sectors.
Should this delta be displayed in real-time, or is it enough if it is only shown per sector, like 3 times per lap, depending on how many sectors a particular track have?
If you want it in real-time this is in my opinion much bigger programming challenge then to just implement delta calculations for each sector, because LFS already has that and it needs only a small feature upgrade.
Our Airio can also show you the time for each sector and the delta is just the difference between that value and some reference value. If you want the simple version, then I propose that Scawen make some way of selecting what will be the reference value and display the delta somewhere. One can choose the ref between his PBs or else's or WR or current fastest player's sectors.
Last edited by rane_nbg, .
Actually, that is very well said
What I think his point is to make us all sad that he is leaving or maybe push devs to update more frequently, which is ofc not going to happen, not because of him or anyone else.Farewell dude, and thank you for playing LFS for 15 years, I wish you joy and many good races in RaceRoom or where ever
PS. maybe try to go outside more
LFS says "can't generate AI path for bikes now", so I guess that there will be such a feature in the future.
Both
Jokes aside, it may be that F1 is just too fast for AI to handle, or you have a bad car set for them.
Jokes aside, it may be that F1 is just too fast for AI to handle, or you have a bad car set for them.
As far as I am aware, a new thing about tire physics will be to develop a numerical model that will simulate as close as possible the tire slip curves, where at the moment those curves are input into the game engine as some parametrized functions with rough steps, taken from somewhere else. Also, it may be that the tire model will have more than 24 radial and 3 axial zones as it has now, we'll have to wait and see. Obviously, the simulation will be more accurate if you have a smaller (more high-resolution) grid to define the tire model. This about temperatures is more about fine-tuning the model or making it with enough free parameters that will allow fine adjustments. So rather than trying to manually optimize a tire slip curve such that the end result is something realistic, Scawen wants to try to simulate the curve realistically in the first place with a more detailed tire model and avoid having to rely on external input curves.
About multithreading, Scawen is working on two threads that can run on a CPU in parallel, while sharing the same resources. Even if the CPU has only 1 core, it can still happen that it has more than 1 thread - multithread. Depending on the CPU architecture and operating system, it will always try to run the code as efficiently as possible. That may be such that both threads are run on core0 on separate threads, while other cores are remaining unused.
To sum up, one needs at least a CPU with 2 cores and 1 thread per core, or a single-core CPU with 2 threads to take advantage of this new update. Will it run better on a more capable CPU? is unlikely, but we also have to wait and see, as Scawen said he is testing it on his particular dual-core CPU where he already saw significant benefits with respect to a single thread LFS code run on the same CPU.
About multithreading, Scawen is working on two threads that can run on a CPU in parallel, while sharing the same resources. Even if the CPU has only 1 core, it can still happen that it has more than 1 thread - multithread. Depending on the CPU architecture and operating system, it will always try to run the code as efficiently as possible. That may be such that both threads are run on core0 on separate threads, while other cores are remaining unused.
To sum up, one needs at least a CPU with 2 cores and 1 thread per core, or a single-core CPU with 2 threads to take advantage of this new update. Will it run better on a more capable CPU? is unlikely, but we also have to wait and see, as Scawen said he is testing it on his particular dual-core CPU where he already saw significant benefits with respect to a single thread LFS code run on the same CPU.
Last edited by rane_nbg, .
Normally, anything with 8-10Nm max holding torque is more than enough. This is not to say that you will max it out, you will probably use 20-30% of that torque in real racing conditions, but it is good to leave some headroom for high torque spikes that will not be clipped. Don't worry about setting it up, you will manage as there are plenty of resources for any DD online.
It's a good idea, demo servers could very much benefit from this. If it ever gets realized, I just ask to leave the wiggle room for adjusting the steer lock and brake pressure, as this has to be user optimized for every controller type - keyboard, mouse, gamepad, joystick, or wheel.
One curiosity though. How do we agree on which setup to choose as a "fixed one"? Could be fun to have a poll or a voting system for it some day.
One curiosity though. How do we agree on which setup to choose as a "fixed one"?
Could be fun to have a poll or a voting system for it some day.
Last edited by rane_nbg, .
It's good that you were able to narrow down under what conditions the freezing occurs. Yeah, really hard to say why it happens, I can't say if this is a software or a hardware problem.
I experienced a similar problem on a very very expensive HP laptop workstation that my wife uses for her work. It just kept randomly freezing, even up to 20 times per day in the middle of normal work. It did help for a while to disable all run-time power-saving options for SSD in bios, but it again started occasionally freezing which is a real bummer. She had to return it because it was unusable for anything, HP support was useless and this is a serious flaw in the low-level hardware-software design. I hope, it's not the case with your laptop.
I experienced a similar problem on a very very expensive HP laptop workstation that my wife uses for her work. It just kept randomly freezing, even up to 20 times per day in the middle of normal work. It did help for a while to disable all run-time power-saving options for SSD in bios, but it again started occasionally freezing which is a real bummer. She had to return it because it was unusable for anything, HP support was useless and this is a serious flaw in the low-level hardware-software design. I hope, it's not the case with your laptop.
FGED GREDG RDFGDR GSFDG