Quote from r3zp3k7 :

Allow JPEG image formats for mod textures. Keep DDS conversation only on PNG textures (although I would also add PNG conversation to JPEG for non-ALP/non-transparent textures).

I've attached two files, both converted into DDS end up in the same 683KB size. You can check quality/size differences on websites like this one (was the 1st one I saw in the search console): https://www.diffchecker.com/image-compare/

PNG - 1355 KB
JPEG - 113 KB

Even if textures could download as jpg they would have to be converted to dds on arrival, as jpg takes a lot of CPU to extract each time, and doesn't contain mip maps etc, so there's quite a bit of processing to get them ready for realtime use. Basically for in-game use it must be a dds and must be saved locally that way, so it can be loaded and sent directly to the GPU without any conversion.

For your download comparison, the best thing to compare is a jpg vs a dds *after* it is compressed in a .7z file. DDS look a lot bigger than a JPG on disc but the DDS often compress well in a 7z file, so the download saving might not be as much as you think.

I don't mind being proved wrong - I'm just stating my current understanding of it, without doing any detailed analysis.

Quote from Aleksandr_124rus :

...maybe I need to do something differently but either I don't understand how it works, or it doesn't have a significant effect.

The NCL can only have an effect when used within the same smoothing group. In that case it will give a higher weighting to the triangles with the higher number. So it affects only the normals at the boundary between two normal contribution levels, within the same smoothing group. But across smoothing group boundaries, separate triangles do not contribute to the same normal anyway so then it has no effect.

But I wondered about the slight shading errors, and had a look in game and in editor. I tried "flat" view mode, because flat shading shows a good representation of the triangle normals, that produce the raw data for the vertex normals.

As you can see in flat shaded view, there is a sort of dent here (attached image). Because of how LFS works, that dent is the cause for the undesirable normals at that location.

I forgot to mention flat shaded mode. That is another thing that Eric uses a lot. I think that by moving vertices around a few mm here or there, the flat shaded model can display more consistent lighting and that will affect the vertex normals in a good way. I don't know if you can use the same thing in blender (I know blender supports non-triangle polygons so I don't know).

EDIT: I just remembered, sometimes triangle rotations can also have a quite a noticeable effect on the normals. I mean rotating two triangles within a quad (select 1 triangle, SHIFT+click the adjacent triangle). The LFS importer doesn't always make the best choice of triangle rotation when creating two triangles from a quad in the imported obj file.

Last edited by Scawen, Sat, 30 Mar 2024 14:39.

Quote from Aleksandr_124rus :

the shading algorithm always sets its own direction of normals. And it doesn't always look good. And I don't know how to deal with it. In blender the shading looks different than in LFS Editor, and in LFS game it is even more different.

I haven't seen the specific case you are talking about but there are some tricks you can use.

First to understand:

- the normals at a vertex are based on the directions of the connected triangles, within a smoothing group.
- the normal contributions are higher from the larger triangles meeting at that point.

You can adjust the normals in two main ways:

- extra triangles may sometimes be needed
- use "normal contribution level" (ncl)

I have a feeling that a lot of people don't know about normal contribution levels, although Eric uses them a lot. You can use it to increase the importance of some triangles, relative to others, regarding their contribution to normals.

Actually, triangles with ncl of zero will not affect the normal at all if there are triangles with a higher contribution level also connected to that point.

You can view and assign the ncl in a similar manner to smoothing groups.

I always imagined that type of central deadzone could be set in the controller's software, though I don't think I've ever tried. It seems like a memory from the distant past. Is that not the case, or at least not convenient?

EDIT: Maybe that's only in the Logitech software, but not e.g. Microsoft? Just speculating.
https://www.lfs.net/forum/post/1721869#post1721869

Last edited by Scawen, Sat, 30 Mar 2024 10:41.

And not only the interface, also the setup file format. Other things are already shoehorned in there. The 7th gear ratio is in a completely different position in the file, where it was queezed in to support the BF1 (I think).

So it's not an easy thing to add at this point, although it's an obvious thing to support. The larger setup file requires version support in the setup file reader, an adjustment to multiplayer packets and ability to read old MPRs with old style setups in them, etc. "Changing a number" is far from the reality. Better to do it at the same time as some other additions to the setup file.

Well that's just for interest and to explain why it's way too difficult to do right now.

My comment earlier was not in opposition to the suggestion, but about the statement that "the majority" of modern vehicles have 7 or more gears.

That statement seemed very unlikely, and I did ask if somehow this change in technology had passed me by unnoticed. I prefer suggestions to be based on reality rather than fiction.

EDIT: I think what I mean to say is I would prefer to be persuaded by calm reasoning rather than exaggeration.

Last edited by Scawen, Sat, 30 Mar 2024 14:44.

Sure but I have my doubts that 7,8,9 speed gearboxes are fitted to the majority of modern vehicles. I'm happy to be proved wrong though.
Until then I'll just go on believing that 5 and 6 speed are the usual thing.

Some of these suggestions are now done in Editor E7, including the new line guide as described.

Also a step towards being able to transfer selected triangles between subobjects. You can now merge a subobject into another subobject. So you could break off triangles from one subobject, into a temporary subobject, then merge that one into another subobject. I realise that sounds laborious but in some situations it could be more convenient than merging everything back to main object and breaking off again. Also, the eventual function to transfer triangles might well use an intermediate subobject invisibly, using this new function as part of the operation.

So I think it's an important new function and seems to work well as far as I have tested, but would like to hear if it works as expected for you.


Editor Patch E7:

Drag selection box:

Function to make drag box from points now available in points mode
Scale / rotate / shear axes are now hidden while making a drag box
Grey button shows drag info to avoid left buttons moving around

Typing individual values to align points:

ALT + click r/f/u numbers to set all selected points to same value
- relative values compared with last selected point not preserved

New modeller line guide:

Set up a trace then click "guide" to create a line guide
- the guide is visible in most editor modes and all views
- options to hide/show the guide or draw it open/closed

Merging subobjects:

You can now merge a subobject fully into another subobject
- this is a step towards moving a selection between subobjects
- triangles can now be transferred via an intermediate subobject

https://www.lfs.net/forum/thread/106792

Editor Patch E7:

Drag selection box:

Function to make drag box from points now available in points mode
Scale / rotate / shear axes are now hidden while making a drag box
Grey button shows drag info to avoid left buttons moving around

Typing individual values to align points:

ALT + click r/f/u numbers to set all selected points to same value
- relative values compared with last selected point not preserved

New modeller line guide:

Set up a trace then click "guide" to create a line guide
- the guide is visible in most editor modes and all views
- options to hide/show the guide or draw it open/closed

Merging subobjects:

You can now merge a subobject fully into another subobject
- this is a step towards moving a selection between subobjects
- triangles can now be transferred via an intermediate subobject

https://www.lfs.net/forum/thread/106792

Quote from dh7938726 :

As majority of modern vehicles carry 7 to 8 or even 9 speeds

I'd like to see the stats that bring you to this assertion!

In your third screenshot, if you press the pedals, do the axes (blue and yellow) move?

If they do then you just need to assign them to the correct input.

EDIT: I see your axes are set to "con botones" - it should be 'separate'.

Have you tried to setup according to the guide?
https://en.lfsmanual.net/wiki/Options#Controls

Hi, I see there were some threads in the 2023 forum section so I hope it's OK to create a thread here. If not, someone can delete it.

My question is about directions, I have a vague memory that last year one of the rounds (that I didn't enter) was run in both directions around the track. Is that happening this year, or maybe not now that the two races are of unequal length?

Thanks!

Thanks for that detailed description of the guide lines based on trace. I wonder if it could actually be initialised from a trace. I'm trying to keep the interface simple to implement. So you would make a trace then click a button to keep it as reference line data, until cleared.
[EDIT: I have done this now, works well - see attached image]

About the centering, I've thought more a bit today. I think a good way would be if I enabled ALT+click on the number (to the right of r/f/u buttons). Then the dialog that is initialised would be similar to the existing dialog but with some different text. And the outcome of that would be that all the selected points acquired that value.

So...

1) You could use that to achieve what you are saying, like this:
ALT+click the number. Enter 0.

2) You could make all points match the green point, like this:
ALT+click the number. Press enter.

3) Set all to some other value:
ALT+click the number. Enter a new number.


[I'm also looking back at the other suggestions]

Last edited by Scawen, Thu, 28 Mar 2024 18:31.

It's really not on topic as it's a completely different interface.

By the way, my own Xbox controller reports separate axes through Direct Input.

The problem you report is really a Microsoft bug.

I can't imagine that it would be easy to implement the new interface, maybe even impossible with the old compiler used for the public version. Anyway, it's a really big task and I'm 99% certain this will never be implemented into the old version of LFS.

Nice to see a dragster approved. I have an improvement suggestion.
In version 23, I believe the engine rotation direction is wrong. For nearly all RWD cars, when you blip the throttle, the left side should lift (car rocks clockwise from driver's viewpoint as engine revs increase).
This is confirmed at least in this video.
https://www.youtube.com/watch?v=ywDgpkWas8k

To fix: 'Object Positions' -> Rotation (from front) -> clockwise.

I want to have a day on the editor tomorrow.

Quote from bayanofmansorofisky :

Static Line : Draw a line either from selecting multiple points (as trace function) or hold and drag mouse. Similar to select box. But only its job is to give a guide line thats helpful to see tris edge, heading or pitch when in 2D view.

I am a bit tired now, but I'll ask you to make this clearer for me to understand.

Is it really something that behaves like the 2D drag box, only it is separate from that and doesn't select points? Can you write a bit more description and a couple of use cases so I can visualise it better?

Quote from bayanofmansorofisky :

Snap to : edit the existing button Center, but have an option to snap selected points to one of the axis, 0 the value of X, Y or Z
currently only available for X

I think I thought of something like this before, but more related to typing in a number for X, Y or Z. But instead of preserving all the points value relative to the green selected point, it would set all of those points to that exact value that you typed in.

If that makes sense, would it achieve what you are suggesting? I think your description is what I've said but you type in '0'.

Thanks, I decided not to add that one as it is not available in the new physics version.

Quote from racerss :

The range is not customizable also.

It's an interesting thought.

First to say that, apart from the bug that is now fixed, nothing has changed with the mouse axes. Their range can only be set by the multipliers on the right, and not by using numbers in the range columns that the other axes use.

But I'm wondering now if they should be changed to use the same system as the other axes, and delete the extra multipliers.

I don't really know why they are different, it's probably do do with the order of development back ion the past. But maybe they should be unified now, it might be quite simple. But maybe people are happy with the multipliers and I could just leave it.

Thanks, the invert mouse axis bug is fixed in E10:
https://www.lfs.net/forum/thread/106967

OK, in Test Patch E9 the in-game axes display now matches the the one in the controller screen.

The dead zones I described are included by default but are now user controllable.

https://www.lfs.net/forum/thread/106967

Test Patch E9 includes input range improvements:

The full resolution reported by the controller is now supported
- previously drivers were instructed to report -1000 to 1000
- controllers we tested report values 0 to 65535
- so steering wheel moves in smaller steps

The range adjusters in controller options now use percentage values
- the range defaults replicate previously default in-game behaviour
- previously brake/throttle/handbrake/clutch axes had a dead zone
- the dead zones were not adjustable by the user but now are
- the axes visible in game now match the options screen

Download: https://www.lfs.net/forum/thread/106967

Test Patch E9 includes updated controller support.

Changes in E9:

Input range improvements:

The full resolution reported by the controller is now supported
- previously drivers were instructed to report -1000 to 1000
- controllers we tested report values 0 to 65535
- so steering wheel moves in smaller steps
The range adjusters in controller options now use percentage values
- the range defaults replicate previously default in-game behaviour
- previously brake/throttle/handbrake/clutch axes had a dead zone
- the dead zones were not adjustable by the user but now are
- the axes visible in game now match the options screen

Support for mod approval:

WIP filter is available on the mod selection screen

Translations:

More translations updated! Thanks to the translators

Download: https://www.lfs.net/forum/thread/106967

That could be the case if a position packet from the pink car was delayed, so the instance of that car on your computer still hadn't put its brakes on, even though that driver did use the brakes in reality.

I'm trying to get the patch completed. I had hope the weekend before last, then last weekend. But I had to work on website for a couple of weeks. Now I'm trying to get the last LFS fixes done. So I hope in a week or two.

There's no point asking me for an ETA really. I'm working as fast as possible and every time I give an ETA, it doesn't happen because there;s always more stuff happening that means I can't do my work.

Quote from subUwU :

I recently went on the forum to check out new activities and was upset because of some particular threads that had disrespectful and hate comments towards the developers regarding development on the updates.

Thank you for your kind comments.

Quote from Viperakecske :

We respect but servers are dying we cant race whitout timing out and such yes

That's a bit much to say really, after a single race was disrupted by a DDoS attack and we made some changes to reduce the chance of such occurrences in future. Your comment is ill-informed, incorrect and unwelcome. Also you are giving the attackers the attention they crave.


OK, the trolls can smell blood and are starting to come in for the kill, so let's close the thread before it gets any worse.