I finally fixed the windows (side, rear and windshield), no more holes there either. I also continued working on the interior, adding some details with accessories (footrest, brake pressure limiter and gear stick support), and started playing with adding the safety net too.

I'm honestly worried about hitting the triangle limit now, I'm almost at 62k triangles, and the seat is very very rough, I still don't have a proper interior, especially around doors, the dashboard is still somewhat incomplete on the sides, and I would like to add the fire extinguisher behind the driver seat too.

I may try and optimize some bits, but not sure how much I'll be able to save. How does everyone deal with details? How much can we get away with oversimplified geometry and some proper texturing?

Here's a link to a first release on GitLab: https://gitlab.com/Cykyrios/lfs-setup-validation-tool/-/releases/0.1.0
Feel free to try it and tell me if you have any issue.

For info, I made the batch validation output a text file, so you can actually see the results
You can also set the path to the RAF folder if LFS is not installed at its default location (note that for Windows paths, you need to double the backslashes), you will find the config file for that in the same place as the default path for loading setups (%appdata%\Godot\app_userdata\LFS Setup Validation Tool).

Lovely texturing work!

I made a GUI tool to create offline setup restrictions, that you can then use to automatically validate setups. The intended use is to have drivers send you their setups, so you can batch validate them, which should simplify limited setup races and championships.

The GUI is mostly a reproduction of the setup tabs of the garage view so it's easy to find values. Each setting can be clicked to choose a restriction (unrestricted, fixed value, list of specific values, or allowed range). If the currently loaded setup has values falling out of the restrictions, those will be highlighted in red (restricted fields are highlighted in gold).
The batch part goes through all the setup files in a given directory and simply prints the loaded setups and whether they have any invalid values.

Ideally, I would also like to have an InSim counterpart that can display the restrictions while in the garage view (client side or maybe server side), but I'm not yet sure I'll do this.

I'll have a GitHub repository and binary releases up in the next few days as time allows, in the meanwhile any feedback is appreciated!

Quick note on some caveats: To make this easier to work with, especially in the final drive tab, I am loading the car_info.bin files from the LFS/data/raf directory, which allows me to have the correct differentials, gears and (as a bonus) tyre sizes displayed. Unfortunately, disabled systems cannot be hidden (handbrake, ABS, TC when not allowed in the vehicle itself), unless maybe this can be found in the .veh files. This does require the car_info.bin file to exist, which can be done by pressing O in the garage view. The RAF directory is assumed to exist at C:\LFS\data\raf on Windows and /home/$USER/.wine/drive_c/LFS/data/raf on Linux, I will probably add options for this later on.
All values are interpreted as floats, this is generally not a problem, but requires typing 0 or 1 for off/on (ABS, TC). Differential types, tyre manufacturers and compounds go from 0 to however many values they have (e.g. 0 means R1 tyres, 7 means knobbly tyres).

Last edited by Bokujishin, Tue 11 Feb 2025, 22:25.

I would like to suggest implementing reverse Z depth to mitigate z-fighting visual artifacts that can be observed in the game.

For the non-technical people reading this, this simply means less flickering of geometry that is very close to other geometry: concrete objects in custom layouts, lines and arrows on the ground (which seem to be placed about 1mm over the ground) and other such graphical issues.

To give a few actual examples:

• South City, behind the grand stands across the main pitlane at /cp 20174427 4722383 9957501 19884 15474 0.0 60.0 - any time you move the camera, you can see the arrows flicker.
  
• Concrete parts: place a few concrete slabs next to each other, with some intersections, and you will also have severe flickering.
  
• In the Laurent Coil Cup mod I'm working on, I chose to have the sunshield as separate geometry above the windshield, because I need some of the windshield's geometry to be double-sided (the black part on the edges), and I also want to use the same windshield for the non-cup version, which doesn't have the sunshield; I need to separate the geometry by over 4mm to stop z-fighting from being visible in long-range shots, but in closeup shots you can actually see that offset.
  

This is currently alleviated somewhat by offsetting the geometry, that's why the arrows and other markings on the ground are slightly above it (if you go to /cp -6264565 6547061 674862 -30063 4209 0.0 60.0 in Blackwood, you can actually see that offset for the pit boxes through the camera's near clip plane). The racing line darkening, as well as the thinner lines visible on Blackwood especially, are actually offset by several centimeters! (/cp 756993 -11233401 -6824 -3991 3694 0.0 60.0)

There exists an efficient method to fight this, called reverse Z depth, which I believe is not currently used. Here are a couple links to articles talking about it and its implementation: NVIDIA article, example and additional links
This technique should have little to no performance impact, but should greatly improve the z-depth sorting, which would reduce graphical glitches and maybe even allow for less geometry offset.

Last edited by Bokujishin, Sun 9 Feb 2025, 22:12.

21/Read & Understood

I was thinking about this again, and came up with related features on the InSim side:

• we should be able to retrieve this info (either as an addition to IS_NPL or a separate packet, IS_NPL doesn't seem to have much spare room for this)
  
• an action should be added to IS_JRR to refuse a join request if the selected number is already taken by another car
  

Dashboard update: now mostly hole-free! Yes, even the vents are air-tight
I still have to model the ends of the dashboard on either side, and fix the transition from the dashboard itself to the vents.

In addition to the license plate (and its textures s_plate and s_plate_alp that we can use for mods), it would be really nice to also have a way to add a number and a name (I suppose max. 3 digits and probably around 15 characters for the name (or whatever number fits the variables I suppose)), with associated textures s_name/s_number and s_name_alp/s_number_alp, so we could display them on mods without having to rely on adding a special spot in the skin template. Not only that, skins do not support alpha, so we cannot put name/number on windows without making the surrounding region opaque.

Since event signups were just recently updated, and we can choose our number when signing up, it would make sense, at some point, that said number actually be used in game (and automatically assigned if you signed up for the event?).

Most frequent use case for racing, if I'm not mistaken: name and/or number displayed on windshield, rear or side windows, and/or on the dashboard.

EDIT: I might as well ask for driver flag as well, since it's pretty common to see it next to a driver's name, and the game already has those flags.

Last edited by Bokujishin, Sat 8 Feb 2025, 14:59.

I worked on LOD2 since I was basically using the version you can see in my first few posts up until now, and now I'm actually done with LOD2 before LOD1

I ended up with about 5.5k triangles, I hope this won't be considered to be "very high"... To be perfectly honest, I would really hate to lower the count down to even 2k, as it would completely destroy the visual fidelity of the car - with 5.5k, I basically cannot see the transition to LOD2, which is the second purpose of levels of detail, after optimization. Below 2k or even 1k triangles should, in my opinion, only be for a third visual LOD (not the one LFS uses for collisions).

Anyway, now I need to get back to modeling the interior (mainly missing air vents on the dashboard, then I can add some detail on the tunnel and the back), and iron out some details on the exterior (properly plug the gaps here and there, refine some rough shapes, especially on the front grilles, and those pesky tail lights).

GodotInSim v1.5 is now available on GitHub.
It updates the AI control packets following the changes in LFS 0.7F5.

You can also check out this very serious project using those packets and a custom mod.

Having that IS_RAI definitely makes sense, instead of having to poll the state manually.

Regarding the gear error, I can get the "Avoided GEAR_REVERSE" and "Avoided GEAR_FIRST" messages in my own car, with a sequential gearbox, by staying in neutral, not pressing the clutch, and quickly pressing shift up and then shift down while still holding shift up (and the other way around for the other message); I have never encountered such messages in other situations though.

Scawen was quick to release 0.7F4, so I made the "final" version:

The indicators are blinking to the beat, 2 columns use flash and do have some blinking artifacts, and there seem to be some wrong pixels here and there, but I won't worry about this, my main objective is complete

Quote from Scawen :

I suggest you could use a time like 10 (which is 0.1s) otherwise, if you use 0 for the Time value, you are just telling it to hold the lever on full time and it's doing what you are telling it to do.

My bad, you're right and I was just misusing the time parameter, the documentation is fine as it did mention a short time was needed.

No more issues or further comments on my end then

I just noticed an issue, it seems like CS_CHUP, CS_CHDN and CS_FLASH get "stuck", they only work once and never go back to zero, so I can't change gears anymore, and the high beam flash stays on indefinitely.

Other than that, AI flags work properly, I can disable autoclutch, and toggleable lights work fine too.

Edit: Actually it's a bit more complicated than that: if I send a 255, I can then have the AI downshift once more (but not upshift). When the AI stops and turns the engine off, I can here the wind blowing temporarily as it goes out of "sleep mode" whenever I give it its input again, but it keeps flashing and refusing to shift up.

Last edited by Bokujishin, Sat 25 Jan 2025, 21:07.

I used the new AI control feature from version 0.7F2 to make this very important thing

I made a light strip object with 7 lights: rear fog, front fog, left indicator, extra light, right indicator, flash/high beam, and low beam (combined with side lights). I don't think it's possible to have more than these and retain independent control of individual lights (which is why I combined low beam and sidelights). Then I placed 20 of those objects to make a 14x10 screen, and animate the individual lights from the video.

It's a bit buggy right now, as fog lights and the extra light can only be toggled and not set on or off, and indicators have a fixed blinking pattern, which means they may be off when they should be on, so I have them turn off every 0.4s and the next video frame is supposed to turn them back on (I tried to synchronize with the music BPM). Plus I have a "loose pixel" issue where some of them get flipped at some random point.

I think I'll wait for 0.7F4 if Scawen does add the ability to specifically turn lights on/off, so I can fix my issue, and then post a video of the result. In the mean time, here's a screenshot of a random frame.

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, Fri 24 Jan 2025, 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, Thu 23 Jan 2025, 18:44.