The online racing simulator
Quote from Bose321 :Sounds like a nice update. Would be nice if we had a server to test it on.

What do you mean by that? There are several servers running. Confused

Quote from Bose321 :I find it a bit confusing that the tire width selector is changing front and rear for the FXR. The FZR and XRR do have it separated. I can imagine the FXR can have different widths if you have a RWD biased setup or whatever?

I've kept FWD and AWD tyre sizes the same at front and rear as this seems to be the usual thing.

This patch obviously does not allow all possible configurations. It enables a lot of new possibilities for drifting, rallycross and hard track racing.
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.
Quote from Pathseeker :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.

Scawen has already explained this in the other thread:

Quote from Scawen :
Quote from dekojester :Scawen, I am curious if it would be simple to allow more connections to a server. 38 driver slots is just fine, but only having 47 total slots is a hindrance, especially for endurance racing.
...
I understand if it's not just a simple integer switch, but it would really help the endurance side of racing, and even those full grid weekly events would benefit from it, especially if trying to qualify > 38 cars

I've had a look into this now and unfortunately it is too hard for this patch. Some packets have reached their size limit because of limitations in the packet system. Not only between guests and hosts but also between hosts and master server.

I have some plans to overhaul the packet system to allow much larger packets but it's a big change and not something to be done in the old version.

Quote from Scawen :What do you mean by that? There are several servers running. Confused


I've kept FWD and AWD tyre sizes the same at front and rear as this seems to be the usual thing.

This patch obviously does not allow all possible configurations. It enables a lot of new possibilities for drifting, rallycross and hard track racing.

Sorry, had my filters setup up wrongly.

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)?
Quote from Bose321 :Sorry, had my filters setup up wrongly.
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)?

What do you mean? FZR and XRR both can run widest tires in rear with alternative configuration was running 325 rear road normals last night
Quote from martin18 :What do you mean? FZR and XRR both can run widest tires in rear with alternative configuration was running 325 rear road normals last night

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
Quote from Scawen :I've kept FWD and AWD tyre sizes the same at front and rear as this seems to be the usual thing.

This patch obviously does not allow all possible configurations. It enables a lot of new possibilities for drifting, rallycross and hard track racing.

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.
Quote from DarkKostas :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.

if the central and front diff are open, isn't the car behaving like a rwd ?
Quote from Flotch :if the central and front diff are open, isn't the car behaving like a rwd ?

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 Big grin 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.
Quote from Scawen :I want to get back to the development version. It's really important to me.

Yes! Its important to me too and probably most of the players too. I'm really looking forward for the big update test patches. Thumbs up
rb4 must be 45 degrees
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
"Steering wheel turn amount changes with maximum lock"

This made me very happy. I didn't expect to actually see this get changed since it felt like a bit of a niche issue. Thank you so much!
Hhhmm.. Really long time since I tried LFS but is this normal that the tires stick out that much in case of damage?
Attached images
lfs_00000024.jpg
lfs_00000025.jpg
Yes.
Quote from Scawen :
You can now see CPU usage for Physics, Draw, Prediction, etc.
The "Pred" line shows CPU usage for prediction of remote cars

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.
What is with all these people coming in here with GPUs that they found bundled inside a box of cereal wondering why they perform terribly.
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.
Quote from gu3st :What is with all these people coming in here with GPUs that they found bundled inside a box of cereal wondering why they perform terribly.

Being with a laptop on the move (currently in Montenegro) is far more practical then walking around with a "gaming rig".

Stay on topic or get the fck out.
Quote from Scawen :
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,

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 Wink

Quote from Scawen : Please save some energy and heat

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!
Quote from cargame.nl :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.

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.

Quote from cargame.nl :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 notice that the internal GPU its much smoother. But this is patch unrelated.

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.
Can we expect revers Rockingham in the future?
This thread is closed

Test Patch U25: Multiplayer Updates
(352 posts, closed, started )
FGED GREDG RDFGDR GSFDG