Here is a suggestion/tip about key binds for tyre changes if the race is declared wet. I guess this may not be obvious to everyone as the commands are quite new. Previously, scripts could be used to set the pit instructions, but with recent LFS updates they are no longer required.
Because of the quite new /pitins command (set pit instructions) and multiple commands on one key bind, you can set the tyres to be changed in your pit stop, using the text in one key bind.
I hope this question isn't too obvious. I am aware of my lack of race experience.
I read up on safety car and virtual safety car, to find out the speed limits.
I think under real safety car there is no speed limit, it's more like drive safely and no overtaking unless directed.
Under virtual safety car I read in the NDR Sporting Code that the standard speed limit is 100 km/h, but may be specified differently for an event. For some reason I had thought the speed limiter could be used but that isn't the case if the limit is 100.
EDIT: So my question is what is the VSC speed limit in this event?
I saw a parked Porsche on a walk yesterday, if was a 911 but had a similar layout for the front lights, including the front side indicators and the lower strip below the main headlights. We could see orange bulbs inside the strip light so think they must be indicators.
One more thing I noticed on the model, it looks like the calipers need to move out a bit as the disc is visible.
I can't really see from your image but it sounds like the auto mirroring system for mappings. It's the system that allows, for example, a small mapping to be applied to some triangles on one side of the object and then the related triangles on the other side will receive a flip of that same mapping (optionally with a different cutout).
That system can't work if a "reflectable" mapping is applied to a triangle that itself is on two sides of the object.
So you need to either:
- continue to use a reflectable mapping, then use triangles that are on one side or the other but not both. I think this can be done by using the yellow central points and triangle mirroring.
Or:
- continue to use triangles that cross from one side to the other but make sure the mapping is not reflectable. A mapping is marked as reflectable if all its points are on one side or the other. So maybe in your case you need to move the mapping near the centre so it straddles the centre line.
Hope that helps although it's possible I've misunderstood the situation.
I think I should mention that I've entered the E-Challenge.
All four rounds use a layout that replicates a real life street circuit
Each event has qualifying sessions, a sprint race and a feature race
Server is open for practice at the challenging Mexico e-Prix Circuit
The feature race (27 laps at Mexico) requires some energy saving
Live streamed with expert commentary by Sim Broadcasts
Race direction by New Dimension Racing
There's still time to get some practice in and sign up!
I hope I'm not annoying you with feedback as I already posted in the other thread. It's just that I'm sitting here looking at the car and come across things.
1) I thought the front indicators are hard to see from some angles, like it has the front side ones but nothing front-facing. I really can't find reference on the internet but wondered if the lower front narrow strip lights could be used (though it needs reference material).
2) I found the up-down gear indicator on the dash too hard to read, it was so small, I thought maybe the 7-segment number would be enough as it looks nice. But I am uninformed, it's just an opinion / observation. But I think this is covered by superlame's suggestion.
3) I think the rear number plate has too much vertical stretch.
That is, 49.7 days after starting, your host will hang and anyone on it will be stuck online and people who join are in "Queue position 1" until they press escape.
This is fixed in my version and so you will all get the fix in version F (hopefully in a week or two, depending what comes up).
Anyway, for now you can find out when your host was started and if it is near 49 days, you should stop it, and restart it (you have to wait 1 minute).
To see when it was started, hover your mouse over the green RUNNING text and you will see the UTC time and date when the host was started.
Why 49.7 days?
Well that is 0xFFFFFFFF ms (hexadecimal)
Or in binary, it's 11111111111111111111111111111111 ms.
Then time inconveniently loops back to zero, so in 1ms you go back in time 49.7 days.
I had a look and I don't know a way to fix it while using compressed textures. It is 16 bit colour banding due to the conversion to DDS. You can see it in the editor too if you switch on compressed textures.
I have a few too many things to do, so can't really investigate further at the moment. I'm not sure but maybe it could be better to go for a plain colour as the best compromise within the current system.
Can you explain this? I tried extrude or trace and it did use the currently selected layer, as I would expect so I'm not sure what you would like to work differently.
Related to this, I thought of a possibility specific to extrude (not lathe). The trace line is often along existing triangle edges. I think it could detect this and use all the properties of the triangle that shares the edge (separately for each line in the trace). Smoothing group, mapping, layer.
Yes, I have been thinking of this too, actually have already asked Eric about it.
The only issue I have, and it's not a big problem, just which point to use as the origin of the automatically created "break off" object. I think it should be one of the points belong to the selected triangles, or somehow related to them.
Maybe a yellow button if there is one, or a point that is low down in the selection. You might think of something like a point that is in the centre of the selection, but this could risk losing precision. Maybe the nearest point to the centre, or the lowest point?
Just thought I'd ask this in case anyone has a good idea for that. It's not that big a deal because you can adjust it after breaking off, but a good choice of object centre might be helpful, I guess.
Yes, these DXT formats are interesting, as a special kind of compression that can be used directly by the GPU without decompression. Well, that's not quite true - I suppose they are decompressed at the moment they are read into the pixel shader, but not in advance.
Because the compression is only in blocks of 4x4 pixels, which is a completely different type of compression compared with JPG or PNG (which are also very different from each other).
The result of this is that they are even faster than fully decompressed textures because of the memory bandwidth reduction.
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.
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.
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?
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.
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.