i download the file lfs editor and its not work the file i download i cant open the file some idk what happen so if it can be fix can you fix this

First you need to allow slick tyres on the car. This can be done in the vehicle editor Allow tab.

Hello,
First of all, I would like to apologize for my poor English. I am from Poland. I have an S3 license and I use the Vehicle Editor add-on. I would like to be able to change the type of tires in cars. For example, to install slick tires on XFG. Is it possible?
Thanks, Dawid.

Day 6+

Premise:
Uploading exterior shell to LFS Editor.
Installed frame, engine, suspension, aero, lights, LOD2 & LOD3.
Still a lot of work to be done before release.

A big thank you to instasam for providing the headlight and taillight textures.
The car would not look nearly as good without the support.

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

Evening,

It may have taken longer than expected, but since my last post, a lot of inaccuracies have been found. I've been working on converting the Macan GTS to the 2020 model (for more accuracy) & fixing the inaccurate parts. also many improvements in roof, interior, and rear.

Physics update as well by RBunny (martin18). New Aero dynamics, Minor edit to frame, and lower center of gravity.



Here are some old/new pictures in both Blender and LFS Editor:
























Some comparisons:


Old:




New:






roof edit (windshield all the way to the rear wing):


Old:




New:





Thanks to RBunny (martin18) for helping me with finding & pointing out the inaccuracies in the model.

Last edited by M7md1467, Sat 7 Jun 2025, 18:16.

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

Thanks for the report.

It looks as if that has been the case for a long time, I think since before LFS editor was released.

EDIT: Correction, it looks like the change was September/October 2022. I think the setup storage changes were related to multithreading. So it probably did work correctly in the earliest public versions of LFS Editor.

Without much investigation, I don't think it should be like that, but on the other hand I think it doesn't really affect anything much (given the current limitations of LFS suspension physics). I think it was an unintended result of a change around the way the live setup is stored. I'll have a look to see if it can be corrected.

Last edited by Scawen, Thu 5 Jun 2025, 07:32.

try this https://www.h-schmidt.net/FloatConverter/IEEE754.html
it's 32bit IEEE-754 encoded decimal value.
ie. 0.05 = 0x3D4CCCCD (which stored as four bytes in little-endian way is CD CC 4C 3D).
ie. for you the relevant field on the web page is "Hexadecimal Representation" and swap bytes to get little-endian version (or check if your hexa editor can display/edit also 32bit values to let it do the split-to-bytes step)

Fixes for moving subobjects in Editor F9.

Thanks for the report and test data.

The problem was related to a movable subobject that was made invisible by configuration layers. Any subobjects later in the list would go wrong.

The problem was only in the recent editor and not in the public LFS.

The bug is now fixed in Editor F9. https://www.lfs.net/forum/thread/111321

Sometimes you get the opportunity to work on the project when you don't expect it. Such was the case here, as I had to spend a day at home, waiting for the watermeter to be replaced at essentially random time of that day. That at least gave me few extra hours of productive time I opted to use for further improving this mod.

Early on I tackled with the LOD2 and LOD3, as these were non-existent up to this point.
Shortly after that I completely reworked the tube mass model to get the accurate weight distribution of the vehicle.


Afterwards I had a thought about improving the quality of the wheel rims. These were extremely basic and initially I did not intend to work on them further, however I was in a mood of giving it some extra 20 minutes of care. Of course 4 hours later in the rabbit hole I ended up with completely remodelled rims. I'm actually quite proud of this though, I mean, have a look:

Initial version:

Reworked version:

IRL design:

I still have to play a bit with smoothing groups and mappings, but I gotta say it already looks pretty good.

Also tried to have some fun (with occasional desperation) in the engine editor, as I kept trying to perfectly match the irl engine specs. Sadly with the tools available I can only get it about 90% right, so some compromises had to be made.

Oh and I remodeled the steering wheel as well, so now it is much smoother with way more polygons.

One more version of the steering wheel is planned (movie car had different steering wheel compared to the original/displayed design). Should be a quick job though.

The to-do list is now getting very small, I believe by the end of the week I should be able to send the mod for manufacturer's approval.

Cheers!

OK, let's figure this out. For some reason the subobject you are trying to move has type "SLIDER" but the internal 'mover' that moves it has type "SPINNER".

But of course the mover should have acquired its type from the subobject it represents. So the question is why is that happening. Could it be you have reached a limit? How many moving subobjects do you have?

EDIT: Incidentally, object type 'spinner' was not working in the latest version of the editor (Test inputs) but I've fixed it now. But that is not related to Tuttu's bug.

Last edited by Scawen, Tue 3 Jun 2025, 13:58.

I modeled some exterior parts that weren't accurate or had missing details on the original Sketchfab model:
- Side vents behind the doors
- Side vents behind the rear windows
- License plate bezel (originally flat, I first reshaped it in LFS Editor time ago, then I now remade it again in Blender with better result)
- Resized, moved and fixed (I did properly align its vertexes in Blender) the front emblem
- Modeled panel gaps where missing (hood, trunk, front end, rear end, side trim, sideskirts)
- Fixed the design and proportions of the engine cover and (rear) hood

Been quite a while since the last progress report on this. Unfortunately I had to commit a portion of my available time to other projects of mine. Speedcubing, towerrunning, taking care of the family to name few... However occasionally here and there I did open up the editor and worked on this when the opportunity was there. Must be said that despite this mod being very close to the releasable state for some time already, the rabbit hole of continuously fixing and improving various stuff around the car is extremely deep. You fix one thing and in the process notice two other things that deserve attention or extra love. And the more you work on it, the longer the to-do list gets... But I now got to the point when I feel satisfied about the quality of this thing and I believe it could get submitted in a week or two.

Anyway, here is the list of most notable improvements I have done lately:

The dashboard is now completed, including fixes to the smoothing groups, better mappings, fixing holes and adding working light indicators for stuff like headlights, blinkers, handbrake, fuel warning, etc.


Added an optional rear lights mask that was use in the movie. It utilizes modified rear lights from Škoda 742, which I reused from the EMKO mod with Flame CZE's permission.


The car is now skinnable as well! This has been a painful process to get right from the very scratch, but all hard work around it is now done (phew...), with all maps properly aligned.



Last but not least I reworked the driver animation to fit the unique driving position this car has. One may wonder why making the skin would be the hardest part on this. Well, it wasn't... Now I honestly hate these animations with passion!


Aaaaanyway, that's it for now, in the upcoming week or two I only intend to fix few minor things before submitting this car to Škoda for approval. Afterwards this car will be ready for a slick review.

Maikl out.

Last edited by michal 1279, Thu 29 May 2025, 15:08. Reason : typos

Quote from Ibtasim6781 :

Been driving this car around a bit and I like it, but found a few issues...

Thank you for these suggestions for changes. I was already aware that there were things to be changed, but unfortunately, recently I haven't had time to play LFS, let alone mod it I plan to return to modding soon and fix the errors you mentioned, as well as many others (for example, the unrealistic suspension, or rather its absence). However, I will need more time for that because I lost the project files from the LFS Editor, so I will have to reassign the textures and so on from scratch.

Quote from Jake_Blasted :

Excited to see this project. Sure the guys would be happy to help you out if you...

Thank you very much, I will likely pop in that Discord because I have a couple questions. While I'm not new to LFS modding in general, I'm new to starting a car model from scratch in Blender. It's been quite the learning experience because I've only done some modeling & touch-ups in LFS Editor.

Progress has slowed down on this because of real life stuff, but I'm not stopping

Quote from MontxEsp :

Maybe they will include rain. When? Probably when Logan Sargeant wins an F1...

Considering a graphical and physics overhaul is already being developed, all we need next. Or atleast the next step Is to go for a Track Editor.

I'm not saying we'll be driving any licensed tracks, but the possibility to create new enviroments is good enough.

Its already being done with some mods, althought completely flat. Its just the next logical step.
Maybe turning already made popular layouts into actual fictional tracks

Fixed some bugs and issues in F7 game and editor, updated to F8.

Available on the same links in first post.

Since the previous report in March there have been various updates. Most of the time I have worked on LFS but also had to do a few things outside of LFS.

I'm not sure how interesting it is but I can look through the list of updates I sent to Eric and add a few comments.


Towards end of March:

I worked on the render modes, which were kind of a mess and it took a while to reorganise the code a bit.

In the end I came up with 3 render modes: basic / SDR / HDR:

- basic: straight to backbuffer, no antialiasing / exposure / tonemapping
(good for lower-end GPU, uses exposure estimate based on time of day - not good in tunnels or car parks)
- SDR: uses SDR render targets, does antialiasing and exposure, no bloom or tonemapping
(exposure calculation is good but there is no glow around lights and no tonemapping to help with bright sky)
- HDR: visually the same as recent versions but now adding bloom and tonemapping in a single pass
(our best option for good GPU but there is a hit from the bloom processing and HDR render targets)

New system for different settings between VR and non-VR modes

MSAA settings "none" and 2X options in addition to 4X and 8X

Started to work on the Public build of the new version and had to work on the track selection screen. The limits are worked out differently now so some changes had to be made to align paths with map images.


Early April:

Retro tyre model:
FIX: Retro model was heating up tyres too quickly in longitudinal skids
FIX: Retro model could cause a crash with wheelspin at low speed
Implemented skid darkness from New model into Retro model

Both tyre models:
Smoke update - calculated only immediately (without temperature build-up)
Doubled intensity of dust (from dusty surfaces)
Removed the "skin temperature" thin edge on outer surface as no longer needed

Render modes:
Code cleanup allowed only downsize as much as needed for exposure in SDR mode
FIX: screen was sometimes not cleared for a few frames e.g. after pressing V

Vehicle editor:
FIX: Z buffer was not disabled when drawing wheel cross-section
FIX: Tyre cross-section was not shown if Retro model selected

Cars:
LX6 - restored public version tyre size
LX4 - restored public version tyre size / mass / engine power


Towards mid-April:

Shaders:
New compute shader included [think this was for the exposure histogram]

Exposure:
Dashboard brightness now constant regardless of exposure
Avoided black frames when changing views with V or TAB in game
- the black frames were while exposure was calculated on a hidden image
- now the screen is simply not updated during those few frames
Reduced overexposure after TAB/V/restart from dark place (e.g. tunnel)
- initial exposure attempt was then worked out from a whited out image
- the overexposed image didn't show the true excessive brightness
- issues are solved by targeting a standard brightness (after TAB/V)
Exposure is also reset and recalculated when switching Render mode
Exposure is also reset on entering or leaving Free view mode
More accurate histogram (now 256 bins - see in CTRL+E)

Graphics:
FIX: Corrupted lighting (normals) on 3D spectators with scale > 1

Misc:
Faster load of Octree when track is loading
Added progress percent for "Generating" stage

AI:
FIX: Divide by zero updating path for AI in EV (e.g. Formula XR-E @ BL1)


Early May:

I had some distractions in the second half of April but in early May sent another update:

VR: Avoided black frames when tabbing between cars in "TV in VR" view
Avoid debug message about DEFAULT lighting when car drawn as physics LOD
Added Misc option to show ms/frame instead of FPS (removed SHIFT+F5 key)
OPT: avoided setting main render target multiple times per frame
FIX: avoiding mysterious crash in SetForce after losing full screen
OUT OF BOUNDS now displayed if the spawn point is out of bounds
OPT: improved main render function saving around 0.2 - 0.3 ms per frame
FIX: Jittery freeview camera (graphics now synchronised with physics)


Summary:

I'm not intending this to try to stir up conversations, but more to illustrate all the small things I have to work on, in order to get the version finished. Most of these things, you (and I too) probably wouldn't think of but it takes a while to get everything ready after so many changes have been made in the program.

D3D11, HDR graphics, dynamic lighting, 1000 Hz physics, shadow maps, multithreading, non-path-based occlusion culling have meant a lot of changes throughout the program and while trying to get things finished, I keep encountering new things that have not been considered, or were thought of as "fix that small thing near the end" but then it is a bit harder to fix than expected.


Ongoing:

I still have to do some more work for certain headlight issues, add some weather options, finish building a releasable public version and whatever comes up in the meantime.

Eric has been doing some more work on South City and has to complete Kyoto Ring where there are still some holes around.

We still can't give a time estimate, we'll just keep doing the important things until it's ready for testing.

“ NOTE: This version of the editor actually uses the "RETRO" tyre model”
I mean yeah, any reason why it wouldn’t use retro physics?🧐🧐

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.

Some people use LFS Editor to create the entire 3D model, others use Blender to create the 3D model, then export it as an OBJ file, which can be then imported into LFS Editor.

LFS Editor manual
LFS Editor video tutorials

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.