So, will anything be added to the editor with the new update?
It's a completely new system with D3D11 graphics, dynamic lighting, 1000Hz physics, multithreading, dynamic echo rendering. It's not a thing you could release half of.
To be honest that would be a bit like going to your BMW dealer after hearing they are developing a completely new car, and saying, I have lots of money, can you at least sell me the seats, steering wheel and some suspension parts, it would be great, I can stick it in my existing BMW that is from an entirely different era, it'll be no problem.
In fact, the whole thing goes together and has to be in one piece.
[ EDIT:
In case my rubbish analogy makes no sense, I'll say it straight: The new tracks are constructed in a new editor, for a new version of LFS. They cannot be loaded into an old version of LFS that is completely incompatible. And the new lighting system cannot be released without updated tracks. Think of it more like LFS version 2, it's completely different.
Three more points:
1) Many, many, updates from the new version HAVE been copied into the old LFS, just look at the releases of the past few years with so many updates! It's funny how people forget how much has been done in the past few years.
2) The idea is that when the new version is finally released, updates can be done more easily because I don't have to copy the same updates into two different versions of LFS and development can be finally back on track.
3) This development is a huge part of my life. If you are desperate for it to be released, try multiplying that feeling by 1000x and then you may understand how important it is for me to get it released.
end of EDIT ]
To be honest that would be a bit like going to your BMW dealer after hearing they are developing a completely new car, and saying, I have lots of money, can you at least sell me the seats, steering wheel and some suspension parts, it would be great, I can stick it in my existing BMW that is from an entirely different era, it'll be no problem.
In fact, the whole thing goes together and has to be in one piece.
[ EDIT:
In case my rubbish analogy makes no sense, I'll say it straight: The new tracks are constructed in a new editor, for a new version of LFS. They cannot be loaded into an old version of LFS that is completely incompatible. And the new lighting system cannot be released without updated tracks. Think of it more like LFS version 2, it's completely different.
Three more points:
1) Many, many, updates from the new version HAVE been copied into the old LFS, just look at the releases of the past few years with so many updates! It's funny how people forget how much has been done in the past few years.
2) The idea is that when the new version is finally released, updates can be done more easily because I don't have to copy the same updates into two different versions of LFS and development can be finally back on track.
3) This development is a huge part of my life. If you are desperate for it to be released, try multiplying that feeling by 1000x and then you may understand how important it is for me to get it released.
end of EDIT ]
Last edited by Scawen, .
There is no plan to release track editor in the near future. It's kind of a long term dream of something that may or may not happen. It would probably be a year or two or more of work like the vehicle mods. It's difficult to even imagine how it could work and the tracks would be distributed. It can't work like the vehicle mods. Anyway, I say this not to start a discussion about the track editor, that I cannot get involved in at this time, but to make sure people don't have false hopes. I simply added a few more features to help Eric use the track editor, as I have been doing for the last 25 years or so.
I saw you saying "Track editor: minor usability improvements" does this mean we will have access to the track editor? As a map modder for gmod, id love to make tracks for lfs as well, im looking forward to it
Technical progress report, March 2025
Hello Racers,
We have been working hard to get LFS ready to release. As many of you know from a recent report I have incorporated the current public tyre physics into the new development version. We call it the Retro model. It's the same tyre physics but now at 1000Hz and with a self-aligning torque component that slightly improves the force feedback. The idea is to get the new graphics out without further delaying the release to await the new tyre model that is still unfinished. We also described how Eric has expanded Kyoto massively, in a way that reminds you of Westhill but with more roads and with its own character. South City is all opened up too. Eric has continued to work on South City and Kyoto.
On my side, since the start of February, it has been mainly technical work finishing loose ends from the graphical update. In a roughly chronological order, areas covered in early February include:
Force feedback (appropriate filtering to prevent spikes)
ABS (updated for 1000Hz physics updates)
Thread-related crash related to moving subobjects
Retro model updated to use new system for friction on various surfaces
AI - some bugs were present after reinstating the Retro model
Then something I found interesting that can be illustrated with screenshots. As we now use physically based rendering and high dynamic range, the exposure (brightness of the final image) has become an issue, just as it is in real life. The difference between light areas and dark areas can be quite extreme. For example if we used an exposure level suitable for outside on a sunny day, then the inside of a tunnel or a multi-storey car park would look extremely dark, even with artificial lights switched on. The exposure must be turned up in these cases and we do that by analysing the output image for brightness and constantly updating the exposure.
So far, so good, but it's a tricky thing to get right. In a typical in-car view there is the dark car interior, the bright sky, and the landscape you actually want to see. It's not good enough to take the average of the whole scene and adjust the exposure based on that. Certain areas are of interest and they need to be exposed correctly.
Two examples that produce the wrong result if we consider the whole image.
1) In an open wheel racing car, you can see so much of the sky that the exposure is reduced and the image becomes too dark.
2) In a car with restricted view of the sky and a dark interior, a lot of the image is dark and so the exposure is turned up too high.
In the FERA, an approved mod by CarlosSainz55, the overall image is quite dark so the exposure ends up too high for the scenery.
In the FOX, the overall image is bright so the exposure ends up too low.
I used a trick, to identify the scenery using the alpha channel. When rendering the sky (each frame) and the interior of your own car in a driving view, I made sure the alpha channel of the pixels was set to zero (like transparency). The alpha channel was set to not transparent when drawing the scenery. So the image that is read to create the histogram for the exposure calculation, looks a bit like this. The magenta indicates where the alpha channel is left at zero.
Now the exposure calculation can consider only the parts that are not transparent. The exposure in driving views and trackside cameras is far more usable and stable, no longer a problem and you are mostly unaware of exposure changes as you drive around. Exposure adjustments as you move into and out of darker places seem appropriate and helpful.
One thing on my list was Z-buffer issues, that I had noticed at Kyoto and have always been around, usually seen as flickering of two nearby surfaces when it's not clear to the graphics card which pixels are nearer to the viewpoint. I noticed a post by Bokujishin in which he mentioned the "Reversed-Z" method that can produce more accurate Z-buffer results with no loss of performance. It is a now well known method in which the Z buffer values go from 0 in the distance, to 1 at the near clipping plane, instead of the other way round. I tried a quick experiment that did show an improved Z-buffer and then spent a couple of days working it in properly and solving the bugs and issues that inevitably come up when you make such a change in a complex program.
While doing that, I learned about the infinite far plane, a slight change to the projection matrix that allows us to avoid cutting off pixels that are rendered beyond a certain distance, with barely any loss of Z buffer accuracy (that had already been massively improved by the Reversed-Z system). This seemed to me almost like magic, but I tried it out and it worked perfectly. It's not the usual thing to find a little code that simplifies things and provides a better result without any downside.
One of the issues that had come up when first implementing the Reversed-Z system was fog. The haze effect that helps create a sense of depth by including more of the sky colour as objects are further away. It didn't work at all but by a simple change I was able to restore a Z value to the shaders and fix the fog. But as usual, one thing leads to another and I started to look at an ongoing problem we had, with fog glowing in dark places. The short explanation is that our graphics engine doesn't really know which parts of the air are in sun or shade, so even when the camera exposure is turned up (in a tunnel or car park) the fog effect still appears as if you are looking through lit air. And as the exposure is up by such extreme values, the fog level then appears to be incredibly bright and it looks quite bad. A previous workaround had attempted to alleviate the issue by starting the fog only after a certain distance. But it wasn't a good fix: in a long tunnel you could see a 'fog line' moving down the tunnel 120 metres in front. This can be seen in the South City Work in Progress video made by Victor in 2021 (time 2:40).
120 metres was OK for car parks but not for tunnels. In the end we came up with a solution based on a comparison between the image-based exposure, and the predicted exposure if you were outside (based on a simple calculation). Now when the image-based exposure is much higher than the predicted exposure, the fog is turned down and this seems to solve the problem in a way that it it no longer perceptible as an issue. Glowing fog in dark places is no longer, while haze in open areas is unaffected.
Continuing work after that included:
Shadows: a useful optimisation and slight improvement in accuracy
VR: post-processing is now available and final image submitted as 32-bit
VR: fix for Vive Pro 2 and any other headsets with non-square pixels
Interface: shaders to show some interface elements in greyscale
Public version: Compiled public version exe for the first time
Track editor: Some minor usability improvements
Still to do:
Support for pop-up headlights and handlebar mounted headlights
- these currently are undetected and do not cast a beam
Headlight analysis to allow smaller headlights to be drawn more brightly
- currently intensity is constant so a large headlight appears brighter
Take more steps towards building an actual public version
- currently exe runs but can only get as far as track selection screen
Some amount of adjustable weather, e.g. overcast sky
- not supporting clouds for this version but some options are possible
When will it be released?
We still can't say. There are several things on our lists and new things keep popping up, so it's not possible to give an estimate.
We have been working hard to get LFS ready to release. As many of you know from a recent report I have incorporated the current public tyre physics into the new development version. We call it the Retro model. It's the same tyre physics but now at 1000Hz and with a self-aligning torque component that slightly improves the force feedback. The idea is to get the new graphics out without further delaying the release to await the new tyre model that is still unfinished. We also described how Eric has expanded Kyoto massively, in a way that reminds you of Westhill but with more roads and with its own character. South City is all opened up too. Eric has continued to work on South City and Kyoto.
On my side, since the start of February, it has been mainly technical work finishing loose ends from the graphical update. In a roughly chronological order, areas covered in early February include:
Force feedback (appropriate filtering to prevent spikes)
ABS (updated for 1000Hz physics updates)
Thread-related crash related to moving subobjects
Retro model updated to use new system for friction on various surfaces
AI - some bugs were present after reinstating the Retro model
Then something I found interesting that can be illustrated with screenshots. As we now use physically based rendering and high dynamic range, the exposure (brightness of the final image) has become an issue, just as it is in real life. The difference between light areas and dark areas can be quite extreme. For example if we used an exposure level suitable for outside on a sunny day, then the inside of a tunnel or a multi-storey car park would look extremely dark, even with artificial lights switched on. The exposure must be turned up in these cases and we do that by analysing the output image for brightness and constantly updating the exposure.
So far, so good, but it's a tricky thing to get right. In a typical in-car view there is the dark car interior, the bright sky, and the landscape you actually want to see. It's not good enough to take the average of the whole scene and adjust the exposure based on that. Certain areas are of interest and they need to be exposed correctly.
Two examples that produce the wrong result if we consider the whole image.
1) In an open wheel racing car, you can see so much of the sky that the exposure is reduced and the image becomes too dark.
2) In a car with restricted view of the sky and a dark interior, a lot of the image is dark and so the exposure is turned up too high.
In the FERA, an approved mod by CarlosSainz55, the overall image is quite dark so the exposure ends up too high for the scenery.
In the FOX, the overall image is bright so the exposure ends up too low.
I used a trick, to identify the scenery using the alpha channel. When rendering the sky (each frame) and the interior of your own car in a driving view, I made sure the alpha channel of the pixels was set to zero (like transparency). The alpha channel was set to not transparent when drawing the scenery. So the image that is read to create the histogram for the exposure calculation, looks a bit like this. The magenta indicates where the alpha channel is left at zero.
Now the exposure calculation can consider only the parts that are not transparent. The exposure in driving views and trackside cameras is far more usable and stable, no longer a problem and you are mostly unaware of exposure changes as you drive around. Exposure adjustments as you move into and out of darker places seem appropriate and helpful.
One thing on my list was Z-buffer issues, that I had noticed at Kyoto and have always been around, usually seen as flickering of two nearby surfaces when it's not clear to the graphics card which pixels are nearer to the viewpoint. I noticed a post by Bokujishin in which he mentioned the "Reversed-Z" method that can produce more accurate Z-buffer results with no loss of performance. It is a now well known method in which the Z buffer values go from 0 in the distance, to 1 at the near clipping plane, instead of the other way round. I tried a quick experiment that did show an improved Z-buffer and then spent a couple of days working it in properly and solving the bugs and issues that inevitably come up when you make such a change in a complex program.
While doing that, I learned about the infinite far plane, a slight change to the projection matrix that allows us to avoid cutting off pixels that are rendered beyond a certain distance, with barely any loss of Z buffer accuracy (that had already been massively improved by the Reversed-Z system). This seemed to me almost like magic, but I tried it out and it worked perfectly. It's not the usual thing to find a little code that simplifies things and provides a better result without any downside.
One of the issues that had come up when first implementing the Reversed-Z system was fog. The haze effect that helps create a sense of depth by including more of the sky colour as objects are further away. It didn't work at all but by a simple change I was able to restore a Z value to the shaders and fix the fog. But as usual, one thing leads to another and I started to look at an ongoing problem we had, with fog glowing in dark places. The short explanation is that our graphics engine doesn't really know which parts of the air are in sun or shade, so even when the camera exposure is turned up (in a tunnel or car park) the fog effect still appears as if you are looking through lit air. And as the exposure is up by such extreme values, the fog level then appears to be incredibly bright and it looks quite bad. A previous workaround had attempted to alleviate the issue by starting the fog only after a certain distance. But it wasn't a good fix: in a long tunnel you could see a 'fog line' moving down the tunnel 120 metres in front. This can be seen in the South City Work in Progress video made by Victor in 2021 (time 2:40).
120 metres was OK for car parks but not for tunnels. In the end we came up with a solution based on a comparison between the image-based exposure, and the predicted exposure if you were outside (based on a simple calculation). Now when the image-based exposure is much higher than the predicted exposure, the fog is turned down and this seems to solve the problem in a way that it it no longer perceptible as an issue. Glowing fog in dark places is no longer, while haze in open areas is unaffected.
Continuing work after that included:
Shadows: a useful optimisation and slight improvement in accuracy
VR: post-processing is now available and final image submitted as 32-bit
VR: fix for Vive Pro 2 and any other headsets with non-square pixels
Interface: shaders to show some interface elements in greyscale
Public version: Compiled public version exe for the first time
Track editor: Some minor usability improvements
Still to do:
Support for pop-up headlights and handlebar mounted headlights
- these currently are undetected and do not cast a beam
Headlight analysis to allow smaller headlights to be drawn more brightly
- currently intensity is constant so a large headlight appears brighter
Take more steps towards building an actual public version
- currently exe runs but can only get as far as track selection screen
Some amount of adjustable weather, e.g. overcast sky
- not supporting clouds for this version but some options are possible
When will it be released?
We still can't say. There are several things on our lists and new things keep popping up, so it's not possible to give an estimate.
Speaking of that, seeing as you have an S3 license you could use LFS Editor to increase power, reduce drag or add wider tyres to the AI cars possibly letting them have a bit better pace compared to player. It's sort of a bubblegum fix, pretty much have to give them more speed in the straights for them to gain the time back lost on corners.
They don't take the corners really well, i guess the AI is programmed to regain traction or not to go over it by any means, so they can't utilise any form of tyre slip, it is eliminated instantly instead.
Wild what the community can achieve once you grant them more access to some tools. LFS really needs a track editor tool, please. Let the community blossom!
I did not vote,but checked the car in garage and here's what's wrong from first glance:
- as many do,also you sinned in aerodynamics part - the car has such extremelly low drag,that it allows to exceed 400km/h (translating to your ancient units,that's 250mph),which is way past realistically possible for such car. Also you have added downforce,however I seriously doubt if a sedan type car generates anything more than the amount that counters car's natural lift from air that gets trapped in wheel arches.
- power seems to be higher than real world's counterpart has - quick research led me to 365kW max power available,however this depends if you're going for proper replica.
- also regarding quality - LOD2 has holes in model,probably looks very weird from distance,LOD3 seems to be autogenerated by editor,you should tweak it closer to actual form of body.
- as many do,also you sinned in aerodynamics part - the car has such extremelly low drag,that it allows to exceed 400km/h (translating to your ancient units,that's 250mph),which is way past realistically possible for such car. Also you have added downforce,however I seriously doubt if a sedan type car generates anything more than the amount that counters car's natural lift from air that gets trapped in wheel arches.
- power seems to be higher than real world's counterpart has - quick research led me to 365kW max power available,however this depends if you're going for proper replica.
- also regarding quality - LOD2 has holes in model,probably looks very weird from distance,LOD3 seems to be autogenerated by editor,you should tweak it closer to actual form of body.
Do you do the modeling through the editor?
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).
Hi! Yes i know it , but the problem is it should be from lfs editor level itself , like more objects etc. This is Plugin only.
im sorry, i have a silly question: doesn't this exceed the polygon limit on the lfs editor? if it does can you still submit it?
I don't think it's a bug, those higher numbers represent the output mesh.
Triangles should be relatively simple, I guess some of the ones you selected are mirrored, so the output number is more than you have selected.
Points are a bit more complicated and there will be multiple points where smoothing groups or mappings meet.
For instance a simple cube with one mapping would have 4 points per side, so there would be 24 points even through they are built on only 8 editor points. 3 points at each corner, which you can see if you turn on normals (nrm). Each output, game ready vertex can only belong to one mapping or have one normal.
Triangles should be relatively simple, I guess some of the ones you selected are mirrored, so the output number is more than you have selected.
Points are a bit more complicated and there will be multiple points where smoothing groups or mappings meet.
For instance a simple cube with one mapping would have 4 points per side, so there would be 24 points even through they are built on only 8 editor points. 3 points at each corner, which you can see if you turn on normals (nrm). Each output, game ready vertex can only belong to one mapping or have one normal.
Anyway, I'll try to post it, private mod, me and 2 other friends will use it. If it works out I'll be happy. However, there are several other mods that are available to the public that are "ripped" or conversions without credits or links. In this case I actually forgot to read the "read me", I was excited to do that and learn about LFS EDITOR
San-nin Z350 StreamOption (GT4 Option Stream 350Z bodykit)
Hello!!! I'm bringing my first import project to LFS EDITOR, I converted mods to old versions (vob mods) and after 6 years away from LFS I came back and wanted to bring my ideas and mods here, respecting the current mod rules!
In this mod I just used an interior that I had on my old HDD, the whole bodykit was taken from a mod from NFS MW, I just have the mod because it is free to download.
The wheels are from the XRT that I edited and looked the same as the original car, the textures are all from LFS itself (XR_Interior1, XF_Interior1, and others).
Check out images of the mod, from development and learning until it is completely finished and running on LFS.
In this mod I just used an interior that I had on my old HDD, the whole bodykit was taken from a mod from NFS MW, I just have the mod because it is free to download.
The wheels are from the XRT that I edited and looked the same as the original car, the textures are all from LFS itself (XR_Interior1, XF_Interior1, and others).
Check out images of the mod, from development and learning until it is completely finished and running on LFS.
Volvo 140 series (142)
So, I started to build one of my IRL cars in Blender back in August last year, done a couple hours here and there each day and ended up importing it into lfs editor and textured it and so on, so I feel like it is time to publish some work in progress pictures of it.
It is not ready YET for publishing, there is alot of work to do on it and I dont wanna stress the process.
My 3d modelling isn't perfect in any way
(Pre/Mid Facelift and trim) configurations. I might do a 1973-1974 facelift but thats not the focus right now and that someone else already made it for LFS.
All the textures used are shot by me.
What to do list.
*Work on the physics
*Topology, tris fix around wheelarches since its not looking well in LFS.
*Make 2 variations of rims
*Make mid facelift steering wheel
*Finish glass mesh
*Finish interior
*Finish chassi mesh
*Add sunvisor for rear window as a config
I'll just dump all of the pics that I got down below.
It is not ready YET for publishing, there is alot of work to do on it and I dont wanna stress the process.
My 3d modelling isn't perfect in any way
(Pre/Mid Facelift and trim) configurations. I might do a 1973-1974 facelift but thats not the focus right now and that someone else already made it for LFS.
All the textures used are shot by me.
What to do list.
*Work on the physics
*Topology, tris fix around wheelarches since its not looking well in LFS.
*Make 2 variations of rims
*Make mid facelift steering wheel
*Finish glass mesh
*Finish interior
*Finish chassi mesh
*Add sunvisor for rear window as a config
I'll just dump all of the pics that I got down below.
Isn't having no differential the same as having a locked diff? LFS Editor allows only locked diff if you choose the vehicle type as kart.
As far as I know LFS does not simulate chassis flex.
As far as I know LFS does not simulate chassis flex.
L.R.N (Live For Speed Rally Note)
Hi guys,
I'm working on a rally notes system, here is the preview in French.
I hope you'll like it.
The idea is to be able to edit the audio files yourself.
Each insim circle triggers the notes contained on the same line.
Example 0= 5 4 3 2 1 Go launches (5.mp3 4.mp3 3.mp3 2.mp3 1.mp3 Go.mp3)
The audio notes being contained in a text file.
Fix and update: 12_08_2025
#TIMER now from special.nt each timer is contained in this file.
#Each circle is now check line.
Update:
#TIMER is okay and can be restart from UI.py
Fix and update: 07_08_2025
Fix
#Some notes was not correctly positionate
#Most of objects touch ground now
Update
#Adding Road to stage
#Adding Service park
#Concatenate S1-RTS1-S2-RTS2-S3-RTS3-Service_PARK-RST0 in one file
#New UI design i put the image on attached file
Fix and update: 25_04_2025
update
# REFRESH LAYOUT, Special thanks to "papator"
Fix and update: 22_02_2025
FIX
# Now UI.py load config.ini file
UPDATE
# Up to 10 special in case of 4
# Change ratio of windows to A5 format
# Hide/Show list of special, when you choose special that hide the list
Fix and update: 16_02_2025
FIX
#CODRIVER HAVE ALL NOTES for these stages
UPDATE
#Update of UI
#Editor for Special
#New design for GUI
Fix and update: 15_02_2025
FIX
#More than one special
UPDATE
#First version of UI
#Activate or desactivate co driver
#creation of config.ini who contains path folder/speed codriver's voice(not create yet)/language (not create yet)
Fix and update: 29_01_2025
FIX
#Reduce some delay
#Remove circle_insim
UPDATE
#Add some notes
#Disance
#Wrong way is notified by codriver
#Add an insim button for restart special
I'm working on a rally notes system, here is the preview in French.
I hope you'll like it.
The idea is to be able to edit the audio files yourself.
Each insim circle triggers the notes contained on the same line.
Example 0= 5 4 3 2 1 Go launches (5.mp3 4.mp3 3.mp3 2.mp3 1.mp3 Go.mp3)
The audio notes being contained in a text file.
Fix and update: 12_08_2025
#TIMER now from special.nt each timer is contained in this file.
#Each circle is now check line.
Update:
#TIMER is okay and can be restart from UI.py
Fix and update: 07_08_2025
Fix
#Some notes was not correctly positionate
#Most of objects touch ground now
Update
#Adding Road to stage
#Adding Service park
#Concatenate S1-RTS1-S2-RTS2-S3-RTS3-Service_PARK-RST0 in one file
#New UI design i put the image on attached file
Fix and update: 25_04_2025
update
# REFRESH LAYOUT, Special thanks to "papator"
Fix and update: 22_02_2025
FIX
# Now UI.py load config.ini file
UPDATE
# Up to 10 special in case of 4
# Change ratio of windows to A5 format
# Hide/Show list of special, when you choose special that hide the list
Fix and update: 16_02_2025
FIX
#CODRIVER HAVE ALL NOTES for these stages
UPDATE
#Update of UI
#Editor for Special
#New design for GUI
Fix and update: 15_02_2025
FIX
#More than one special
UPDATE
#First version of UI
#Activate or desactivate co driver
#creation of config.ini who contains path folder/speed codriver's voice(not create yet)/language (not create yet)
Fix and update: 29_01_2025
FIX
#Reduce some delay
#Remove circle_insim
UPDATE
#Add some notes
#Disance
#Wrong way is notified by codriver
#Add an insim button for restart special
Last edited by NENE87, .
Karting
Hello fellow racers
So as far as I know the biggest thing lacking in the karts is the differential, I couldn’t find the thread on which I read this, but the reason for the karts handling being so weird is because it HAS a differential, whereas real life karts don’t (hence why you should always lean to the outside of the kart)
Not an expert on game development or anything but would it be difficult to add a feature to remove differentials in LFS editor?
Thank you
So as far as I know the biggest thing lacking in the karts is the differential, I couldn’t find the thread on which I read this, but the reason for the karts handling being so weird is because it HAS a differential, whereas real life karts don’t (hence why you should always lean to the outside of the kart)
Not an expert on game development or anything but would it be difficult to add a feature to remove differentials in LFS editor?
Thank you
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.
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, .
The mod system has its own separate section in the forum: https://www.lfs.net/forum/498-Vehicle-Mods-Forum
There is a thread for suggestions for the mod editor itself: https://www.lfs.net/forum/thread/100169
This suggestion (multiple engines in 1 mod) has already been written in that thread: https://www.lfs.net/forum/post/2053421#post2053421
There is a thread for suggestions for the mod editor itself: https://www.lfs.net/forum/thread/100169
This suggestion (multiple engines in 1 mod) has already been written in that thread: https://www.lfs.net/forum/post/2053421#post2053421
Different engines in configs option
Don't know if it would be accepted, but it would actually pretty nice if we could add in LFS editor different engines to different configs.
Day1
Day 1
I started with the basics, getting some references to start the dev of the mod.
Once i have enough information i started with the tyres dimensions and the wheel base to have a reference in the editor
Then start with the moddel in question
I started with the basics, getting some references to start the dev of the mod.
Once i have enough information i started with the tyres dimensions and the wheel base to have a reference in the editor
Then start with the moddel in question
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)
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)
Do you know if there is a way to achieve a similar effect with alpha textures? I tried it with a window glass texture but it only works in the editor
It would be cool to create a window glare / translucent glass effect.
Last edited by Flame CZE, .
FGED GREDG RDFGDR GSFDG