Hello LFS mods users.

We have allowed through review a few "track mods" which use an "object" mod to represent the scenery of a track.

A small central physics object (LOD2 or LOD3) is created and sits on the ground, while LOD1 represents the scenery. There was a problem with the scenery disappearing if the viewpoint was too far from the origin.

Mod creators were able to get around this by using a hacked LOD distance, but we don't want to allow such hacks. It's better to release a fix for the issue.

At the same time, I had a note on my list for the development version about a bad calculation for the view radius of some mod vehicles with subobjects (that has become a problem since the addition of moving subobjects).

Two of these track mods have been waiting to be published and it seemed a good idea to help them and solve the view radius problem at the same time.

Now, the distance from an object is calculated as the distance from the object's bounding sphere instead of the distance from the object centre, which solves the problem. It is impossible for a lower LOD to be selected if you are within the bounding sphere of LOD1.

If you would like to join a server that has a track mod, you should use the new test patch 0.7F7 (or later) available in the test patch forum:
https://www.lfs.net/forum/thread/110607

If you are developing a track mod you should use the new editor test patch 0.7F7 available in the mods forum:
https://www.lfs.net/forum/thread/111321

Future development possibilities:

The track mod support is not very good at this time. It is a bit obscure as a player needs to "drive" the track mod and it has to enter as a physics object and settle on the ground. Our mods system was obviously designed for vehicles only. It would be nice to properly support such objects in the future, for example:

1) A new object type "solid" or "track" which does not enter physics at all and cannot move
2) Increased number of collision triangles for unmovable objects
3) Place a track mod as a layout object instead of using a player slot and start position

Examples (1) and (2) look quite easy to add (in an incompatible version) while (3) is a lot more complicated.
There is no time to develop such features at the moment. I am just pointing out that there is a possible future for track mods that goes beyond this current minor improvement. Track mods might not have to be a whole track but could be a bridge, a podium, or some other type of stationary object.

Last edited by Scawen, Sat 10 May 2025, 17:16.

Hello Mod Creators,

Here is a PATCH for the LFS Editor. Editor 0.7F or later must already be installed!

This is not a thread for random requests regarding the mods system.
For mods suggestions, use the Mods System Suggestions forum section.

This editor patch is a minor update to help support "track mods" and includes a few fixes.


Changes in Editor F11:

FIX: wire overlay was not clearly visible especially in 2D views
32 layers are now available + scroll bar and option to show all


Changes in Editor F10:

FIX: Rear caster angle can now be set in the base default setup
FIX: Avoided the jaggies on generated sky texture near the horizon


Changes in Editor F9:

FIX: Error in moving subobjects after one made invisible by layers
FIX: Object type 'spinner' was not working in Editor F8 (Test inputs)
LX4 - restored public version tyre size / mass / engine power
LX6 - restored public version tyre size


Changes in Editor F8:

FIX: View radius was sometimes reduced unexpectedly in the vehicle editor


Changes in Editor F7:

Improved vehicle view radius calculation (bounding sphere)
- LFS can more accurately detect if a vehicle is currently visible

LOD distance refers to distance from bounding sphere instead of object centre
- previous version did not work well for large objects, e.g. "track mods"

NOTE: This version of the editor actually uses the "RETRO" tyre model
- this is not expected to result in any noticeable changes in the editor


DOWNLOAD:

LFS Editor PATCH 7F to 7F11 [If you already have LFS Editor 0.7F or later]
Editor 0.7F or later must already be installed!
https://www.lfs.net/file_lfs.php?name=LFS_EDITOR_PATCH_7F_TO_7F11.zip (1.6 MB)

Last edited by Scawen, Tue 10 Jun 2025, 15:07.

Thanks, I reproduced this and it does also occur in the new version.

I'll make a note to consider it but I guess not with high priority.

Does anyone know if wheels sometimes drop underground at these locations?

If someone could provide a very simple way to reproduce this (hopefully with a single object) then I could have a look to see if the same bug still exists in new LFS.

Thank you, we noticed this yesterday and Victor fixed it.

Maybe it could be:

The mods stored on the server and downloaded to LFS could be in an encrypted form that LFS game can read but LFS editor cannot read.

Then the only legitimate way to load things into your editor is by downloading the mod manually in editor form (not encrypted) via legitimate means, e.g. from mod's page when it allows derivatives, or direct from the author.

Problems with this:

1) All the mods currently on the server are in editor form and not ready to be downloaded in the proposed format. So a big switchover operation might be needed.

2) As mentioned before, this type of encryption, that anyone's S3 license can decrypt, can be easily cracked. Someone would release a decryption tool for encrypted mods, to convert game-ready mods into editor mods.

I don't know if this low level of security would be enough. It's not something I'll be doing in the near future though as you know what I am still working on.

I guess I'll have to go on thinking over time, as it appears the simple function is too controversial without other security measures, but those security measures are a much more complicated subject.

Maybe it's more like, the simple function should be in there, as a simple function and without its own security measures, but the protected model itself should be prevented from loading into the editor by unauthorised people.

But that is a whole new level of complication and I don't have any time to start trying to figure that out.

I also know in advance that is the least satisfying type of work, if I ever do it, I would have to work for many hours or days implementing things into the editor, the web server, the game, and all the while knowing that hackers will easily flip the switch, undo the encryption, etc. Setting out on a task that you know for certain will fail is never very enticing.

Quote from HOUSSEM.221B :

or it can be allowed only for mods that have "Derivatives are allowed : YES".

Quote from Egor K :

I agree with Houssem, although it's strange that this needs to be discussed at all.

This seems impractical, I'm just talking about a simple function to export an OBJ. I can't even start to think how the suggestion could be implemented, somehow with the Editor connected online and having knowledge of where every model came from, and even track that if they saved out and reloaded the model? It's not really possible, I think.

This is only about a simple export from the modeller. As far as I know, this is a common feature for 3D software and I'm not sure if LFS Editor should be different.

Quote from Egor K :

What you're saying is like: ‘lock pics are already available, so it's no big deal to leave home door unlocked’.

I'm interested to understand what is the main concern.

Of course, LFS models can already be easily saved for reload in LFS editor.

So what is the main worry, is it that people might rip LFS mods and use them in other games?
(Although they can do it anyway but the new feature would make it easier to save a clean model)

I've asked the mod reviewers about this but we didn't come to any strong conclusions.

I'd like to consider a simple (and limited) exporter to OBJ format, from LFS editor, that allows the plain grey model to be loaded into other 3D software.

It wouldn't export the mappings. Our type of mapping isn't supported in the OBJ format. Although I think it is possible (but not really easy to code) to export mapped models, there is no way to read LFS style mappings from an OBJ model. So from LFS editor point of view it's not worth coding to export with textures at this time.

Although I haven't looked in detail, I think it is simple enough to allow an OBJ export of the points, triangles and normals. I understand this could be useful and I wouldn't mind doing a few hours on that at some point.

So we are left with, what problems could arise? The only issue I see is that someone could load a mod in our editor and export the plain grey model, which might be a breach of someone's "no derivatives" license. The proposed export function just makes it easier to get a 3D model out from an LFS mod, to be used somewhere else. It doesn't really allow anything that wasn't possible anyway, just makes it easier.

You click the function on the left, then select the axis to assign it to.

E.g. want to assign steering wheel.
- click "Steer"
- move steering wheel so you see which axis is the steering wheel
- click that axis (on the right)

Maybe at some point I can summon the motivation to add a column to the table that allows individual ones to be deleted. Some investigation will be needed, for instance do all those duplicates refer to the same hotlap file (in which case only the table entries would be removed) or is the file itself duplicated (in which case each instance could have the full delete procedure).

Without knowledge of what happens behind the scenes, it looks like hours of investigation, webcoding and testing, so it's probably best for me not to stop the other things I am working on, unless at some point I experience a great feeling of motivation to go and work on LFSW code.

Thanks for the info. I guess maybe you had to delete them both and then re-upload?

I'll explain why I am saying that:

I uploaded a hotlap, but at first couldn't see how to delete it.

I had to click on "Racer details" and there is a list of hotlaps, including a 'Del' link.

But if I have a look at xolan1993's page, there is only one reference to the hotlap which is actually duplicated (BL historic / FO8). So I guess it may be impossible for him to delete only one instance of it?
https://www.lfsworld.net/?win=hotlaps&whichTab=details&racer=xolan1993

Maybe we need a delete button in the table where you can see the duplicates, which I could make available for your own hotlaps, and developers could delete any of them so I could easily respond if there is a duplicate in future. I guess this is the only way forward.

Seems you are determined to get me to look at this.


A user can delete a hotlap, can't they? So I wonder why they leave duplicates there.

Bug still exists for xolan1993:
BL2 / FO8: https://www.lfsworld.net/?win=hotlaps&whichTab=trackcharts&track=bl&car=FO8&config=historic

...and also for ignacio molina 1:33.95 (currently positions 101 to 108)
BL1 / XRG: https://www.lfsworld.net/?win=hotlaps&whichTab=trackcharts&track=bl&car=XRG&config=gp

...but duplicate hotlap has been deleted for Viper:
SO chicane / FO8: https://www.lfsworld.net/?win=hotlaps&whichTab=trackcharts&track=so&car=FO8&config=chicane



Maybe Viper deleted his duplicate hotlap?

I removed the link to the photo as it looked really dodgy and I didn't dare to click it.

Maybe you could have a read through instructions here:
https://en.lfsmanual.net/wiki/Options#Controls

If you still have a problem then maybe upload a picture using a legitimate image sharing site.

Quote from johneysvk :

...is deleting the duplicate entries manually an option maybe?

It could be, when I looked I saw the duplicate hotlap appeared to have a different id, so it should be possible to add a function to delete it, either by a developer or the user.

Is it possible for the user who uploaded it, to delete one of the duplicate hotlaps, or does it not work that way? I'm asking in case you can give me more insight, in case it might save me a few minutes driving and uploading hotlaps.

This thread is not really "General LFS Discussion".

In future please use a more appropriate location, such as the mods in development forum.

I'll close this thread now as it is not of general interest for the community.

Last edited by Scawen, Fri 4 Apr 2025, 10:05.

Although I realise a website bug is annoying, Victor isn't looking at it (it's his code) and I'm not sure it's worth my time to start trying to figure it out, if it's just an occasional hotlap that appears duplicated.

Unless it's more of a problem than I know?

On the other hand, if there is a known way to reproduce this then I could fix it. It's just really hard trying to debug something that happens very rarely, in someone else's code, with no known way to make the bug happen.

EDIT: I've fixed a bug in the calendar.

It was reporting the UTC time wrongly when hovering over the event start time.

Hopefully that should appear correctly now. You should see your local time displayed, and hovering should show the UTC time.

Last edited by Scawen, Tue 1 Apr 2025, 09:20.

For old versions (before the mods) we did release dedicated servers.

But the cracked LFS community running on a pirate master server had grown bigger than the legit community and we didn't earn enough money to live on, which obviously could be a problem in the end.

There was one solution, make something new (mods) and stop releasing the dedicated server software.

Is there a program file 7zr.exe in your LFS_EDITOR\bin folder?

I see the JGTC runs on the USA servers:
https://www.lfs.net/leagues/818/season/1146

And the GT3 Challenge:
https://www.lfs.net/leagues/815/season/1245

It does seem like there isn't enough activity in the USA despite us having a good setup there. LFS seems to be more popular in South America. Hopefully there will be a bit more activity when we release the new update.

It's just a command that doesn't do anything but remains local. It's in the same place that local commands are processed, and does not get sent to the server.

I guess it can be seen in one of the messages that is sent out via InSim so an external program could use it for any purpose.

Quote from Bokujishin :

I haven't looked into tonemappers in-depth, just enough to know the differences as a user, but I don't remember AgX being purple

I remembered wrong, it's sort of peachy.

This was the example page I saw, about half way down the page you can select the images and the AgX ones seem to be sort of pink or peachy.

https://kronnect.com/introducing-agx-tonemapper-in-beautify-3/

I'm not saying I've discounted it, just haven't studied it enough and these examples didn't encourage me.

Quote from Drifteris :

i noticed street lamps don't cast dynamic shadows inside the car (like sun does), is that for performance or will there be an option to have it?

Our system is really not set up for shadow maps from street lights, the street lights are really just a source for ambient lighting.

Quote from Flame CZE :

It seems like the LCD brightness got fixed too?

Maybe it's because at night, the inside of the tunnel is brighter than outside, whereas it's the other way round during the day?

Maybe interesting to know that there are two exposures going on.

Other than the image-based exposure that I have been talking about, there is also a calculation based on sun height and sky brightness, which can be used to produce a roughly suitable exposure level in an SDR mode that I am currently still supporting, that doesn't have bloom or analyse the image for exposure. That gives quite reasonable results in the day and might be a helpful option for people with a low powered GPU. That calculation is very simple and done every frame even in the HDR mode (HDR is not for HDR monitors, it's just that internally we process the image using a high dynamic range).

Anyway why I am talking about that, currently that is the value that is used to set the dashboard brightness. Without that, the dashboards were EXTREMELY bright in the night, so it was a quick fix at some point in the past. Anyway as discussed earlier, it's not working well and I might do something based on getting a lighting value from your car's environment map, to simulate a light sensor, or I may take a simpler approach (for now) and just set a direct value, so the dash appears just as it does in current public LFS. I am making decisions to get to release without getting hung up on details. That would be awaiting the better dashboard support where we could allow parts of the dashboard to be illuminated by the environment.

Quote from rane_nbg :

Exposure changes look quite fantastic now, so as illuminated displays.

I notice that color tone is slightly towards netral (cool) while previous it was more towards warmer tint. I know that this is during night time, but it's the same tunnel with the same light sources. Has anything else been changed with lighting?

White balance is also based on the time of day rather than the current image. Instead of trying to analyse the image for white balance, it's simpler just to take some good values for day and night. If I used the day white balance in the night, everything would look too yellow, as we are using realistic values for the street lights.

Quote from Bokujishin :

Thanks for the night version, really nice too!
You mentioned the sky not being pitch black because of the date, and while I'm not sure of the difference between France and the UK, I was still expecting something darker, but more to the point - I think there's a bit too much ambient light outside, I believe the buildings and even the road should look much darker even with the sky's current brightness and street lights.

Well here in England, we are quite far North so in May we have short nights and there is a bit of twilight at 3am. I could do a pitch black one but don't think it's really worth it at the moment, though I can make these videos quite quickly.

By the way, I have noticed your other posts. I have tried an ACES filmic shader, might show some comparison screenshots at some point, though personally I don't like it as reality doesn't look like a film, if you see what mean.

I haven't researched enough about AgX, the ones I found did look complicated and all the example shots I saw on the internet just looked like a purple version of the image, so I wasn't sold on the idea. But I'll probably follow your link to see if the simpler version you linked to is of reasonable complexity. At the moment I am using a simple Reinhard shader to reduce the sky whiting out.

I think the tunnel lighting is quite well balanced, compared with the street lighting. Eric has set the lighting values by observation, we haven't gone so detailed as to set watts or lumens per light. But you can judge for yourself in this similar video done in the night.

EDIT: This video time is 03:14 on 4 May so the sky is not pitch dark.

Last edited by Scawen, Sun 16 Mar 2025, 10:16.