Hi Scawen! Do you planing to increase the objects limit in the LFS Editor in game, now we have 3k limit , any chance to increase it ??

No need for rain for now, only a track editor. Create your own fork of "Historic Lemans". From my point of view, we need a track editor, you need to create a thread with a proof of your work and only the developer can add the track to the official lfs release.

Alright, time to announce a new project with GodotInSim: GIS Hub (as in GodotInSim Hub).

This is an application, built on GodotInSim of course, that aims to become a small ecosystem, an InSim manager if you will; you get a GUI with tabs, where each tab corresponds to an InSim module, and therefore each module can provide its own user interface based on Godot Control nodes, as well as its own logic, based on a packet subscription system: modules initialize by telling the hub which packets they want to handle, and optionally which packets they want to ignore. They can also request notifications for packets sent by other modules, as well as the list of active modules.

As a bonus, all modules share the same InSim connection, so it can be interesting to make modules more specialized instead of having a very broad scope, without risking going over the maximum 8 connections LFS supports.

The idea here is to allow multiple people (or myself ) to work on smaller-scale projects, and potentially use functionality from other modules where it makes sense (although I hope this won't make dependencies too big of an issue).

To allow for a single InSim connection, I start a separate instance of the app, create a TCP server on it (default port 29990), and connect the hub to it. The server connects to InSim and relays packets to and from the hub, which then dispatches them to the modules.

Since each module only needs to implement a few GISModule functions, but is completely free otherwise, you can even manage your own InSim connection if you want to bypass the server, while still being able to monitor other modules. OutSim and OutGauge, as well as InSimRelay, must be managed at the module level.

As a very quick example, here is a simple log module, which writes the contents of packets it receives, packets sent by other modules, and formats messages in a nicer way instead of the raw data: (yes, the messages are just tests and sent by the log module itself)


The InSim-managing server also includes a log, but writes it to a file instead, which means that even if the hub crashes because of a module error, packets keep being logged by the InSim connection, and the hub can reconnect to the server when restarted.

I am planning to make a few "core" modules, that would always be active, but other modules would be discovered at runtime and enabled or disabled dynamically by the user. Currently planned core modules include Hub functionality (general settings, InSim setup) and Player Management (UCID and PLID lists - this might be included in the Hub module instead), I am open to suggestions for additional core features (something that the vast majority of InSim apps could use). I will also try to convert my own projects to modules and distribute them along with this app.

Speaking of which: modules need to be exported as a Godot pck file (you need the Godot Editor for this), and placed in the modules folder next to the executable. The pck should be contained in a folder of the same name (modules/my_module/my_module.pck), to avoid conflicts in the filesystem after importing multiple modules.

Security: Modules have access to all Godot functionality, including potentially dangerous functions, like deleting files or simply executing any kind of code - you should only download pck files from trusted sources (ideally directly from the author's online code repository like GitHub or GitLab), and not from random people (that would be like launching .exe files random people send you).

GIS Hub features:

• Modular InSim application with a TCP server managing packet input/output to/from LFS
  
• Very basic crash protection for the InSim server, running in a separate process from the hub (does not prevent loss of functionality from the modules)
  
• Allows for cohabitation of many independent modules while "consuming" only one InSim connection
  
• Full InSim, OutSim, OutGauge and InSimRelay support on a per-module level
  
• Module communication: modules can request the list of active modules, as well as monitor packets sent by other modules
  

Planned core module features:

• (WIP) GIS Hub options, InSim setup
  
• (Planned) UCID and PLID management
  
• (Other) Open to more suggestions (for actual core features)
  

Planned modules:

• (Done) Packet logs
  
• (Planned) Message helper (write or copy/paste Unicode characters, change selected text's color, send as user or local message)
  
• (WIP) Telemetry
  
• (WIP) Race Stats
  
• (WIP) Lap Delta (a certain someone has been persistently asking for this since I showed a proof of concept last summer , even though other apps already do this)
  
• (Maybe) Setup Validation Tool (not sure it warrants a module as it does not actually use InSim (it would if setups could be sent via InSim), but why not)
  

I may also investigate the possibility of separating tabs into their own windows, so you can see multiple modules at the same time (e.g. minimap + telemetry + race stats).

I will probably repeat some of this, and include more details about actually creating modules, in a dedicated thread and in a link to the GitLab repository I'm hosting this on, once I have improved basic functionality and tested it properly.

Last edited by Bokujishin, Tue 11 Mar 2025, 16:49.

All that in lfs editor huge respect+1000 🥶

I think I can speak for the community, that these updates are a powerful reminder of how development should be done. Excellent documentation, your candor and realism at all angles is incredibly thoughtful and appreciated. Dedication to quality and making a working product is a dying art, and we only find it in awesome independent developers like you all.

We are so excited for the future of LFS, good on you dev team, keep up the good work, keep the faith, we are with you ❤️

ps: thank you for the modding system, it's truly a pleasure to be able to enjoy this and to be able to contribute to it. If we can see a track editor in the future, I know it's a lot of effort, but you can figure it out once you get time to sit down with the problem.

The juice is worth the squeeze, great updates, keep going 🔥

Quote from Mehmetgulec :

It looks really good, but the editor also needs improvements

While I am sure your suggestions are sensible, I am not working on the vehicle editor as part of this release. the idea is to get the new version released, so I then have time to work on other things including vehicle editor improvements. Please feel free to post vehicle editor suggestions in the correct forum section: https://www.lfs.net/forum/532

Quote from lfsrm :

Great read, I'm still oddly curious about how you are going to solve the cloud sustem for the new skybox, many racing sims completely miss the mark when it comes to the visual aspect of it.

The current plan is to avoid delaying the release for clouds. I love clouds and will miss them in the early versions of new LFS. But it's a big job with many technical difficulties and that's why there will be no clouds at first, although I do want to allow completely overcast (i.e. the whole sky is a cloud).

Quote from TheRubius192FE2 :

i think the dashboard is brighter than my future (joking but hope that it gets optimized)

It's a tricky issue at the moment and that is one thing lacking in the vehicle system at the moment. We really need some way to separate the parts of the dashboard that are illuminated by the environment (in traditional dashboards that are not just a computer screen) and the other parts that are self-illuminated like lights and the modern screens. I'm sure that in real life these modern screens must adjust their brightness a great deal depending on the lighting conditions, to be visible in the day but not completely blinding in the night. In some way, all our dashboards in LFS are self-illuminated like the modern computer screens, so I think they will have to start out light-sensitive and self-adjusting, even if that is unrealistic. Awaiting the more proper dashboard support mentioned above. I've probably not explained myself very well.

It looks really good, but the editor also needs improvements and I would say it is lacking even for this version.
_ALP indicator overlay is not allowed.
Indicator overlay maximum size 512x512
If it is possible for it to work, we should be offered this option
INDICATOR TYPE / Analogue or Digital
A 3D cursor for the analogue display to which a new add-on such as a slider, rotator, etc. can be added

This is the most common problem I encounter.
Wish you good work LFS Team

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 ]

Last edited by Scawen, Mon 10 Mar 2025, 19:14.

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

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.

Quote from emodel :

So a good, tweakable and adaptative AI as all I need.
Then, i guess, LFS is not the game for me, but the shame is, again, to me its perfection, and the sim i have most fun with, even with its flawed AI

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.

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).

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.

Quote from Evolution_R :

The model is now fully imported in LFSE.

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.

Quote from Evolution_R :

That's why it's important to read the "read me" files before doing anything.

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

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.

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.

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.

Quote :

Same for suspension... Frame and axles takes this job but in LFS it's perfectly stiff

As far as I know LFS does not simulate chassis flex.

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: 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, Fri 25 Apr 2025, 16:42.