It appears legal, this guy make different models with blender, if you take a look here : https://assettocorsa.club/mods/auto/koenigsegg-one-1.html this is asseto corsa mod, there is not grid in front of the car modelized (in asseto)interior is not the same too, that's why it appears legal, if you want input this model in lfs, first you need reduce poly with decimate tools, or use this model for making your own, you have the shape etc, if the model is too close with the real car, maybe the car can't be accepted... After you need import object with lfs editor there is a complete tutorial here =>https://en.lfsmanual.net/wiki/LFS_Editor

I hope that can be help you

Last edited by NENE87, Tue 15 Aug 2023, 08:10.

One of the distinctive features of this car, and prominent for the in-car view, is the inset brake discs. I wanted to replicate the vented design (even though the drivers apparently didn't like them!).

I couldn't use the LFS editor discs because the 49's disc are inset too much (circa. 130mm front and 190mm rear) so I needed a solution.

This was before Scawen made the "Hub" sub-object available but I am glad I didn't have that option otherwise I wouldn't have found this ...

I defined the disc faces as "Brake" sub-objects which do not rotate - this may seem counter-intuitive but it means that I could use an image of a real disc with all it's reflections and shadows which would have looked wrong rotating. The illusion of rotating is provided by the ventilation holes which I defined in the wheel "Spoke" definition. The result looks really good in action!!



As I further develop the car I intend to redraw the ventilation holes as "Hub" sub-objects and also create a disc _ALP to allow a metal overlay so that the discs reflect the environment.

Improvement Suggestion
- A bigger range of movement for the disc offset (even though I didn't use them)

Quote from NENE87 :

What about this project?

Does the editor allow the use of existing UV maps, made in outside tools like Blender, to apply materials yet? If not, this remains stopped as I can't make it the quality I aspire to.

so, since tnis is an incopatible update, can we get westhill int. without chicane? jk

lovely, rim editor needed an update

Hello mod developers.

As many of you know, I am trying to get to a full version release so that all racers get the benefit of the recent updates, which I won't list here (you can read the first post of the editor test patch thread).

I noticed that some people, who want better looking wheels, have been using workarounds for deficiencies in the wheel rim system. So I really had to sort that out, even if it delays this full version release and my subsequent work on tyre physics. Sorry to the physics purists but I can't really leave the editor with such glaring issues. Wheel designs are very important and some people are putting a lot of effort into their mods. It's not good to have more and more mods with workarounds for a system that needs changing. So I have worked for a few weeks on this system for rim and wheel graphics.

Here I will list the updates and then post a few pictures:


The new lighting system affects both the rim and spoke objects. The lighting at each vertex depends on its depth in the wheel and the direction it faces, by an approximation system that is also affected by the "concealed wheels" setting (that makes it darker on the inside).

I think this ambient lighting should also be applied to any 'brake' or 'hub' objects that are found, because they are also within the wheel cylinder. But let me know if there are other uses for such objects, that mean the new lighting shouldn't be applied to them.

More notes:

I would advise mod makers not to use rim workarounds for now, as the auto repair is likely to affect the look of your work in the rim flange area. It's probably best to go along with the default LFS rims at the moment. If you do use workarounds, please be ready to fix your mods as soon as the update is released.

The update will be incompatible. Not for physical reasons, but simply because the file format is updated. That means, old LFS will no longer be able to load mods saved with the new version. There will be a test patch that can load the newly saved mods, of course. I will start a few test servers for people to test their mods, during the short period of time when the incompatible test patch is out and we are in final testing before the official update. I hope that period will be only around two weeks, to allow enough time for testing.

Always interesting to see how things go.

Any news on more objects and updates to the layout editor?

Looking forward to even more fun.

Quote from Aleksandr_124rus :

Im wondering what changes when i changed vehicle class from saloon to gt?
I test it and i dint noticed any changes, i hope its good.

Some editor updates ago it was changing available options of what u can put in the car, for now it's just gives category on mod list.

Hey.
In short - you can't directly edit them.

You can make and submit a derivative version if allowed by the author. If not - you can always ask the author for permission.
It's written in the mod description page under license type:
Derivatives are allowed: YES

or
Offline only:
You can locally edit the .veh file and use it offline only.
Example: go to LFS\mods\vehicles\BZ30 ROADSTER~034\ and copy BZ30 ROADSTER~034.veh into LFS_EDITOR\data\veh\ -> edit the .veh inside the Editor and save it -> copy that modified veh file and paste it in the LFS\mods\vehicles\BZ30 ROADSTER~034 folder replacing the original one. Always make a backup of the original file or just delete it and it will download it automatically if you want to use the mod online.

Last edited by Evolution_R, Tue 8 Aug 2023, 22:03.

There are two parts to making a dashboard. One part 'compulsory' and the other part optional.

The 'compulsory' part, edit the dashboard:

Vehicle editor
Textures tab
Select s_clock / s_clock_white / s_clock_formula
Click "EDIT" on the CLOCKS line
There are a lot of options

The optional part, create a dashboard back texture:

- backing texture appears *behind* needle, numbers, markings
- appears illuminated (self lit) like the default dashboards
- recommended texture size is 512 or 1024 for future-proofing
- load the texture in page mode in the modeller
- click the "fixed" button to mark it as "dash"
- there is a reload button in the dashboard editor
- alpha channel has no effect

There may be many tricks and tips but I guess from this point you will need to ask more specific questions.

Is there a line "Adapter Select" or "Output Select" in your cfg.txt?

Some more info here. I'm wondering if there could be something left over from your previous install. Or maybe you have reinstalled a new editor, so then there isn't much in your cfg.txt anyway.
https://www.lfs.net/forum/post/2051977#post2051977

I do think I need to include some extra error logging for startup issues, and have a note about that.

I have the same error, this is my deb.log file info:
Aug 05 13:37:04 LFS : 0.7C
Aug 05 13:37:04 timer resolution 1 ms
Aug 05 13:37:04 read config
Aug 05 13:37:04 get command line
Aug 05 13:37:04 preinit d3d
Aug 05 13:37:04 No modes found

i tried a lot of things but nothing works (LFS editor works while i had windows 8.1. Now i have windows 10, i dont know if that could be the problem.

I am really happy to see all the progress, and I really want our community to prosper. Thank you devs so far.

One personal suggestion (after getting old Westhill drivable first) is that now when South City has a huge expansion, we should also have a big number of official layouts. Instead of so1-so6 we should have like so1-so20. Basically I want this so that we would have green line in every single combo we are driving. Official layouts also make it possible to hotlap all. And it seems like we got more official content without using layout editor.

Resize everything down to 256x256 and inside the Dashboard editor in LFSLazy - X and Y positions to /2.

Or just update to 0.6U.

add the option to create 8 gear transmissions in LFS editor

Create a new subobject, position it near one of the wheels, set its object type to hub object. Then, when you exit to the vehicle editor, you should see it positioned at the wheel centre and it will move with the wheel.

Quote from Amynue :

Although, now I've also read the changelogs for the D33 (game) Test Patch and didn't see a mention of that change

You are right, there is barely a mention, I can't find it in the log either, just mentioned in this post.
https://www.lfs.net/forum/post/2049235#post2049235

I do recommend that mod creators should use the latest patch. I'm not like Microsoft. My updates contain many useful updates and more fixes than new bugs. Any new bugs are fixed extremely quickly, especially when there are more people testing.

I know it's not practical for everyone to get every update, but I'm sure it is best to keep up with the updates, which have been done with a lot of care and input from community members. Then there is no need to read such a long list that can leave your head spinning.

Quote from Amynue :

All I want to know is - why can't we have 65535 triangles in the main object, if that's the triangle limit for the whole mod?

There are different reasons for limits on points and triangles.

Triangles refer to points using 16 bit integers. 15 bits for the point ID and one bit to specify whether the referred point is the original or mirrored version of that point. So no point can have an index above 32767 (the maximum number represented in 15 bits). So that's the point limit. Sure we could make all objects use 32 bit integers instead and be bigger, but then the pit out glitch would be worse. Related to CPU usage when creating the in-game model from the 'editor model' stored in the veh. So limits are a good thing, in the context of a game. In this case that sensible limit happens to be around that point where we would need to switch to larger integers, so as there is a natural 'hard limit' there is little incentive to change the format at this time. Better if artists work within boundaries. As it's a game efficiency is important.

For triangles, the same limit does not actually apply in the same way, but the number of triangles is in the same region as the number of points, so the same limit seems to make sense. It is intended that mirrored triangles should be used as most vehicles are mainly symmetrical. There is a limit on output triangles of 65536 and I think the modeller limit of 32768 "original" triangles is to prevent this number being easily exceeded by mirroring all the original triangles.

If the maximum number of original triangles was increased, then the artist would be able to exceed 65536 easily (by mirroring all) and the game would simply not add them to the output mesh. This doesn't seem clean. Although I see there is a case where number of modeller triangle could be increased without exceeding the output limits (but not mirroring them all) this doesn't seem a high priority. These are very high numbers anyway, and it seems better for people to work within the limits (that already cause a disruptive pit-out glitch on some computers).

Quote from Avraham Vandezwin :

I don't know how Eric's current tool works, or what else needs to be developed to make it public. I'm not talking about complicating things to waste time.
In my opinion, a 3D track modelling algorithm and a few specific 3D object libraries would produce tracks faster than doing everything from scratch.
No matter the visual resemblance to reality. What matters is the quality of the track. In the track environments, there are always the same things (grass, pits, stands, etc.). A track is not a car . It is totally unnecessary to model everything every time. Having standard resizeable generic objects would suffice. And we would have quality tracks more quickly.

Of course the main thing is the layout and design of the track itself and reusing assets to a degree is a valid and widely used technique, but generic environments and reusing generic assets in the name of 'quickly' doesn't scream 'quality' to me to be honest.

Either way, i feel like track editor should be lower priority than more official LFS content and updating the existing content to a somewhat modern standard.

Quote from Avraham Vandezwin :

I don't know how Eric's current tool works, or what else needs to be developed to make it public. I'm not talking about complicating things to waste time.
In my opinion, a 3D track modelling algorithm and a few specific 3D object libraries would produce tracks faster than doing everything from scratch.
No matter the visual resemblance to reality. What matters is the quality of the track. In the track environments, there are always the same things (grass, pits, stands, etc.). A track is not a car . It is totally unnecessary to model everything every time. Having standard resizeable generic objects would suffice. And we would have quality tracks more quickly.

I'm sure the track editor has its own subobject system, after all you can see plenty of reoccuring objects across existing LFS environments.

Just a clarification for the 32768 thing. Usually one only has to model 1 half of the car and the other half is just a mirrored copy. A full car model has to fit into a 16bit integer. I guess that Scawen can make an option in LFS editor to enable/disable a planar symmetry with 32k limit. When disabled a 65k limit for the whole car would be allowed. I'm not using the editor so I may be wrong as this feature might already be implemented.

Last edited by rane_nbg, Wed 26 Jul 2023, 10:36.

Quote from Scawen :

That's all done and you should find it in the list of changes, there was a major overhaul for the clocks recently.

Oh... I've read all of the changelogs in the first post, but didn't see anything about it so I've assumed this hasn't been addressed. What I didn't think about, is to read the changelogs for the test patches of the game itself as this issue is related to the game rather than the editor My bad! Although, now I've also read the changelogs for the D33 (game) Test Patch and didn't see a mention of that change. Anyway... I've installed the D33 Test Patch and the needle indeed is in the same position for both speed units. Thank you! I will make another attempt at "horizontal speedo" for my next mod, which happens to also use such speedo.

Quote from rane_nbg :

I think he asks if there is any other technical limitation that LFS cannot handle 32-bit integers.

Thank you for the comprehensive answer, although I didn't understand much of it
All I want to know is - why can't we have 65535 triangles in the main object, if that's the triangle limit for the whole mod?

Quote from rane_nbg :

in LFS editor one should be able to play with 32-bit models and at the time of export make it into 16-bit, similar to how people do with car skins when they make them in 4096x4096 and then export to 1024 as a final skin for upload.

Yes

I wonder if there is any more info in the deb.log text file? I should probably add some more logged info for startup errors.

Could you try deleting (or renaming) the cfg.txt file? Then the editor will try to start up like a fresh installation.

Yeah, 16-bit unsigned integer, has a range 0-65535. I think he asks if there is any other technical limitation that LFS cannot handle 32-bit integers.

I'll try to answer. Well, most probably the reason is once you increase to 32-bit mesh models the frame rate will start to suffer greatly if you want to display all those polys with a full grid. So Scawen decided to make a compromise of good enough quality. But you have a very good point, in LFS editor one should be able to play with 32-bit models and at the time of export make it into 16-bit, similar to how people do with car skins when they make them in 4096x4096 and then export to 1024 as a final skin for upload.

On the subject of gauges...
I was trying to create a "horizontal speedometer" for one of my mods. When I was trying to calibrate it I've noticed that the speedometer needle position is slightly different in MPH mode than it is in KM/H mode.

Here you can see what happens when I switch between KM/H and MPH units in options:


It was impossible to calibrate it to show accurate speed for both the KM/H units users and the MPH users. Because of that, I decided to scrap it and went with a fictional digital gauge cluster.

Anyway, what I'm trying to say - it would be nice if the needle position was identical for both MPH and KM/H setting. This would be helpful when creating custom gauges. Ability to adjust the thickness of the needle would also be useful.



I also have a question regarding the Modeller - why are we able to only have 32768 triangles in the main object if the total triangle limit for the mod is 65535? Is it due to some technical limitation or... ?
It's especially annoying when importing from .obj file. I would like to be able import an .obj with - let's say - 62k triangles and then split some of it into subobjects from within the LFS Editor. Currently you have to use 3rd party 3D software to split it into two .obj files (below 32768 triangles). I would prefer to do this in the LFS Modeller.

It would be even better if we were able to import .obj files bigger than 65535 triangles. So, let's say - I import a 3D model with 75k triangles into the LFS Editor and then I delete some stuff that I won't need in LFS - for example the engine bay - to reduce the polycount to less than 65535.
LFS Editor should not allow to "Export mod for UPLOAD" if it exceeds the 65535 limit.

Hi, since i have updated my windows, lfs Editor don't open, and i have this error named "No modes found" every time i try to open it.

How should i fix it? Thanks.

I think it'll be a long time before we ever get realistic tracks with the track editor. Most mod tracks in other sims are just rips from other games which likely won't fly here.