I know its a bit off-topic, but maybe there would be a chance to add 1-3spots on server? Not on track, just on server, why? I'll use as example NDR GT2C that is going on now, they have 38 driver in round, safety car, rescue car, 3+- commentators, race director and 4- stewards( some oof them learning) so they dont have enough space in server, and just 1-3 added spot would help for now a lot, and that includes other leagues, like fragmasters.
Out of interest, is it possible to go wider for example the XFR? I think 215 is pretty normal for daily cars even, and I think 225 and slightly larger is normal for more sporty hatches. I think especially with road tires it's a nice bonus.
Out of interest, why can't I run tires as wide as the default config? I understand the whole idea of the alternate config was to have narrower tires for drifting, but since we now have the option, why not allow tires as wide as the default (at least on the rear)?
This is his point : by default you have 335mm for XRR
Anyway, the "alternate" config does not intend to give an advantage over the previous "classic" version, so why not having less tire width at max
I was thinking the same. Now the patch opens so many possibilities, but why not use lock upgrades on the AWD as well? By making them RWD (5% on the diff setting), they're turning into very nice real wheel driving machines, both RB4 and FXR. Lock is the only thing they're missing to slide them properly.
Front yes, but the central has to be locked and set as much as possible on the rear (which is 5% front, 95% rear). Then you just put an LSD to the rear and boom Even with 30 degrees FXR is quite fun, but of course ain't competitive against the other 2.
All the vehicles with front wheel drive (including four wheel drive) have less steering lock because of the CV joint in the front drive system. Of course in LFS the CV joint doesn't really exist but we don't want to allow impossible things.
I have not researched recently into the lock limitation of CV joints. I do know that ordinary road cars with front wheel drive have a quite bad turning circle compared with RWD cars. If that was an easy problem to solve then manufacturers would do it.
Of course it would be wrong to allow extreme steering angles for vehicles with front wheel drive. There may be some cars where it is reasonable to increase the lock a bit more but I don't have any appetite for looking into that type of thing now.
As I've said a lot of times, I want to get back to the development version. It's really important to me. I hope we don't have to do any more incompatible test patches in this series. My brain already feels quite mashed with all these recent updates which were not planned. I don't regret them - I think there are so many new possibilities. But we have come to the end.
Of course, we are still in testing and I do want to know if anyone finds any issues.
Sounds fine, I think this is a major step in a good direction and we have to draw a line somewhere. And the smaller things can always be added later on. Besides, I think it's beneficial for all of us that the major changes like physics and graphics are worked on so we can hopefully enjoy that sooner.
By the way I don’t think anyone noticed LX cars now have 45 degrees lock! Tested that today that was amazing! Thanks Scawen!
Only thing I’d say is maybe 265 front for both FZR and XRR should have the 60 degrees lock.
Maybe just 255 for the FZR since it’s rear engine (rear heavy) felt like had to turn up the front wing Downforce quite a bit to get any grip, I was able to get setup decent enough (245 front 295 rear) but about 5 of us were all asking our selves why only 245
We found 295 rear tires being about the perfect balance. 305-325 driftable but you know just a bit of over kill. For full power no restriction 295 on both cars was just the right amount. We wanted to balance it out more with more front tire 265 front would be more balanced grip levels
Hhmm this feature is misleading when you have a CPU with on-chip GPU combination. (i7-6820HQ HD 530 - Nvidia M3000M combo)
"Draw" reports 90 (percent I guess) CPU usage while it is actually the GPU part doing its job. If I switch to the external GPU chip, "Draw" drops to 12 and "sleep" takes over with 70-80.
This misleading display of "CPU" usage cannot be changed I guess? Its not such a big deal if you know whats really going on but if it can be easily altered then take this into consideration.
edit: actually I hope its the GPU part otherwise I get the feeling there is seriously something wrong with LFS performance. Its mostly the full scene AA causing this by the way.
It is CPU, not GPU, time which is being measured. Actually it's just time itself between one point and another.
The "Draw" section is supposed to represent the time taken for the CPU to work out everything related to drawing the shadows, environment maps, mirrors, main views, etc. During this time there are a lot of calculations and thousands of calls to D3D to set constants, set active textures, set vertex and index buffers, and request sections of those buffers to be drawn. Even some vertices and triangles to be sent to the GPU every frame (for flexible objects like drivers and tyres). There is a *lot* of work for the CPU to do when drawing.
That is why it can help to separate physics and rendering onto separate threads. The GPU doesn't just magically know what do to, it is instructed by thousands of calls every frame, from the CPU, through Direct3D. If the CPU didn't have to do much then there would be no need for a separate thread for rendering.
However, there is something seemingly anomalous about a high value in "Draw" in certain situations. In my case I can make Draw go over 90% by selecting exclusive mode full screen (SHIFT+F10) with Vertical Sync enabled. I don't know exactly why that is without looking into it, but it seems quite certain that the time while we are waiting for the vertical sync, is within the start and end of the section I have marked as "Draw". It's nothing to worry about.
If I go full screen in borderless window mode (SHIFT+F11) then the waiting time is in "Flip" which I would have expected to be the case in exclusive mode full screen too. So that's the only anomaly but I'm not really too worried about it.
Without vertical sync enabled, but frame rate limited, the spare time moves into "Sleep" so we get a much better reading for how long the Draw is taking. If you disable frame rate limitation then frame rate goes insane and Draw goes up to a high number. That is expected as we are asking LFS to draw as many frames as possible with every scrap of time remaining.
That is only a waste of energy. Frame rate should either be limited to a set value or vertical sync should be used. There is no point in extremely high frame rates, specially since the new test patches have sorted out a controller issue that previously caused high frame rates to be useful for force feedback.
I repeat - that is no longer the case. Please save some energy and heat by limiting frame rate (e.g. 100 fps) or using vertical sync if you prefer.
Hmm it was capped on 100 fps (to be in sync with physics) a value which couldnt be reached with the on-board GPU in openX mode (non open layout is probably a different story). Interestingly CPU usage(/Draw) massively drops if I set it on 60 fps. So, if I understand correctly the CPU gets overloaded if the system gets a request for a FPS value which it can never achieve. I wonder if this situation can be automatically detected and can produce a warning as only a few people are being busy with this CPU/GPU nerding
well.. this building is heated by electricity so this doesnt really make much of a difference. Need to wait some weeks before sun starts to do its work but I do get the point.
One thing to still figure out is why there is still so much "shimmering" going on (barriers), even flickering textures.. In external GPU mode. I only now noticing the internal GPU producing a much smoother image. But this is patch unrelated.
This small little CPU debug thing is very helpful in understanding hardware/configuration limits, liking it!
If we exclude that anomaly I mentioned (high "Draw" in exclusive mode with vsync) then Draw should be a good representation of how long it really takes LFS to send all those draw calls and do all the calculations like object culling, lighting on deformed tyres and so on. So it should then be proportional to the frame rate. So 100 fps should produce a Draw CPU measurement that is 66% higher than at 60 fps.
Some of the shimmering can be reduced by moving mip bias sliders to the right and using anisotropic filtering instead. But shimmering of armco barriers is not related to textures so cannot be solved that way and the best you can do is antialiasing. But they will still shimmer.
Even with 30 degrees FXR is quite fun, but of course ain't competitive against the other 2.
