The issue was much simpler than that actually: I was forcing the packet to its maximum size, no matter the actual inputs, that probably messed up things. Steering does work now, sorry about that. (still not sure why just steering was broken, even when moving it around the buffer, but not really important now)

I will check again on my end, just found it strange that only steering is not behaving properly, even though it's in the middle of other inputs (see screenshots for test program bit - apart from extra light and fog lights which do not work on this car, everything other than steering is fine with this packet containing all inputs). Just FYI, my hold times are given in seconds as floats, input values are given raw as per your documentation.

Edit: Also, could you please confirm that extra light and fog lights only accept 0 (no change) and non-zero (toggle)? If possible, being able to specifically turn them on or off, in addition to toggling, would make it easier to use.

Last edited by Bokujishin, Today, 19:34.

To answer my own question, toggle lights don't seem to be affected by the hold time, which works only for axis inputs, horn, flash, look left/right and I assume gear up/down.
Also for some reason, I'm only getting full left steering, whatever the value (1000, 32000, 55000, all result in full left lock).

I just noticed that while ShowLights is supposed to follow OutGauge's DL_x enumeration, the extra light is missing from there, so unless I'm missing it elsewhere, we can't get this light's status from ISP_AII.

Quick question about the hold time for AIInputVal: what is supposed to happen if we issue a new command before the hold time expires? Is the command overridden entirely, or is the hold time supposed to release anyway? (for instance if we turn a fog light on for 10 seconds, but 5 seconds later we turn it on again for another 10 seconds, will it turn off after the remaining 5 seconds or stay on for the 15 seconds in total?)

Multiple values per packet would be nice indeed, otherwise we may end up sending 10 packets or more every time we want to update (which might be every hundredth for more dynamic driving). And if multiple AIs are to be controlled, sending a single packet per car would help.

I take it 254 is not supposed to affect lights, only steering and throttle?

GodotInSim v1.4 is now available on GitHub.
It introduces the AI control packets added in LFS 0.7F2, and the project is now using Godot 4.4 (still in beta).

Input 254 does not seem to do anything right now, all controls stay in their current state.
When stopping control with input 255, the AI will immediately come to a stop and turn the engine off, as if it had no path to follow.

Using the official paths or even custom ones, we can give AI "eyes". Plus we can change routes on the fly, so in a sense they will theoretically be better at navigating. Obstacles may be manageable too: we have InSim packets for those.

I strongly believe that someone experimented enough in this area will be able to make better AI than what is currently available in the game (how much they can be driven to the limit remains to be seen, though, but at least we can give them more character than what looks like a PID to follow the race line, with some offset tolerance for overtakes).

Maybe not a bug per se but rather a default setting that I believe should change: when importing OBJ files, all triangles have a n.c.level of zero; I believe it should be medium by default instead.

Another one though: the point count can be wrong in some circumstances (not sure which, though). For instance, there is a maximum of 24 points on LOD3, but the editor can often show a higher number (50 in my case, even though selecting all LOD3 triangles and then their respective points will only select 22).
For what it's worth, as I was trying to mirror part of LOD3, the count went up to 55 points (for an unchanged 40 triangles), and then the editor was complaining I had more than 24 points.

Last edited by Bokujishin, Yesterday, 18:44.

It's true we don't actually need paths with this system, since we can indeed handle them externally entirely (they would still be useful to make OutSim's IndexedDistance work, but that's another topic, namely telemetry).

MCI packets are available to everyone, as long as your InSim is configured to receive them from the IS_ISI packet. I guess you edited while I was typing

So Scawen's draft should be enough to have basic car control, well under the limits, and more data could allow us to make AI get closer to the limit (car pitch and roll could be used to determine the car's behavior, instead of only position and heading, and their derivatives if speed/acceleration are not included).
Or I guess some form of deep learning could work around those limitations? Though it would probably be wasteful to go that route, with all the possible car/setup combos.

This sounds great! As you say though, we might need some more feedback data about the car, since OutSim works only for a single car (and not from external views, if I can suggest that it be made to work for all views ). Since you added dash lights from the OutGauge definition, maybe you could add the main data from OutSim as well? This would add pitch and roll to heading, which would make a good foundation for external computation of AI control (of course, if OutSimWheel data can be added as well, and maybe torque, that would be excellent).

If I'm not mistaken, using this in combination with the PTH format should allow us to make our own driving/racing AI - but for better usability, it would then be great if we were able to load a custom PTH file (for LA layouts, but also custom layouts in existing configs, e.g. BL1 with a ramp to skip the chicane, not just BLX and such).

Slow progress but I'm working on the interior, made a very basic blockout of the frame's shape, and completed the AC control panel (and the roof part as well).

I also prepared the skin template, because even if I still have some minor things to adjust, mappings should stay as they are. And I made sure the template has a 1:1 aspect ratio for all parts too.

Last edited by Bokujishin, Wed 22 Jan 2025, 20:10.

Great to know this is on your radar! When you do decide to tackle this, if you feel like trying my implementation (roughly 50-ish useful lines overall), I'm willing to just give it to you, that could make for a first test before you decide to dive into the rabbit hole.

But of course, we're all expecting the new graphics and track updates first

Alright, I think I can call this done as far as proof of concept goes. I now have a parameterized, more realistic (but still fake) model that can somewhat mimic what BeamNG does. Now of course, it cannot be perfect, and adjusting some parameters can throw the entire thing off, which is why I will show the parameters and value ranges that I believe work best.

I use 4 parameters:

• spacing: controls the spacing linearity between part-throttle curves (0 = linear, 1 draws curves toward 100%)
  
• dip power: controls the interpolation after the transition, lower powers result in faster drops
  
• RPM transition: controls the RPM range ratio at which the transition occurs: 0 means we don't follow the 100% throttle curve at all, 1 starts the interpolation at a fraction of the range corresponding to the throttle value
  
• transition smoothing: controls the amount of smoothing (partial interpolation toward the scaled torque curve), 0 results in no smoothing (sharp transition), higher values smooth the transition more
  

The parameter ranges that seem to give the best results are 0.5-0.7 Spacing, 0.15-0.25 Dip Power, 0.4-0.6 RPM transition, and 0.1-0.5 Transition Smoothing.

See the attached screenshots for results: "coilcup" gives the complete result for the engine I showed in my previous post, the others show torque and power curves for the engine shown in the BeamNG article, for comparison. At 0.25 dip power, I'm a bit on the high side for low-RPM torque, 0.15 may be more appropriate here, but high-RPM torque might then become a bit too low (which shouldn't really be an issue, as part-throttle, especially 10-30%, can easily be adjusted from pedal input).
For reference, I am also including the shape of my transition smoothing, this is basically a quadratic interpolation away from the transition point, and scaled depending on throttle input and the smoothing parameter - RPM transition can be changed as well to move this interpolation around, and avoid "clipping" at either end of the RPM range.

I would really appreciate if Scawen especially can have a look at these pictures and give his thoughts about this, as I truly believe this should not be a difficult change to make (but would still require proper testing), and it would benefit both realism and driving comfort.
Feedback from everyone else is also appreciated!

Last edited by Bokujishin, Sun 19 Jan 2025, 13:17.

On the bright side, if it works in the editor, it should mean it will also work after the graphics update

Just a quick note on the subject of those translucent sunshields, since I added one to the Laurent Coil Cup, I can say you do not need to manually build each triangle, I did duplicate and flip them, then merged the vertices and assigned zero normal contribution to the inner side as well as the same smoothing group, and it works just as well. (almost pure white on the screenshot, not exactly the most interesting to see the effect, but it receives shadows just fine)

Quick follow up on this, as I experimented slightly with values extracted from my WIP Clio Cup mod, see engine torque/power plot from the editor.

As a reminder, LFS currently uses only the max torque (at full throttle), and directly scales it relative to the throttle input: 300N.m at 3000RPM at full throttle will yield 150N.m at 50% throttle, and so on.
In my "first version", as I mentioned in my previous post, I only need a bit more info: idle RPM and redline RPM, and then add some parameters to tweak the model. I currently have a single parameter, which controls the percentage of RPM range (between idle and redline) at which the transition occurs (further scaled by throttle input). The result can be seen in the attached screenshots.

We can observe something that is somewhat similar to BeamNG's 2016 model, it feels to me like I'm mainly missing the curves-bunching-up-toward-100% effect I mentioned previously. My transition parameter is at 50% of the RPM range, and while raising it could get me closer to BeamNG's 2016 model, this is not my goal (since they improved it since, and my 50% value actually works closer to their 2023 model).

I will now experiment with changing the high-RPM linearity, and introducing smoothing at the transition, but right now, my model only performs a few more operations and uses one additional linear interpolation, with an easing curve thrown in the mix, and that's it: I interpolate values from full throttle to input throttle between the transition point and the redline, and the lerp weight follows an easing curve (so we dip faster at the start and flatten out toward the end).

In other words, this is still an incredibly cheap model, and while it remains a fake one (as in not physically-based), that should already show improvements over the current behavior (again, especially when starting to roll at non-full throttle, and out of corners), although I must admit I have no idea how the harsh transition would turn out in the simulation (BeamNG used this model for about 7 years, so it cannot be that bad...).

As a comparison, 1500RPM yields 229N.m at full power on my example engine (from the LFS editor curve). If we try to roll out at 30% throttle, that's about 69N.m (note that on my chart, we actually find 54N.m, because I interpolate from the negative red series at 0% instead; that line in particular is completely arbitrary). With the current state of my model, however, we have the full 229N.m available at that point, which will make it much easier to start rolling without stalling and without having to floor the throttle and burn the clutch at 4000RPM.

Last edited by Bokujishin, Sat 18 Jan 2025, 19:43.

Edit: See this post for my proof-of-concept implementation results (Scawen, if you could have a look, that would be greatly appreciated!).

After watching Niels Heusinkveld's video about the "wrong" throttle model used by many sims (including LFS, but also the likes of ACC, iRacing and others, even the newer AC Evo (at least in its early access status)), I've been thinking about ways to improve this behavior.
First off, how does LFS compute part-throttle torque? Well, it simply scales the torque curve to the throttle input - this kind of works in general, but comes with two main drawbacks:

• low RPM torque is way too low: torque should follow the full throttle curve at low RPM (or close to it)
  
• higher RPM torque can be too high/over-peaky: part-throttle torque should dip significantly at higher RPM, instead of following a flattened full-throttle curve
  

The first point is responsible for the difficult launch behavior of most cars: it's incredibly difficult to just start rolling with low throttle in a realistic way without stalling. It also makes cars "too easy" to drive out of corners, in the sense that they will lack some of the torque they should have, therefore drivers are encouraged to almost floor the pedal instead of feeding throttle.
The second point means wheel spin behavior is weird, as higher RPM will actually tend to increase torque, therefore worsening the spin, instead of decreasing torque, which helps stop the spin.

For more detail, please do refer to Niels Heusinkveld's video https://www.youtube.com/watch?v=0gW-cbSX3Uc

Now, what can be done to improve the model? Well, LFS could follow in BeamNG's steps: https://www.beamng.com/game/news/blog/throttle-torque-curves/ (by the way, there's another video by Niels comparing LFS's model with the improved one, no need to talk about the third model, as it's plain wrong and just bad).
This article is really nice to see how the curves look, and combined with Niels' video, they should give enough understanding of the issue.

My understanding of BeamNG's 2016 model is that they basically follow the 100% throttle curve up to a certain point, and then dip down to lower values. Their 2023 model refines this by introducing some smoothing at that transition (maybe it improves other areas, but let's focus on the basics for now).

From the above, I would like to suggest introducing a new throttle model, which basically works as follows:

• keep the current max torque logic, as it's the full throttle torque, and is good as is
  
• for part-throttle torque, follow the full-throttle torque up to some point, then interpolate down to the current scaled-down (interpolated) part-throttle torque curve, which is currently the final torque value
  
• introduce a smoothing transition to prevent abrupt behavior change when leaving the full-throttle curve
  
• introduce some parameters to control the general shape of the part-throttle curves, either per engine (and exposed to mod makers) or as general, hard-coded values that would not be accessible.
  
• additionally, the target throttle curve should be scaled up slightly, as spacing doesn't seem to be linear: 10% throttle may be spaced at 20% instead (random value here), with the curves bunching up toward full throttle.
  

As a first thought, and based on BeamNG's curves, I would do the following:

• transition point: for throttle input T, aim for RPM_idle + 0.5*T * (RPM_redline - RPM_idle)
  
• dip down from full throttle curve: interpolate exponentially from 100% to T, between the transition point calculated above and redline RPM
  
• smoothing: haven't thought too much about that yet, I'll try experimenting and see if I can come up with something decent, but I guess we could use a small percentage of RPM_redline-RPM_idle, centered around the transition point, as an RPM interval to interpolate linearly between the curves
  

My hope with this is that we could, at some point, replace what I believe is a simple "throttle input -> lerped torque output" formula with a slightly more complex one (probably involving a couple lerps and an exponential interpolation, not exactly resource intensive calculations), that could result in a somewhat low-hanging fruit type of improvement, that would make driving both more realistic and more enjoyable (especially for cruisers with manual clutch, I guess? )
Now I'm no genius, so if you see any obvious flaw in my reasoning and ideas, feel free to say so!

Last edited by Bokujishin, Sun 19 Jan 2025, 11:08.

Does anyone know how to convert differential ramp angles to LFS percent values? I believe 90° becomes 0%, but I'm not sure what angle would correspond to 100% - in any case, LFS values range from 10% to 80%.
Official Renault documents mention 2 variants, with ramp angles 29.5/90 and 32/90.

Small improvement of the dashboard's geometry as well as the dash "visor", and I went ahead and made an actual dash - not that easy to work around some of the limitations, I used the LED tacho from s_clock_formula, and tweaked the mapping's colors to make the green and orange segments (not exactly satisfied with their color, but I won't be able to get much better than this).

In addition to my previous post, instead of allowing multiple clock types, an alternative would be to have a single "superclock" type which could enable or disable individual elements (clock tacho, LCD tacho, LED lights, basically everything unique that can be found in all clock types), so we can actually choose what we want instead of compromising one thing for another.
I assume the current clock types are actually shaders that use game state as input to draw the corresponding texture? In that case, it doesn't sound too much of a stretch to have a supertype (but of course would require moving all vehicles to that, unless a new type is added while keeping backward compatibility).

For my Clio Cup mod, I will try using LED rev lights to emulate what can be seen in the above screenshot, not currently sure I'll be able to turn the red LEDs green, in which case I would also like to ask that the color be editable (at least so we can make them white and edit the colors through mappings).

EDIT: To illustrate that last point, I added screenshots to show how the rev lights look right now, both off and on - I did manage to get red, orange and green, but just barely, orange and green are both green mappings with no blue, full green, and a varying amount of red, so control is rather limited here, plus as you can see, they all look green when off.

Last edited by Bokujishin, Mon 13 Jan 2025, 07:25.

I forgot something important: the roof intake! Now taken care of. I also started detailing the plastic bits around the windows, including the rear door handles, and added the sun visor to the cup version.
That's all I did on the exterior modeling, as I wanted to start the interior a bit. The dashboard of the cup version is basically a pre-2023 RS Line version dashboard with some of the lower-end buttons and controls, the rest will be more different between cup and road versions.

But I also found documents on Renault's website that give very juicy technical details, which really helps in the vehicle editor. For instance, they have damper charts for cup, rally (asphalt/gravel) and RX versions. Unfortunately, the dampers are more or less bilinear in their behavior, so I had to go for the middle ground as LFS only allows linear damping.
Another example is gear ratios: I now have the exact same ratios as the real car (since those appear to be fixed), and all shift points are around 5800 to 6000 RPM, as they should. My only concern is the very long first gear, which makes it difficult to start the car gently without stalling or overheating the clutch.

Anyway, with those changes (and more as I find data in the documentation), the car now lifts its rear inside wheel very easily in corners (in BL1 for instance, it will basically spend the entire hairpin and right hander after the back straight on 3 wheels).

I think another way to try and improve engine sound specifically, would be to know how LFS uses the WAV sample and how the parameters affect it. When looking at the waveforms for default cars' engines, they all fade out and the second half of the sample is almost silent. I did manage to create a couple "proper" engine sounds in Audacity by layering sine waves and some white noise then fading out, but they're not very good, and don't seem too different or unique anyway, plus they tend to clip very easily.

If anyone knows more about this, I'm interested (would also love to know how Scawen or Eric generated the official ones).

Quote from pärtan :

Sunlight is pretty much parallel with only a 0.5 degree shadow spread, so the effect shouldn't be super obvious in this case.

While sunlight can be considered to be parallel because of the distance, its enormous size is still relevant for umbra and penumbra (and in the case of solar eclipses, the penumbra area can cover the entire Earth even when actual umbra is a much smaller spot). This probably goes quite a bit off topic though but you can still see this effect in plain sunlight. Another light source that would show this effect very much is a car's headlights, though this is much more complex to do because of the spotlight source instead of the sun light, and much more expensive to compute.

Still, as we are on the subject of lighting, I do wonder what kind of tone mapping, and maybe HDR Scawen is using? Several screenshots seem to show very washed out colors on brake lights for instance, while in real life, they appear very red. I would personally recommend investigating tone maps such as ACES or AgX for instance (AgX being more realistic, and Blender offers a "punchy" variant that has more contrast). Then again, the brake light issue might just be an issue to do with the emissive textures, which are probably additive.

And while I'm on brake lights, I wonder if the various lights are more visible in the new version? On some cars, it's currently very difficult to tell when the driver in front is braking, unless you're right behind them - again, in real life you could spot a brake light from several hundreds of meters no problem, but in games, they're difficult to see because they appear so small they literally don't get displayed properly.

Good to know you're using cascaded shadow maps, do you also blend them to avoid the sharp transitions?
Also, does "about half way down the page" include PCF?

I would also like to ask Eric a small question regarding Kyoto: where does the original Kyoto's Japanese come from? Since some of it seems to be a bit grammatically broken (see this recent addition to the manual), I was curious, and on the new screenshots, the Japanese looks correct so far.

I have a very old spare PC (built in 2010, i5 2500k, Nvidia GTX560Ti, 8GB RAM), the thing is so old the GPU does not support Vulkan (but does support DX11), it struggles with basic multitasking and eats through its RAM, even on Linux. Well guess what, LFS runs fine even on that hardware (at least in single player with 20 AI, I never tried multiplayer on that PC). Even a 500€ laptop you can buy today would run better, we can't cling to obsolete hardware and expect software to not take advantage of more recent technology.

If your PC is old but supports DX11, I would even expect performance to be better on the new LFS graphics, or at least very similar, as multi-threading means the CPU should use more cores and not be limited by single-core speed; yes the GPU will be working more, but DX11 optimisations over DX9 should help, so unless you're already GPU-bound, you shouldn't see a significant drop in FPS.

And to add to gu3st's point: I built my current PC in January 2023, it is pretty beefy, and yes, LFS runs better on the CPU's integrated GPU than it does on my very old PC.