Couldn't this be prevented by adding a good amount of damping in the end stop force? I have to admit I don't know how it's done in other software, but in LFS, reaching the end stop makes the wheel bounce sometimes pretty hard, and if the FFB tries to turn the wheel past the stop, the wheel will keep bouncing until you move it away (this can happen when stopped, typically in grass or gravel, with damaged suspension or maybe just on slopes, or when you spin the car and the wheel travels the whole range, especially on cars that have smaller wheel rotation).
Out of the game, the soft limit on my wheel (1080 degrees, configurable as with all direct drives) feels much better, it stops the wheel (maybe not as firmly as LFS does), but the force then feels like it wants the wheel to stay around the stop, instead of trying to push it away completely - I assume LFS applies a force directly proportional to how far the wheel is over the limit? Maybe a PID would help here?
Anyway that's probably slightly off topic here, but maybe food for thoughts later on.
Out of the game, the soft limit on my wheel (1080 degrees, configurable as with all direct drives) feels much better, it stops the wheel (maybe not as firmly as LFS does), but the force then feels like it wants the wheel to stay around the stop, instead of trying to push it away completely - I assume LFS applies a force directly proportional to how far the wheel is over the limit? Maybe a PID would help here?
Anyway that's probably slightly off topic here, but maybe food for thoughts later on.
FWIW, I experimented with using s_plate_alp for driver name and number decals - it's hacky at best, and I have only tried a single number/name combination, so I expect other values to break in one way or another.
You can see the explanation in this post about my Coil Cup mod, screenshots attached here as well.
Edit: Alternatively, having access to a transparent user texture would be nice, although I assume it would be a mess to have that in addition to skins.
You can see the explanation in this post about my Coil Cup mod, screenshots attached here as well.
Edit: Alternatively, having access to a transparent user texture would be nice, although I assume it would be a mess to have that in addition to skins.
Last edited by Bokujishin, .
I've been experimenting with driver name and number as window decals - unfortunately, the game does not allow adding those properly, so I made a hacky workaround using the s_plate_alp texture instead (which by the way, does not seem to allow specifying cutouts smaller than the texture? it stays locked at 128x32 for some reason, after I set it once, and won't change anymore even after restarting the editor).
This thing can only work if people use XX YYY as their license plate, where XX is a two-digit number, YYY is the driver's trigram, and adjusting relative positions with spaces (multiple spaces are needed to prevent unwanted bits from appearing).
I *may* keep this as a separate configuration (and will probably replace the "no window paint" version with this), but I would definitely prefer having a proper solution to this (user-configurable car number, driver name, possibly driver flag, available either in s_plate (and s_plate_alp) or a new special texture - bonus points for multi-driver, or at least having the texture change on driver swaps).
This thing can only work if people use XX YYY as their license plate, where XX is a two-digit number, YYY is the driver's trigram, and adjusting relative positions with spaces (multiple spaces are needed to prevent unwanted bits from appearing).
I *may* keep this as a separate configuration (and will probably replace the "no window paint" version with this), but I would definitely prefer having a proper solution to this (user-configurable car number, driver name, possibly driver flag, available either in s_plate (and s_plate_alp) or a new special texture - bonus points for multi-driver, or at least having the texture change on driver swaps).
Hey, thanks for the feedback! Regarding 1st gear, while I do agree it feels a bit too long, especially on race start, I am following the official specs of the real gearbox (reverse gear is even slightly longer...). You have to play with the clutch to get a good launch, but it tends to heat it up quite a bit.
Center of mass I recently moved up again a little bit as I had made it likely too low, although to be honest I do not know how high it should be - what I can say is I have not managed to roll the car on a flat straight, even with abrupt steering and playing with the brakes. However, it does indeed roll somewhat easily when going on kerbs. My main references for that behavior would be from videos of Jardier's Clio Cup season, there are 2 instances of a car flipping after being hit and turned almost 90 degrees by another car, even on a flat surface (Paul Ricard, but there's another instance at Eau Rouge, Spa), and Jardier himself had to ease the steering to avoid rolling after riding a kerb at Paul Ricard.
Also, another reason for higher CoM is to help the car go 3-wheel, but even as it is now it won't lift the rear as much as the real car.
I unfortunately have no proper reference for the turbo (what pressure I should put in LFS or how much it lags), I kept default settings here, I'll have another look at official documents to see if I can find something useful.
As for the sound, I must admit it's not really to my liking (not close enough to the real sound), I agree it could be a bit louder, I just hope it won't cause clipping if I do that.
Center of mass I recently moved up again a little bit as I had made it likely too low, although to be honest I do not know how high it should be - what I can say is I have not managed to roll the car on a flat straight, even with abrupt steering and playing with the brakes. However, it does indeed roll somewhat easily when going on kerbs. My main references for that behavior would be from videos of Jardier's Clio Cup season, there are 2 instances of a car flipping after being hit and turned almost 90 degrees by another car, even on a flat surface (Paul Ricard, but there's another instance at Eau Rouge, Spa), and Jardier himself had to ease the steering to avoid rolling after riding a kerb at Paul Ricard.
Also, another reason for higher CoM is to help the car go 3-wheel, but even as it is now it won't lift the rear as much as the real car.
I unfortunately have no proper reference for the turbo (what pressure I should put in LFS or how much it lags), I kept default settings here, I'll have another look at official documents to see if I can find something useful.
As for the sound, I must admit it's not really to my liking (not close enough to the real sound), I agree it could be a bit louder, I just hope it won't cause clipping if I do that.
Sorry but I will not add ABS to this car, as the Clio Cup does not have it - braking is challenging indeed, as the differential has low preload and almost no coast locking, so if you have trouble there, I would suggest lowering the brake strength and trying to move the brake balance instead. Or you can adjust the differential itself, but I chose values that try to approach the real car's behavior (you can definitely see them lock up in real life).
LAURENT COIL CUP
Vehicle mod: LAURENT COIL CUP
Details page: https://www.lfs.net/files/vehmods/DBF12E
SHORT DESCRIPTION:
COVER SCREENSHOT:
Details page: https://www.lfs.net/files/vehmods/DBF12E
SHORT DESCRIPTION:
COVER SCREENSHOT:
Thank you, it means a lot coming from you, as you make very high quality models yourself and especially very high quality textures 
plus all the tips you post as well.
Texturing is somewhat of my nemesis, I've never really had the knack for it, and that's probably why I tend to rely more on geometry, so I'll see how it goes - thank you for the advice! One thing that would definitely help with faking details with textures is normal mapping (it would be especially nice for grilles to make them less flat, but leather, alcantara and other materials would benefit as well, but I'll see what variable shine can do - I assume it's a specular map?).
Today I've also sent an update for review, the mod will be available to all since I have now fixed most issues and added more things in LOD1, and LOD2 has been overhauled (with 5.5k triangles, we'll see how this one goes). It remains WIP though as I still need to model the steering column, interior door panels, touch up on the dashboard, and detail the rear half of the interior.
After that, I plan to reorganize the model a bit (layers, subobjects, cutouts) in hopes of allowing for easier work on variants of the car - Cup is one thing, but RX and Rally5 versions are very close, then there's the road version, and I would also like to make the Rally3 version, so if I can keep a single model for all of those, that will help. All versions would be separate mods rather than configurations, though, as even RX and Rally5 have different masses and weight distributions, in addition to a slightly less powerful engine, and there's also the copilot for rally versions.
Bonus screenshots: finally started working on tail lights
this is how they look in the updated mod, still WIP but already better than what I had before.
plus all the tips you post as well.Texturing is somewhat of my nemesis, I've never really had the knack for it, and that's probably why I tend to rely more on geometry, so I'll see how it goes - thank you for the advice! One thing that would definitely help with faking details with textures is normal mapping (it would be especially nice for grilles to make them less flat, but leather, alcantara and other materials would benefit as well, but I'll see what variable shine can do - I assume it's a specular map?).
Today I've also sent an update for review, the mod will be available to all since I have now fixed most issues and added more things in LOD1, and LOD2 has been overhauled (with 5.5k triangles, we'll see how this one goes). It remains WIP though as I still need to model the steering column, interior door panels, touch up on the dashboard, and detail the rear half of the interior.
After that, I plan to reorganize the model a bit (layers, subobjects, cutouts) in hopes of allowing for easier work on variants of the car - Cup is one thing, but RX and Rally5 versions are very close, then there's the road version, and I would also like to make the Rally3 version, so if I can keep a single model for all of those, that will help. All versions would be separate mods rather than configurations, though, as even RX and Rally5 have different masses and weight distributions, in addition to a slightly less powerful engine, and there's also the copilot for rally versions.
Bonus screenshots: finally started working on tail lights
this is how they look in the updated mod, still WIP but already better than what I had before.
Last edited by Bokujishin, .
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?
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).
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).
Setup Validation Tool for limited setups
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).
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, .
(Technical) Implement Reverse Z Depth to decrease z-fighting visual glitches
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:
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.
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.
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, .
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.
I still have to model the ends of the dashboard on either side, and fix the transition from the dashboard itself to the vents.
User-settable name and number (s_name, s_number)
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.
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, .
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).
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.
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.
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
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
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.
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, .
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.
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.
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, .
FGED GREDG RDFGDR GSFDG