OK here's my new proposal for 12 (including sicotange suggestion)

SPACE
< > ^ v (triangles or arrows)
# @
: . ( )
SPARE


About tall objects and different concrete objects with tarmac surfaces, I have to put the brakes on because what happens is we are straying into track editor type territory. Things getting very big might start to mess up how the system works and we are just talking about a couple of days' update right now, not a big new project.

I realize this is something that has likely already crossed the dev's minds and potentially takes a whole lot of coding, but a tire grip multiplier would come in very, very handy. In the future maybe even some control over the slip curve?

When creating historic cars especially, i encounter issues where say an R3 or R4 tire would have the grip i would want from the car. But obviously it never switches on, especially on light cars with big tires. A tire grip multiplier would allow me to pick a softer compound and change its grip coefficient.

Then again, who knows what the new tire model will bring in terms of tire parameters.

EDIT: Just thought of another suggestion; an FFB force multiplier for the car within the editor context. Depending on suspension type, setup, the steering force differs a bit from car to car, which is how it should be. But there are some types of vehicles where this difference is very big, like for example karts. With the 250cc superkart i've made, i have to run the ffb force in game at around 40% to get the same amount of force out of the wheel as i would in other normal cars at 7-15%. It's about the same in other karts. A simple force multiplier that's assigned to the car would solve this issue.

Last edited by terga, Mon, 19 Dec 2022 13:37.

It would be nice if we would have like a little On/Off Menu, where the Modder can decide what part can be applied to the Mod (Bumpers, Window Tint, deleted Plate, Exhaust style and some other customizations), like a Tuning Menu. With 4 configs you come really fast to the limits, and you cant please everyone with 4 configs. Everybody could customize the car in their own Style

A perfect example would be the already existing On/Off Menu in the Editor, that Menu ingame would be a great addition.

Last edited by Fakeeexd, Mon, 19 Dec 2022 11:42.

Quote from Scawen :

Would the kerb objects like you see at Blackwood do the job?

This would be perfect as concrete-based kerbs are a real headache to get right (mostly due to placement and orientation limitations in the editor).

The time has come for this series to end, and so with it my 8 years here on LFS as I pursue conscription full-time now. Thank you everyone for the journey and for having a go at my creations just as I see them fit to be raced on my hundreds (of which I could never have thought would happen). NRGCL ends with 27 editions of layouts, some good, some bad, but all of which can be improved on. Don't let the editor cast doubt, it is capable of brilliant things as long as you have the mind to create

I leave behind one last gift to the community, Glendale. A V8 Supercars inspired circuit taking cues from many historical tracks from the land down under, a super driver's track making most use of LA1x's open space to instill some damn good flow into the 2 min lap time. A treat in the FXO Supercar, have a go at taming this rewarding street course.

Have fun all, and have a jolly, Merry Christmas.



Recommended vehicles
FXO Supercar by Nikopdr
FBM
Any other car!





⸗ The reward is in the passion

Check out my TC Layoutting series!
http://forum.city-driving.co.uk/forumdisplay.php?fid=13
https://www.youtube.com/watch?v=ONFy_8kqPj4

AA™| AOR Nova

Last edited by MicroSpecV, Sun, 3 Dec 2023 15:12.

LFS EDITOR Related.
When making the driver side switchable
The textures should flip to look properly specially when having a text.
This is done by either naming the mapping as U_Name or by duplicating the the mapping cutout and flipping it (flip button) and using it as an opposite side cutout for the same mapping.
However, non of these work on subobjects
It only work on Main object
Tested the previous methods dozen of times and it just wouldn't work as intended on a subobject.. Full flip & side swap won't help either.

Also, it seems like we can't put exhaust restrictions on setups inside LFS Editor aswell.. There's no option there.. Only inside lfs

Last edited by bayanofmansorofisky, Wed, 14 Dec 2022 09:00.

My mate converting an Iveco truck from box to platform with back mounted crane and since in unladen state rather large mass located at rearmost point it's intersting how it will behave at high speed (high for truck) so I want recreate it inside LFS.

Mass / Object Positions

Some heavy parts mass cannot be set in mass menu, while some of these are unsprung, at least for now only way to set them — tubes, so they will be sprung.

Plan is: place native mass objects, build frame with extra mass objects, make sure weight distribution corresponds to EUROCARGO ML180E25S specs, then add bed and crane.

Mass > Frame (literally)

First I went outside and take some measurements

then modeled frame and bed in CAD and calculated mass per metre to build frame in Vehicle Editor.

Truck frame (without bed and reinforcement for crane load) set to 1202kg.

Mass > Engine

LFS Editor assigns mass of 5883cc engine 294kg. Cummins ISB 5.9L mass is 520kg. So added 226kg, then gearbox 350kg and radiator 99kg.

Mass > Suspension

Front axle of similar capacity mass (with oil and brakes) is 316kg. Front axle set to 283kg.
Rear axle if similar capacity mass is 645kg. Rear axle set to 600kg.

Wheels

By the way, factory truck had all wheels 315/70R22.5 and factory floor had continuous transverse beams that lay on longtitual beams of subframe. But bed must be low as possible to fit taller payloads and for that reason decided to T-weld transverse beams and to use rear tyres with lower profile: 315/60R22.5.

LFS Editor sets mass of four wheels to 176 kg. Conditionally divided mass into six wheels — two front, four rear — about 30kg each.
315/70R22.5 tyre mass is 59.70 kg. 315/60R22.5 tyre mass is 58.42 kg. 9.00x22.5 rim mass is 44.03kg. So one wheel mass is about 100kg, therefore added 406kg proportionally.
Same with spare wheel, but since frame tubes can only be added symmetrically, as well as spare tyre itself can be placed only in center, so additional 44kg is halved.

Mass > Battery

Mass of one Promotive 680108100 — 45.1kg, truck has two. Native maximum 40 kg battery can be moved to the side, but additional 50kg is halved as well.

Wheels, spare wheel and battery additional mass is 500kg.

Cabin structure based on pic from Scania Truck Bodybuilder — Cab Structure (1038kg).

Truck chassis is 5315kg total. Compared to closest in mass Iveco chassis not more than 28kg discrepancy along the axes. It is acceptable.

• IRL — 3440kg (64.2%) front and 1920kg (35.8%) rear;
  
• LFS — 3423kg (64.4%) front and 1892kg (35.6%) rear,
  

So now can add bed and crane.

Mass > Bed

Truck chassis with bed mass is 6034kg (bed 719kg).

Mass > Crane

I made crane with "LFS tubes" model in CAD to make sure COG matches, was only necessary to finish moving parts, cause I've already made model of fixed parts (using drawing from palfinger.com and self measurements) to calculate reinforcements of the frame tail, but that's another story.

Crane 1758kg

Engine

Cummins 5.9L 24V (ISB).

Final drive

Gearbox ratios from ZF 6S800.

Mesh

Current exterior progress
I make cabin and dashboard in Blender as I like, not trying to copy any particular model, but I am inspired by various MAN and Scania trucks.

Last edited by Egor K, Sat, 17 Dec 2022 10:37.

Quote from MiniVan :

By far one of my favorite mods. Might I suggest a "top up" or "hard top" configuration.

If I had more skill with the editor I'd definitely consider it. It would have to have its own version, at least until we get more config slots.

Copy .veh file from LFS/mods/vehicles/ to lfseditor/data/veh folder.
Open LFSeditor,load the desired .veh file in Vehicle editor
Click "edit engine" on top right corner menu.

Did you read what was written about your mods?

You posted a mod as your own "original work" but it was actually downloaded from somewhere.
Another time you posted fake wip screenshots and again it was a ripped mod. Another time you gave wrong source for the model, maybe again to hide that it was a stolen model.

I am not sure if you have a problem with the english language or if you doing it on purpose.
Now remember that you are not the only one who does not understand licensing or decides to use a nice model from sketchfab despite that anyone can guess that it has been ripped.

Now you have this mod waiting for review:
https://www.lfs.net/forum/thread/101407-LANDLINE-RE34
but with your history and the fishy editor pictures, people do not believe you anymore. At the end you started posting in russian for some reason despite that you can write english.

Another 12 days have passed and some of you may be interested to read the log. The super short version is I've been fixing things, doing things that needed to be done, getting rid of lists of things to do. I'm trying to get all the important things out of the way ready to focus on tyre physics. Things that are less important, I plan to do after the release (apart from the odd thing here or there that I simply feel like doing).

The attached images show what tyre smoke looks like in a tunnel with and without a lightmap!


Log of changes:

Some small tasks to finish the delayed texture loading system
- updated per-frame task sequencer so if a car model was built a texture is not loaded
- renamed / reorganised some of the new functions to make more sense when reading code
- prevented delayed texture loading in modeller and vehicle editor (prefer instant)
- fixed single frame with headless driver standing up when exiting animation editor
- the option to switch between compressed and full skins now uses new reload system
- used MP replay to test switching between high and low resolution auto-download skins
- added critical section to make sure DDS saving cannot coincide with loading DDS skin

Spent a day on Fern Bay in the editor - various fixes (not creative work)
- unlike other tracks, Eric does not plan major Fern Bay updates in the near future
- there were shadow holes due to buildings and footbridges without top surfaces
- as an old favourite I wanted to see it in good condition suitable for release
- it's good for me to spend a little time in the track editor occasionally

Fixed minor issue: players joining in entry screen could trigger texture purge events
- host and guests did a quick load and delete of the new player's car to check setup
- as this car was loaded in "in-game" mode it would trigger a check for unused textures
- but cars no longer point to a setup in the player so this seemed to have no purpose
- so instead of preventing the cars triggering a texture purge, simply avoid this code

Off-topic interface update: Provide a left and right arrow for multi-state options
- it bugged me that to switch off replay saving I had to pass through an extra state
- now I can simply click left arrow to switch off saving / right arrow to enable
- the arrow button is greyed out if you reach the last option in that direction
- the 'greyed out' logic was easily applied to option slider bars so did that too
- tempting to do it for the integer nudge buttons but would have to change all calls
- too much to do so will forget that until the inconsistency bugs me in the future

Some development version updates
- new feature to help search for textures in the editor (in objects and world mappings)
- fixed system to load most recent version of a track for a lesson (not exact match)
- update to allow replays to load most recent version of a track (or currently loaded)
- fixed a thread protection notification exiting from editor using the window X button

Training lesson fixes
- fixed start time of training lessons which were always at midnight on 1 January 1601
- fixed some small issues around loading tracks that triggered thread warning messages
- fixed a "Game call from main thread" thread warning message during training lessons

General fixes
- fix for a thread protection notification when LFS does a full D3D recovery
(I have not seen a D3D recovery other than by deliberately forcing it to happen)

Fix for a problem noticed in MPR but would affect multiplayer generally
- symptom was a puff of smoke when clicking timeline to a certain point in the replay
- took a while to track down the cause (depended on where car was before fast forward)
- related to tyre's 'previous ground position' which is compared with current position
- this previous position was wrong if car was at a different angle before pos packet
- this has very minimal difference if pos packet is for a car that is currently viewed
- bigger difference if moving to a car that has not been viewed (physics not updated)
- solution is to get a good estimate for previous position using velocity and rotation
- testing shows that car velocity gives a good estimate so will leave out rotation now

The problem described above took me into angular momentum, rotation, position updates
- some things were still waiting since the 1000Hz updates (on my notes for months)
- now there is no sub-update, some things can be rearranged a little (for accuracy)
- a position accumulator is needed for low speeds (to avoid a 'minimum speed' issue)
- seems good to be pulling me back into physics as the tyre updates are waiting
- converted old variable FloatPos (was related to sub-updates) to position accumulator
- now super-slow speeds are possible and car cannot be stuck on 'digital rails' (xyz)

Have noticed an issue for some time - physics objects resisted starting to move
- seems to be related to 1000Hz update: object velocity not fast enough after 1 frame
- fixed by reducing the speed at which an object is considered to have started moving

Cleaned up code from recent changes / discarded finished notes / browsed old notes
- copied a few things from the old notes onto a short list of tasks to do for release
- although we are still a way from there I want to know what remains other than tyres
- random OT: made arrow keys work to move between options screens (seems like should)
- old notes reminded me that smoke particles do not pick up lighting from lightmap
- the lightmap stores info about artificial light and sky visibility, in an octree
- that means smoke looks black in the night and also too bright in tunnel during day
- made smoke particles read lightmap - see the attached images for before and after

To make mods, you need LFS Editor, which can be downloaded from the Downloads page. The 3D model itself can be modelled in another editor of your choice (e.g. Blender) which can then export an OBJ file and imported into LFS Editor. Or you can find a 3D model made by another author on the internet, but it has to have the correct license to be used in LFS and can't come from another game without permission.

Here is the manual page for LFS Editor, which contains more subsections about the editor, video tutorials, guides, FAQ etc.:

https://en.lfsmanual.net/wiki/LFS_Editor

Probably in the updated version of LFS, things will look like in the LFS Editor, so maybe it's a good idea to make the lights and other textures based on how they look in the editor, rather than in-current-game version.

My mods are a bit messy, because I did the opposite of what I just wrote. So when the new version is released I must update them all.

Last edited by Evolution_R, Mon, 28 Nov 2022 19:57.

Hi, i have same problem with editor.


I read the lfsmanual and i renamed the textures. I added .png and _ALP.png but nothing works. I should mention that the other 7 textures work after I changed the format from dds to png. These two don't work. Can someone help?

https://ibb.co/yWBrTBz

If you ask me, even S2 licence has enough tracks and cars. No one so far has mastered all of them, let alone S3 and introductions of mods where sky is the limit. The collection of very good mods will increase over time, as people get more familiar and comfortable with lfs editor. Your idea is nice, no question about that, just that Scawen has something else in mind. I think we should just let him do as he feels and great things will come for LFS.

Another week has passed and I've got rid of some more sheets of paper. The bulk of the work was allowing textures to be loaded gradually after the car's 3D model has been built. Initially it was necessary to allow number plates to be updated without rebuilding the car, for the case of a player changing their number plate while their car is on the track. Sounds obscure, but it was the last case of the car mesh being fully rebuilt while already in game. The trick was to keep a different slot for each player so the text on that slot could be updated at any time, so the number plate can change without the car model even being notified.

More obviously important was a system to allow the textures to be loaded in a delayed manner after the car mesh is built. In recent versions, a remote car's model is built only when the car comes into view, but there is a slight glitch at that point (as there always has been). I've now reduced that a lot by initially using existing special system textures for white skins and grey textures, if the texture isn't already in memory. Then the textures are loaded in subsequent frames, one by one. That doesn't take long so now if you see a white car, it won't be for long, and the glitches will be less than they were before.

It probably doesn't sound very exciting but to me it has been quite interesting to see cars loading quickly then their textures rapidly appearing over the next few frames. But I've changed it so when you load a car in the garage or click on someone's car in the game setup screen, it is always an instant load. Also when entering the game in single player or a replay the cars can be fully loaded before presenting the first frame. But for multiplayer we want to get in there as fast as possible as all connected players must be in sync. So in that case you can see cars appearing sequentially (nearest first) then all their textures are loaded and finally the number plates update. It's a better feeling than the long hold on a black screen when everyone has clicked ready.

It seems like most of my immediate notes are going to the paper recycling now. I have to do something to separate the light direction into a physical side (could be used e.g. for track temperatures) and a graphical side. In future that could relate to other weather features. Just like everything else, the physical side needs to be updated by game code and the graphical side will represent or approximate that visually.

A few other things to do and a few bugs to fix, to give me a clear head then maybe I can look at some tyre physics and reassess that, figure out what needs to be adjusted or finished to get nearer to the long awaited release.


Log of changes:

Improved editor colours when showing grids, pit zones, start positions, checkpoints
- makes it easier to find checkpoints as they need to be adjusted on all tracks

Reduced size of vertices sent to GPU by using more efficient storage for normals
- this helps memory bandwidth when drawing each frame and reduces memory usage

Adjustment to number plate system to allow plate to be updated without rebuilding car
- although a rare event this was the last remaining use of old car mesh rebuild system
- previously used to rebuild after a skin download or after pit-out glitch reduction
- now the text can be updated on the number plate texture without car being notified

System to delay loading textures all at once when the car model is built
- this is to replace the old pit-out glitch reduction that had to be removed
- it was never very nice as it resulted in white cars until your own car stopped
- new system creates texture objects in memory initially using a grey system texture
- after the car is loaded, every frame just one car texture is loaded (if not already)
- it was simple enough for the standard dds textures (but complicated a bit by mods)
- more confusing is the use of skins / skins_dds / skins_x / skins_y / mod skin folder
- the trick is to store all settings that control texture load, in the texture object
- changed the temporary texture for skins to white (looks better with user set colours)
- the temporary texture for all other textures remains grey which seems to work well
- number plate textures not updated until next frame after the last texture is loaded
- now car load, model build, texture loads, number plate creation all done separately

Fixed off topic bug: With some vehicles, exposure was noticeably wrong on entering game
- turned out that driver was not created in car setup but only when vehicle first drawn
- so eye position was not available in advance of first frame (used a default position)
- in some vehicles this could put the view in a dark place so exposure turned right up
- a result of exposure adjusting to output image + recent changes to car initialisation
- exposure usually adjusts gradually but it goes instantly to the first frame exposure

Back to the pit-out glitch, the worst remaining glitch is creation of the car model
- much reduced as it does not include loading textures (because of the recent changes)
- more of an issue could be when more than one car model is built in a graphical frame
- for instance turning last corner into pit straight, after some cars joined the race
- seems it should be possible to only allow creation of one car's model in any frame
- this would spread the stutter over a few long frames instead of one really long frame
- tested this by enabling it when entering game - cars appear one by one up the grid
- it's a good test - cars can appear individually then textures appear individually
- now the thing is to stop it happening at times like single player grid or in garage
- nice for me to see the delayed load but it's better not to see that when not needed

Last edited by Scawen, Thu, 24 Nov 2022 21:30. Reason : correction - the white and grey textures already exist (are not loaded)

Work in progress screenshots from the editor

Do I read that right:
The editor already has support for material types that do not work ingame yet?

Is that a steering wheel claw thingy?

Yeah, I always wondered how Eric or Scawen made all the tracks and cars back in the past. The answer is simple - Scawen made the car and track editors first. We are lucky that he decided to upgrate car editor a little bit and publish it. Same thing might happen for track editor as well. What I'm afraid of is that many moons may pass before we see someone make a track that is anywhere near as good as the LFS tracks..

I assume that is just the track editor interface used by Eric - not intended to be released to the public.

I see screenshots of the track editor for the first time, user interface is looks to be a as thoughtful for the user as the lfs editor. Cant wait for this

Eleven days since the last report, here is some more progress. Not much on multithreading but a couple of thread-related bug fixes. This period started with some work on the skin downloads which now work more smoothly and with a smaller glitch when the texture is applied to the car.

More interesting was an increase in the number of available objects. I had to overcome a technical limitation that object indices were 16-bit numbers, for historical reasons, which meant there was a hard limit of 65536 objects in the world. Objects mainly include actual objects, track cross-sections (we call them simply 'sections') and the segments that link sections, with curves and surfaces. Also flags, marshals, trees, and abstract objects like cameras, start points, grids and pit zones count as objects too.

The new South City has been getting close to that limit and I wanted to add a few more, which were related to an improved way of timing laps. Now that timing can be done to an accuracy of 0.001 seconds, the old path-based timing really wasn't up to the task. The path nodes don't align perfectly with the visual finish line which could give some strange results if there was a photo finish. To be fair these new checkpoints would only add 20 or so objects to a track but when I mentioned them to Eric he did talk about the shortage of object slots and that's why I decided to get down and sort that out. Actually it turned out not to be too bad, as in recent years the obstacles preventing me from changing to 32-bit object indices have been removed. Primarily it was the old 'optimiser' data that switched on and off objects as you drove around the track. It was huge data but now we use an occlusion octree that works in a different way and does not store the indices of individual objects.

There is more explanation in the log below. To illustrate the checkpoints update I have attached 3 screenshots. Because timing no longer relies on paths, it is interesting to note that open configs can now naturally do lap timing even without custom checkpoints being added. Paths still have some advantages such as instantly updated race position list and the colour coding for other cars on the small map, and these functions still work on configurations that do have a path.


Log of changes:

Skin downloads are now converted to DDS and saved from the download thread
- this reduces a graphical glitch when a skin is loaded onto a remote car
- simplified some texture loading code that was mixed up with skin saving

Cleaned up more code around texture loading and skin downloading
- the car's model is no longer rebuilt after its skin is downloaded
- instead the car holds a placeholder skin which is replaced behind the scenes

Support for ALPHA in section ends (tracks are made of segments between cross sections)

Fixed crash bug in the unused texture removal system (could remove some still in use)

Noticed a thread-related bug to do with setting the exposure while restarting
- game code does an 'illegal' D3D call that can cause corruption

Separated "set up lighting" into physical and graphical sections to fix the bug
- considered that this section of code has not yet been separated properly
- the physical part should be done every physics frame (sun could affect physics)
- graphical part needs to be done every graphical frame (shader constants, etc)

Realised that Eric was spammed with too many code-related debug messages in editor
- added a debug level option so he can see more relevant but not excessive messages
- used special macros to simplify the adding of messages for 3 different debug levels
- searched for and updated around 600 debug messages to use the new switchable system
- removed obsolete messages, e.g. a config without a defined path is valid these days

Encountered a thread-related crash, again during restart (clash with drawing humans)

Fixed a zoom bug in one type of trackside TV camera (probably was there a long time)

Removed another thread warning message that appeared in track editor (on undo or load)

Made car ambient shadows, lightmap lighting and headlight effect work in track editor

Considered a new timing system that uses proper checkpoints like in the layout editor
- existing timing is based on path nodes and is misaligned with visible finish lines
- Eric mentioned a concern with the number of objects in map approaching a hard limit

Converted object indices to 32-bit to increase the number of objects that can be added
- previous 16-bit indices only allowed a maximum of 65536 objects to be added to a map
- number includes objects, buildings, cameras, track cross sections and segments, etc.
- in the past the occlusion data relied on object indices and took up a lot of memory
- now we have a totally different occlusion system that storage issue no longer exists
- it took only a bit more than a day to update the remaining object indices to 32-bit

Moved onto the new system that allows accurate alignment of checkpoints and finish line
- started by analysing all path nodes over marked track segments to detect checkpoints
- this produces many checkpoints, often duplicates, e.g. a finish line for every config
- the duplicate checkpoints are combined and config switches enable them appropriately
- this leaves fully working checkpoints that Eric can adjust to improve accuracy
- worked on the editor side of it (the checkpoints are a type of invisible object)
- on the driving side, checkpoint detection use existing code for layout checkpoints
- timing is no longer path-based but paths have uses, e.g. instant race position list
- interestingly open configs can now do timing even without adding custom checkpoints

Continued :
Another cool addition to this would also be the possibility to change roll centers on the car, I.E adjust the wishbones up and down by 10cm+/- to fine adjust setup, it's something you can do in the editor and I think it should be a option to have in the setup as well, it has quite a big impact on the way the cars handle, puts energy through the tires and how the chassis reacts to it.

When you install LFS on your computer it only allows you to use demo content until you unlock the licenced content with your account details.

Quote from https://www.lfs.net/agreement :

3.1 You may install LFS on 2 computers for your own use.
3.2 You will initially be able to unlock LFS 3 times. This allows you to unlock on two computers and keep one spare unlock.
3.3 We recognise that people may buy a new computer or reinstall their operating system from time to time. For this reason, we will automatically give you an extra spare unlock once a week (every friday morning), up to a maximum of having 2 spare unlocks available. The number of unlocks you have left can be found on your status page.

IIRC maximum number of unlocks was increased from 3 to 4 since the release of LFS Editor because that needs to be unlocked separately.

Hopefully this is detailed enough answer

Super! More rally cross tracks with soil, or cover concrete with soil in the auto editor)