Better Security Measures for LFS Mods
Currently, there is an issue that allows players to easily access and steal mods by navigating through the LFS folder on their computer. Though, to my knowledge, there is no way to export the meshes from the editor it still bothers me that there is a lack of security to the mods uploaded.
I suggest adding encryption to the mods, similar to that found in other games, making unauthorised access much harder. The implementation of encryption for mods uploaded would protect and safeguard the the property of the mod creators preserving their work and creativity as it would prevent other users to manipulate the content without permission.
I believe the implementation of this would build a bigger trust in the LFS community giving the confidence for users to upload knowing their content is safeguarded.
I suggest adding encryption to the mods, similar to that found in other games, making unauthorised access much harder. The implementation of encryption for mods uploaded would protect and safeguard the the property of the mod creators preserving their work and creativity as it would prevent other users to manipulate the content without permission.
I believe the implementation of this would build a bigger trust in the LFS community giving the confidence for users to upload knowing their content is safeguarded.
https://world.city-driving.co.uk/?page=stats&type=money
You know this connection. The first place and second place person are in the game 24/7. I don't understand who and why is playing so many games, but everything can be understood from this list.
I really don't understand either. I am a new player, but I do not enter the TC server and earn money. I just ride and get out. Apparently there are people who sold the game money and need real money or need a new S3 license. Why wouldn't they... You play games and they pay you ahahahah
I said it was my last post but this is the last one for sure
Now, I think these issues should be closed and LFS should continue to be developed. We are waiting for new test patches. (editor patches are of no use to me I don't understand vehicle mods )
You know this connection. The first place and second place person are in the game 24/7. I don't understand who and why is playing so many games, but everything can be understood from this list.
I really don't understand either. I am a new player, but I do not enter the TC server and earn money. I just ride and get out. Apparently there are people who sold the game money and need real money or need a new S3 license. Why wouldn't they... You play games and they pay you ahahahah
I said it was my last post but this is the last one for sure
Now, I think these issues should be closed and LFS should continue to be developed. We are waiting for new test patches. (editor patches are of no use to me
I don't understand vehicle mods )New Video: Wheel rims in the LFS Editor
Hello Mod Creators!
Here is a new video about rim profiles, different types of wheel and how to recreate realistic wheel rims in the LFS Editor.
Narrated by me, photos taken by Leo at Haynes Motor Museum.
Here is a new video about rim profiles, different types of wheel and how to recreate realistic wheel rims in the LFS Editor.
Narrated by me, photos taken by Leo at Haynes Motor Museum.
Škoda Favorit
A Czech low budget car from 90s...
I started to work on this car solely on purpose to improve my Blender skills and to learn the LFS vehicle editor.
It is my first attempt to create a mod so I actually don't know if I finish it or not.
I will try tho.
I started to work on this car solely on purpose to improve my Blender skills and to learn the LFS vehicle editor.
It is my first attempt to create a mod so I actually don't know if I finish it or not.
I will try tho.
See the note for E4:
"Prevents frequent excess reports for the same mod"
It soon becomes annoying and there is no reason to see the same message every time the same mod leaves the pits.
Maybe they were first submitted before Editor E5 was compulsory. Anyway, their creators (or should I say hackers) will soon receive a message that their mod (or should I say BMW) needs to be updated.
This is truly amazing, you are not alone with photogrammetry and creating a track with a height map, I have already tried to create my own version of the Chimay track. I have a few questions, I'm really interested in how you can get the scale correct with the height map. I know how to distort my mesh, but the scale is not correct relative to Z. You can recreate a Google Earth Pro copy from a photo or with Blender's GIS plugin. But with this method the route of the road is not correctly adjusted either ^^ The south of Belgium is entirely scanned by lidar, so I can create the Mariembourg Karting track, the Chimay & Mettet "Jules Tacheny" track . I'm thinking of 3 or 5 hill climbs near my house. I've had my project in mind for 5 years, it's crazy how connected we are all 
What the drone do you have? I've shared BeamNG screenshot, Terrain editor is funny to use
This can be useful : https://en.wikipedia.org/wiki/Euler_spiral that's how some road is created... Covadis for autocad can be usefull to understand how ingeneer create roads.
What the drone do you have? I've shared BeamNG screenshot, Terrain editor is funny to use
This can be useful : https://en.wikipedia.org/wiki/Euler_spiral that's how some road is created... Covadis for autocad can be usefull to understand how ingeneer create roads.
Last edited by NENE87, .
By the way, calculating normals on the CPU for flexible object is also the reason why the LFS driver objects (the human in the car) use a lot of CPU time and mod creators should switch on "Concealed driver" for any normal car, where you can't see the driver's body from far away. The helmet is drawn anyway (it's not flexible) and this setting is really important for CPU saving. Just don't set it for bikes and karts or FSAE (when you can see the driver's body even as you move away from the car).
EDIT: Talking about polygon people, and going way OT, but as I mentioned Hind, you can see a few pictures of the polygon people that I coded for the Hind simulator: (I didn't make the objects, but did the code and editor to animate them. EDIT2: and I did the animations too)
https://www.mobygames.com/game/620/hind/screenshots/dos/272951/
EDIT: Talking about polygon people, and going way OT, but as I mentioned Hind, you can see a few pictures of the polygon people that I coded for the Hind simulator: (I didn't make the objects, but did the code and editor to animate them. EDIT2: and I did the animations too
)https://www.mobygames.com/game/620/hind/screenshots/dos/272951/
Last edited by Scawen, .
OK, I'll describe that but first I will mention that saving is only in the graphical render code, not the physics.
The thing about tyres is as they are flexible objects, their vertices cannot simply reside on the graphics card memory. They must be calculated every frame and the vertices are sent from the CPU to the GPU each time. I had thought before the main cost was actually transferring the vertices to the graphics card, and calculating the normals of each vertex. But what I found was the worst part was calculating the colour of each vertex (according to its lighting condition and the sun highlight). This used a lot of integer maths and I found the CPU use was way less when I bypassed this function, returning a simple grey colour. So I set about converting it to floating point maths.
The general idea is that integer maths is good for adding and subtracting, but floating point is better when there is a lot of multiplying involved. There's some leftover integer maths in LFS left over from earlier times. Considering some of its code goes back around 30 years, when we had 486 processors, I worked at Digital Integration on the Hind Helicopter Simulator, Pentium was the latest super CPU and there were no 3D cards.
By converting to floating point I found it was instantly faster, so I changed the code some more so that the normals were calculated in floating point, actually borrowing some code from the development version, where this was done already.
In the development version, the tyre lighting is actually done on the GPU, based on material properties, but the vertex normals are still sent to the graphics card each frame. You can see it in the LFS Editor.
The older code (before Friday) had a lot of complicated stuff to avoid sending vertices if they were not needed. This was done by checking if a triangle faced the user's view before drawing it, then calculating vertices as needed. But that is way complicated. It's better, if possible to just calculate all the vertices then send them all, without jumping around between triangle and vertex code. But for quite a while the "avoid sending unnecessary vertices" was still winning. But eventually I got the vertex normal and lighting calculations fast enough that it was better to do it the simpler way and I saw best results in the profiler that way.
Unfortunately that work, that took most of a day, doesn't benefit the development version because it was already done in that version. In the D3D11 version with shadow maps, all triangles must be sent every time as they may be seen in a shadow map (drawn from sun direction viewpoint). So it was impossible in that version to avoid drawing the away-facing triangles. But in the development version there is code to only send one object's triangles to the GPU once each frame, even if it will be used in multiple shadow maps, main view, mirrors and stereoscopic images in that single frame.
But although it doesn't help the development version, we still have the current public version for some months ongoing, so I'm happy if it helps people racing on full grids and the helps the quality of broadcasts by saving a few percent of CPU each frame.
The thing about tyres is as they are flexible objects, their vertices cannot simply reside on the graphics card memory. They must be calculated every frame and the vertices are sent from the CPU to the GPU each time. I had thought before the main cost was actually transferring the vertices to the graphics card, and calculating the normals of each vertex. But what I found was the worst part was calculating the colour of each vertex (according to its lighting condition and the sun highlight). This used a lot of integer maths and I found the CPU use was way less when I bypassed this function, returning a simple grey colour. So I set about converting it to floating point maths.
The general idea is that integer maths is good for adding and subtracting, but floating point is better when there is a lot of multiplying involved. There's some leftover integer maths in LFS left over from earlier times. Considering some of its code goes back around 30 years, when we had 486 processors, I worked at Digital Integration on the Hind Helicopter Simulator, Pentium was the latest super CPU and there were no 3D cards.
By converting to floating point I found it was instantly faster, so I changed the code some more so that the normals were calculated in floating point, actually borrowing some code from the development version, where this was done already.
In the development version, the tyre lighting is actually done on the GPU, based on material properties, but the vertex normals are still sent to the graphics card each frame. You can see it in the LFS Editor.
The older code (before Friday) had a lot of complicated stuff to avoid sending vertices if they were not needed. This was done by checking if a triangle faced the user's view before drawing it, then calculating vertices as needed. But that is way complicated. It's better, if possible to just calculate all the vertices then send them all, without jumping around between triangle and vertex code. But for quite a while the "avoid sending unnecessary vertices" was still winning. But eventually I got the vertex normal and lighting calculations fast enough that it was better to do it the simpler way and I saw best results in the profiler that way.
Unfortunately that work, that took most of a day, doesn't benefit the development version because it was already done in that version. In the D3D11 version with shadow maps, all triangles must be sent every time as they may be seen in a shadow map (drawn from sun direction viewpoint). So it was impossible in that version to avoid drawing the away-facing triangles. But in the development version there is code to only send one object's triangles to the GPU once each frame, even if it will be used in multiple shadow maps, main view, mirrors and stereoscopic images in that single frame.
But although it doesn't help the development version, we still have the current public version for some months ongoing, so I'm happy if it helps people racing on full grids and the helps the quality of broadcasts by saving a few percent of CPU each frame.
Last edited by Scawen, .
Hello, it gives me the same error message, but my editor is on the latest version 0.7E, what can i do?
Maybe increase number of objects in autocross editor eg things like static vehicles, pit crew, ability to draw custom layouts like in blender
Sqlyzy, you can use LFS editor to add parts to the car and paint it. Find a sponsor, then you'll get S3 for free.
Yes, I agree a reduction in the limit shouldn't be done without public discussion and fair warning. And maybe shouldn't be done at all. Maybe 8192 isn't so bad. It's just something I want to think about a bit more.
I'm interested to understand more about the difficulties in creating a good LOD2. I imagine some different approaches, mainly based on either:
1) Reducing a copy of LOD1, or:
2) Building a low polygon model from scratch based on the points and mappings of LOD1.
I don't know if any simple editor tools might help a lot with the process.
I'm interested to understand more about the difficulties in creating a good LOD2. I imagine some different approaches, mainly based on either:
1) Reducing a copy of LOD1, or:
2) Building a low polygon model from scratch based on the points and mappings of LOD1.
I don't know if any simple editor tools might help a lot with the process.
Nope.
Just would be nice to have that feature in editor...
As mentioned in the first post, you don't *have* to do an intermediate LOD. Better have only two LODs than a bad intermediate LOD. Of course, that's not really a finished mod. A finished mod has 3 LODs.
For examples of what I think LOD2 should be, please look at the official LFS cars supplied with the editor. In my opinion they should be somewhere in the region of around 1000 triangles.
It's not a huge task, compared with making a mod. It's just a simple model that will create a good shadow and look reasonable in the middle distance when LFS switches to the lower LOD mesh to save CPU and GPU time, to keep a good frame rate.
For examples of what I think LOD2 should be, please look at the official LFS cars supplied with the editor. In my opinion they should be somewhere in the region of around 1000 triangles.
It's not a huge task, compared with making a mod. It's just a simple model that will create a good shadow and look reasonable in the middle distance when LFS switches to the lower LOD mesh to save CPU and GPU time, to keep a good frame rate.
Im working to fix the cars that has bad LOD2 and rims they are moved to "saved" is there somehow i can download the original files from the forum? ( i dont have them in editor folder anymore bcs new pc )
I don't know if this is the place to talk about this topic, but there are a few things I observed. A program that has already been created. Before 7E was released, we were trying 2-3 test patches a day. This means that the developer team is careful not to deviate from the program. I don't want to sound knowing or claim that my thoughts are 100% correct. I'm just throwing out ideas. In my opinion, LFS's update plan will be to update the editor first. In every test patch, something about the editor is already shared. As for the graphics update. The developers know very well that it will not be difficult to add it day and night. I think they're adding something surprising. Like the weather... You may be wondering where I got this from. I've read articles where developers were inspired. There is a lot that can change or be updated before the chart or day and night. Of course, this requires time. Who wouldn't want to race at night....
Thank you, that is on topic, as I am trying to help get mods more optimal.
I'll have a look in the editor tomorrow and see if I can spot any issues.
I'll have a look in the editor tomorrow and see if I can spot any issues.
Hello Scawen,
I don't know if my concern belongs here but seeing "triangles", "stutter", etc. (otherwise I'd move it!). Yesterday we had a race with this mod (by the way very nice and very pleasant to drive!) : https://www.lfs.net/files/vehmods/2670D3.
I'm having major performance problems with it even though I have a very powerful computer (I don't master LFS Editor so I can't check what could be causing this problem).
In case it's on topic and can be optimized...
I don't know if my concern belongs here but seeing "triangles", "stutter", etc. (otherwise I'd move it!). Yesterday we had a race with this mod (by the way very nice and very pleasant to drive!) : https://www.lfs.net/files/vehmods/2670D3.
I'm having major performance problems with it even though I have a very powerful computer (I don't master LFS Editor so I can't check what could be causing this problem).
In case it's on topic and can be optimized...
Editor Patch E5 is now required to export mods for upload.
Changes in Editor E5:
Earlier versions can no longer be used for mod uploads
More updates and fixes for some of the official cars
Download: https://www.lfs.net/forum/thread/106792
Changes in Editor E5:
Earlier versions can no longer be used for mod uploads
More updates and fixes for some of the official cars
Download: https://www.lfs.net/forum/thread/106792
26-Jan thru 28-Jan
26-Jan thru 28-Jan
- Work is in progress to establish the interior. For now, reusing LFS assets for seats and steering wheel.
- Dash modeled from scratch in LFS editor.
- A starter dash clocks texture and map is in place. Some edits to do and need to fix mirroring when side switches.
-> Clock textures mapped to individual triangles on the dash.
- Work is in progress to establish the interior. For now, reusing LFS assets for seats and steering wheel.
- Dash modeled from scratch in LFS editor.
- A starter dash clocks texture and map is in place. Some edits to do and need to fix mirroring when side switches.
-> Clock textures mapped to individual triangles on the dash.
good choice to pick lfs vanilla car as a first mod. its better to experiment with lfs editor and all functions and stuff. nice sceenshots. keep it up!
A new update for the Editor, Test Patch E4, is available.
The official vehicles needed an update for the new rims and dashboard options. I've been through them all and added features to help in the rim editor and spoke editor.
Most notably, the rim guide now shows a complete minimal rim profile (not only the flange and seat). The "well" or "drop centre" is included, which can help guide you to make a realistic rim profile for your wheels. A well is required on all car wheels so that the tyre can be fitted. If there was no well, it would be impossible to get the tyre bead over the rim flange to mount on the wheel. The well is normally near the outer face of the wheel (the side that you see) but there is an option in the rim editor to move it inward for the case of "reverse mount" wheels, which are less common and require the tyre to be mounted from the back of the wheel. There is an option to move the well to the maximum extent allowed by the standards.
The LFS guide has been constructed to comply with the "J" rim profile that is most commonly used on road cars. It also adapts for bike rims, which have a smaller flange and a less deep, central well.
I have updated all the vehicles supplied in the editor, so you can see the alloy style rim profiles that I have updated to be more realistic than they were before. Compared with steel rims, alloys allow some flexibility in rim design but they must always include the J profile rim flange and well. So if you see any of the rim guide protruding from your wheel, you should probably adjust something.
Changes in Editor E4:
Rim editor:
A complete rim profile cross section is now shown
Options for rim guide well offset and reverse mount
Points are a different colour in surface mode
Protection against adding duplicate or opposite surfaces
FIX: + and - buttons did not instantly update the 3D model
Spoke editor:
A complete 3D rim profile is now shown
Separate show options for spoke / rim / tyre / guide
It is now possible to rename the first mapping in the list
A "rim" button is shown beside the first mapping (used for rim)
Misc:
A new set of vehicles is included with updated dash and wheels
Engine damage and shift light can be enabled in the dash editor
Download:
https://www.lfs.net/forum/thread/106792
The official vehicles needed an update for the new rims and dashboard options. I've been through them all and added features to help in the rim editor and spoke editor.
Most notably, the rim guide now shows a complete minimal rim profile (not only the flange and seat). The "well" or "drop centre" is included, which can help guide you to make a realistic rim profile for your wheels. A well is required on all car wheels so that the tyre can be fitted. If there was no well, it would be impossible to get the tyre bead over the rim flange to mount on the wheel. The well is normally near the outer face of the wheel (the side that you see) but there is an option in the rim editor to move it inward for the case of "reverse mount" wheels, which are less common and require the tyre to be mounted from the back of the wheel. There is an option to move the well to the maximum extent allowed by the standards.
The LFS guide has been constructed to comply with the "J" rim profile that is most commonly used on road cars. It also adapts for bike rims, which have a smaller flange and a less deep, central well.
I have updated all the vehicles supplied in the editor, so you can see the alloy style rim profiles that I have updated to be more realistic than they were before. Compared with steel rims, alloys allow some flexibility in rim design but they must always include the J profile rim flange and well. So if you see any of the rim guide protruding from your wheel, you should probably adjust something.
Changes in Editor E4:
Rim editor:
A complete rim profile cross section is now shown
Options for rim guide well offset and reverse mount
Points are a different colour in surface mode
Protection against adding duplicate or opposite surfaces
FIX: + and - buttons did not instantly update the 3D model
Spoke editor:
A complete 3D rim profile is now shown
Separate show options for spoke / rim / tyre / guide
It is now possible to rename the first mapping in the list
A "rim" button is shown beside the first mapping (used for rim)
Misc:
A new set of vehicles is included with updated dash and wheels
Engine damage and shift light can be enabled in the dash editor
Download:
https://www.lfs.net/forum/thread/106792
Layout Editor [maximum number of objects in the future]
Hi there!
I have a question abut maximum objects in Editor, now we have 3k objects limit, what is the maximum capabilities of LFS in objects number in the future? Sorry if this question was asked before, simply i cannot find the answear.
I have a question abut maximum objects in Editor, now we have 3k objects limit, what is the maximum capabilities of LFS in objects number in the future? Sorry if this question was asked before, simply i cannot find the answear.
Aerodynamics > Lift (Downforce)
Here's the tricky part, if stated downforce (200lbs or 890N) is correct for top speed of a serial car 221 mph or 98.8m/s, then by quadratic function at 150mph or 67.1m/s it will be 93lbs or 411N, which is 58% of the Initial target.
Perhaps downforce generated by fans reaches maximum already at 150 mph and does not increase further because their speed can be controlled by some program.Also print-out of tunnel 3/10 scale model run results is used as an illustration on Driving Ambition page 74, this one and above data summarized in table below.
Anyway, I see no reason to assign less downforce than planned, so 0.158 N @ m/s is chosen.
Aerodynamics > DragKnowing frontal area=1.79 m^2 and drag coefficient Cd=0.32 (ρ is air density) drag force can be calculated, so for V=67.1m/s (150mph) Fd=1580N.
To find body drag for LFS Editor divide drag force (1580N) by square of speed (V=67.1m/s)^2 = 0.351 N @ m/s.
But using this value LFS Estimated Maximum Speed Calculator (hereinafter — LFS.EMSC) indicates 373 km/h (232 mph), moreover acceleration from 255 to 350 takes 20 sec (16 sec IRL) and from 350 to 370 takes 20 sec again (8 sec IRL).
To match LFS.EMSC and Ehra-Lessien 391 km/h (243 mph) XP5 (experimental prototype number five) record run (not to be confused with official two-way average measured 386.7km/h or 240.3mph) body drag must be 0.304 N @ m/s.
Apart from fact that accelerating from 360 to 370km/h and from 370 to 380km/h takes one sec longer than IRL, even across Layout Square is not enough to reach 390km/h.
So 0.293 N @ m/s (LFS.EMSC 396 km/h) chosen because this body drag ensures acceleration coincides across all control ranges with deviation of less than a second.
Version 3 Aerodynamic changesreduced Body lift from –0.450 to –0.158 N @ 1 m/s
increased Body drag from 0.270 to 0.293 N @ 1 m/s
reduced Side drag from 0.600 to 0.586 N @ 1 m/s
Other changes in addition to those listed heregear ratios according to Autocar magazine: second from 2.21 to 2.19 and third from 1.68 to 1.71
final ratio from 2.99 to 3.03 to ensure maximum speed with
standard (7500rpm, 221mph, 356km/h)
"record" (8300rpm, 243mph, 391km/h)original starter sound from youtu.be/LSUvgTFp5Ts 0.740s (0.742s max)
original gear shift sound from youtu.be/KXihJTDSWb4 0.180s (0.184s max)
second (right) internal mirror disabled (not supported)
Thanks to Rony for helping me stop procrastination with improving the aerodynamics
Thanks to Martin because I had previously speculatively decided original tacho's four-digit readings must be too large to be readable on low resolution screen, but after he asked I tried and realized I was wrong.
Last edited by Egor K, .
Reason : "invisible" table reuploaded, listed additional changes
FGED GREDG RDFGDR GSFDG