In bf1 I think I have encountered a similar bug. I guess "setup changes needed" remains as long as the setup after changes is different from the starting setup.

Quote from MandulAA :

About setup changes in pitstops, this thread might be related (I'm not sure): https://www.lfs.net/forum/post/1960373#post1960373

Actually that is different - I fixed that one yesterday and that was just about the rear tyre pressure using front tyre limits. It will be in the next (compatible) test patch.

Quote from KevinRacer :

In bf1 I think I have encountered a similar bug. I guess "setup changes needed" remains as long as the setup after changes is different from the starting setup.

It's supposed to only say that if the requested setup changes are different from the current setup. Anyway I can reproduce it 100% (the symmetrical setup thing) so I'll be able to fix it.

While you were digging around with pitstop code, did you get a chance to look into these bugs?
https://www.lfs.net/forum/thread/94490-InSim%3A-IS-PSF-STime-Inaccurate-On-TOC
https://www.lfs.net/forum/thread/94491-InSim%3A-Missing-IS-PSF-packet

I did find another pitstop/InSim bug around that time, but it was considerably more complicated. I'll try to find my notes later.

Scawen, I decided to test that pit stop bug:

I tested this ON SO1+FZR and UF1. Same thing happened: I also encountered that same thing if you adjust camber settings instead in those cars. It also happens if you adjust back tires.

However this is where it gets interesting: if you change tyre type, or wing in FZR's case, it works properly. But if you adjust camber and/or tyre pressure at the same time, that bug still happens.

And I also noticed one more confusing thing and one more actual bug:

1) If I decide to change my both front and rear tires type, it's still possible to have that F12-option Tyre change as never. I understand that option can be set to "never", if you don't decide to change all tires. It's just confusing that it says "never" even if you decide to change tyre type on all wheels. Of course, it does change your tires if you change tyre type regardless of tyre wear.

So in case you decide to change tyre type to all wheels, should that option then automatically be: Tyre change : "always"?

I attached a screenshot about this.

2) Actual bug, happened at least on FZR. How to reproduce this:

1) Adjust your rear tires tyre pressure to the lowest possible (for example, if you're using FZR, adjust it to 0.70)
2) Do a pit stop.
3) After that pit stop, you can see that on F12-window, tyre pressure is correct, but it still says that change is -0.10 bar at rear tires compared to current setups. I attached a screenshot about this.

Regarding F12 menu and pitstop settings I have an improvement suggestion:
Once you accidentally switch from assymetric to symetric,you can't turn back so easily. I mean you can turn back to assymetric,but the settings all are now symetric and you have to adjust them manually back - it's quite difficult when racing on track and who can remember all the settings anyway?
So the suggestion is that either switching back to assymetric it should return to previous settings or there should be some way to cancel requested setup changes.

Quote from Degats :

While you were digging around with pitstop code, did you get a chance to look into these bugs?
https://www.lfs.net/forum/thread/94490-InSim%3A-IS-PSF-STime-Inaccurate-On-TOC
https://www.lfs.net/forum/thread/94491-InSim%3A-Missing-IS-PSF-packet

I've added this to my notes file for the compatible patch.

Quote from tankslacno :

2) Actual bug, happened at least on FZR.

Thanks for the tests.

That FZR bug is one of the things I fixed yesterday, linked to by MandulAA above.

Quote from Eclipsed :

Regarding F12 menu and pitstop settings I have an improvement suggestion:
Once you accidentally switch from assymetric to symetric,you can't turn back so easily.

Thanks but I don't want to tackle that, as there is bug potential and complication there. Actually I'm just trying to stay sane while trying to get the compatible fixes done so I can get back to the incompatible fixes so I can release version V so I can get back to the development version and try to finish the graphics so I can get back to the tyre physics.

Quote from Scawen :

Actually I'm just trying to stay sane while trying to get the compatible fixes done so I can get back to the incompatible fixes so I can release version V so I can get back to the development version and try to finish the graphics so I can get back to the tyre physics.

My anxiety levels got up just by reading it.
Please stay sane, we need you!

A quick fix for the auto-repeat - I've enabled it again for all keys by default so it is as before. But it can be disabled on any particular function with a single line of code.

I know at least one function in the development version where I would disable it. But I haven't thought of any in the public version. Please do tell me if there is anywhere that auto-repeat can cause unexpected, confusing, annoying or otherwise bad issues, and I'll disable it on that key.

Quote from Eclipsed :

So the suggestion is that either switching back to assymetric it should return to previous settings or there should be some way to cancel requested setup changes.

I missed the final part of your suggestion yesterday but came to the same conclusion today.

It was an easy fix to cancel all requested changes in F12, because the unchanged setup is available in the current car setup. So the 'cancel' option will be in the next (compatible) test patch.

OK, some more updates in U15. Still a compatible version.

F12 pit instructions:

Pressure change with new tyre no longer counts as SETUP CHANGES
A new 'cancel' option beside the 'setup changes requested' line
Settings that will be adjusted are now shown in light red colour
FIX: rear tyre pressure was limited by front tyre pressure limits
FIX: symmetric pressure/camber request remained after pit stop

Multiplayer:

More accurate transmission of fuel load from local to remote car
Remote car fuel load is now shown in F12 if /showfuel is enabled
Rolling resistance included in catch-up phase of prediction
FIX: Remote cars with worn tread could wrongly get a puncture

Misc:

Auto-repeat key function reinstated (disabled in previous test)
MPR / SPR are now prevented from being named temp_mpr / temp_spr
Free view mode minimum field of view reduced from 10 to 2 degrees
InSim NLP / MCI minimum time interval reduced to 10 ms (was 40 ms)
Mouse X and Y sensitivity (in Axes tab) lower limit reduced to 0.5
FIX: Message MPR_BLANK sometimes displayed when watching live MPR

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

Quote from Scawen :

Free view mode minimum field of view reduced from 10 to 2 degrees

That should make our cameras a lot more versatile, thanks

Small bug:
When using the 4+5 keys to zoom, it hits a minimum of 5.7 and stops zooming.
The slider and InSim packet control work fine and will go right down to the 2 degree limit.

Quote from Degats :

Small bug:
When using the 4+5 keys to zoom, it hits a minimum of 5.7 and stops zooming.

Same here.
I wanted to say this is a really nice update, will use it in my videos, thanks!

Quote from Scawen :

A quick fix for the auto-repeat - I've enabled it again for all keys by default so it is as before. But it can be disabled on any particular function with a single line of code.

I know at least one function in the development version where I would disable it. But I haven't thought of any in the public version. Please do tell me if there is anywhere that auto-repeat can cause unexpected, confusing, annoying or otherwise bad issues, and I'll disable it on that key.

I’m not sure if this is caused by button-repeat or some issue with latency, but sometimes online I’ll accidentally hit the block messages key, and it quickly blocks and unblocks messages. But the server will only display the “blocked messages “ message. So I’ll hit it again to unblock messages and it displays that I blocked messages again. And finally a third time to unblock messages. So server output looks like:

Slow blocked messages
Slow blocked messages
Slow unblocked messages

Also, maybe the lights on/off button, but that’s more of a creative decision than a UI annoyance.

Quote from Scawen :

CPU usage display:

In Graphics or Misc options (in-game) click the car icon then 'P'
You can now see CPU usage for Physics, Draw, Prediction, etc.

I just made a quick test on Blackwood for this feature :
While driving alone, if I limit the frame rate at 250, I can see the sleep value at around 70.
If I do not put a limit, I am reaching 1200-1300 fps, but this time the sleep is around 0 => I can see a core going at 100% of cpu usage (single core app behaviour I suppose)
If I use a full AI grid without limiting fps, I can see them dropping to 300-350 while the cars are present (a lot more if you are "alone" in your field of view).
The Draw is almost always identical I would say, in my case ~70 when not limiting fps. Physics is going to 15-20 with the full grid of AI, and almost 0 when alone.
How is this working : does more sleep mean more cpu "free" time ? is it the same for physics value ? if so why would 31 AI with you cost less less cpu for physics than when alone ? Or is it a display showing the average consumption between each part (the sum is close to 100 each time) : physics, draw, etc... and the "free time" (sleep) ? I tend to suppose it is the last one...

Thanks for the testing and reports.

Quote from Flotch :

How is this working : does more sleep mean more cpu "free" time ?

Yes. Sleep is done deliberately by LFS if you limit the frame rate or if "Sleep every frame" is set. It calls a function "Sleep(x)" which gives up x milliseconds to the operating system before continuing to process LFS code. It tries to do just the right amount of Sleep each frame to get down to the target frame rate.

"Flip" is a another kind of waiting time when we are waiting for D3D to finish and present the finished frame. One way to see that is if you use SHIFT+F11 (full screen borderless window) with vertical sync enabled.

I just noticed that if you use SHIFT+F10 (full screen exclusive mode) then all the extra CPU seems to be in "Draw" rather than "Flip" so I'll have a look why that is different from SHIFT+F11.

About your question "why would 31 AI with you cost less less cpu for physics than when alone". That should not be the case. More AI drivers should always use more CPU time for Phys. By the way, the CPU usage for the actual 'AI' is also included in "Phys" and Audio is also included there. But these are very small compared with the actual physics.

Ok, noted. I think I was misunderstanding sleep/cpu time/cpu tick.
Indeed when more AI are present, the percentage for physics is at 20, while alone it barely reach 1. What is logic.

A simple side question : is LFS limiting the cpu usage to compute frames ? for instance, in my case I suppose the clock frequency is getting somewhere at 5GHz when a single core is stressed, and so LFS displays a huge amount of FPS (more than 1300 when alone). But in the mean time LFS knows that my screen is limited to 60Hz => how is handled the thing in the end : does the couple cpu/gpu has really computed the things (1300 fps), but forbid the gpu to send this flow of framerate to the screen ? or is it done anyway, and the screen discard the unecessary frames ?
I know in the past there was some strong proselytizing ( ) for using vertical synchronization to have fps matching the screen max frequency, but at my level when doing some tests in various games, I tend to have a slightly less fluid experience than not using it ... it is of course very subjective I guess.
Anyway Scawen, I hope you wil succeed to find how to implement the facility for multithreading capabilities for LFS , it ease a lot the cpu consumption for a given result in the end.

Quote from Flotch :

I know in the past there was some strong proselytizing ( ) for using vertical synchronization to have fps matching the screen max frequency, but at my level when doing some tests in various games, I tend to have a slightly less fluid experience than not using it ... it is of course very subjective I guess.

In a lot of games, the processing of controller inputs is tied to the frame rate, so a high FPS will give a lower latency, making the game feel more responsive, even if the same number of frames are rendered on the display.
When inputs (and sometimes physics) are decoupled from the frame rendering, you can still benefit from good latency without having your GPU render loads of frames that will just get thrown out anyway. Some newish GPUs/drivers do some magic to try to improve the latency without having to render so many unneeded frames.

Remember that any need for frame rate higher than 100 Hz was eliminated in test patch U7.

Quote from Scawen :

...

About the connection between visual frame rates and force feedback:

In the old system there was a reason to go for higher frame rates to get more immediate force feedback. But this is now controlled by these user settings and there should be no reason to go higher than 100 fps (LFS physics update rate).

Quote from Flotch :

or is it done anyway, and the screen discard the unecessary frames ?

Yes, if LFS shows a high frame rate, then all that drawing really is going on and it is being flipped to the screen memory (or an off screen surface) at that high rate. But you can't see it because all those extra frames above 100 Hz are identical to another frame (e.g. at 200 Hz we draw 2 identical copies of every frame). And if your monitor is at 60 Hz you won't even see the 100 Hz non-identical frames. You may see a single tear line if the frame is updated during the vertical refresh.

I recommend limiting to 100 Hz or using vertical sync. Otherwise you are just wasting energy for no reason.

Makes me think of gas flaring: https://duckduckgo.com/?q=oil+flare&t=ffab&iax=images&ia=images

@Scawen : what I see/feel :
* with vertical synch (60 fps here), I find some disturbing transitions between frames. It feels not so fluid in some parts, more often when going at high speed, but even in the corners of Blackwood it is sometimes a bit weird to me. One note : Sleep is = 0.00 in this mode (while my cpu is almost doing nothing)
* at 100 fps I still see some "missing frames" I will call them. Again, it is obviously subjective, but it gives the feeling of a computer slowing down when doing the job
* at 150 fps it looks the same as without limit

@Degats : I see what you mean, and totally agree.

Vsync will inevitably result in slightly larger input lag, as swap will block when next frame is already completed. Thus when it is finally presented to the display it will contain older data than it possibly could.

Example: 60Hz display, Vsync is enabled. Buffer is swapped and in this moment next frame rendering starts. It renders in 4ms, but it needs to wait 16.66-4=12.66ms before it is presented. Note that if during these 12.66ms anything is updated, it won't change queued frame.

To avoid that and not waste electricity, rendering needs to start as late as possible. Thus it is necessary to estimate how long next frame will take to render, and wait for (refresh time - estimated frame time - safety margin) before starting rendering. Some swap modes have an issue there: estimated time is obviously not computed precisely exact, so with vsync disabled, it could tear near bottom/top of the screen. But with vsync enabled, small overshoot will cause waiting for whole next frame, which is even worse. I don't know how it is named in D3D lingo, but in Vulkan swap mode named "FIFO relaxed" would solve this, as it is essentialy "vsync but not if late", it would prevent bottom tearing and avoid catastrophic whole frame delay during occasional overshoot.

(there's possibility some graphics drivers are trying to do these calculations themselves and are blocking during swap for extra time)

Quote :

(e.g. at 200 Hz we draw 2 identical copies of every frame)

Does that also mean that in VR mode, when running at eg. 120Hz player car position is not interpolated between 100Hz physics updates? Thus when eg. looking out of the window on track environment, apparent frame doubling will periodically happen, as 100Hz<120Hz?

Quote from milek7 :

Does that also mean that in VR mode, when running at eg. 120Hz player car position is not interpolated between 100Hz physics updates? Thus when eg. looking out of the window on track environment, apparent frame doubling will periodically happen, as 100Hz<120Hz?

Yes that is the case. I haven't seen 120Hz but there is a similar effect at 90Hz. For a lot of people, when looking in the direction of motion, this effect is not too bad but some people seem more troubled by it. I don't know if that difference is purely a perception thing or related to the particular hardware. It is certainly noticeable for anyone when you look sideways at the scenery going past.

Simple answer, yes, it's a known problem.

Quote from THE WIZARD DK :

i use Vsync for the only reason i get a line across the screen when not.
and i think you just described in detail exactly what my issue is with that.
a guess i start with. taking off Vsync.

even though MPR dont record it. im still getting massive lagspikes(or looks like lag) when someone joins server leave server go to or come from pit garage. only change is MPR dont record it now.



this is those "places" on tracks i spoke about some time ago @Scawen.
theres also one if going clockwise on westhill T1. its like the image clutter up or something in these specific areas. and thank you @Flotch for writing this. then i know im not totally off by what i have written earlier.

Those issues still sound like your computer being too weak for what you're trying to do. If there's a delay when cars join the track, that's resource contension where something needs to get paged in/out of memory and the system needs to wait for this to occur. Same thing if it happens in areas of the track.

Additionally becuase of how vSync work is that if it can't meet the refresh rate, it'll reduce to a fraction of the refresh rate to keep hitting frame timing. Triple buffering can reduce the major frame drops but it adds more imput lag. If you have it enabled and you can't maintain 60 FPS, then it'll drop to 30. If it can't maintain 30, even for a moment, it'll drop even lower.

If it's dropping to 30 FPS then you're not able to maintain 60 FPS in those situations. If you were, it wouldn't drop to 30. Additionally, dropping to a divisor of 2, 4 or 8 of refresh rate is a symptom of double buffered vSync.

The settings in nVidia control panel for vSync applies to OpenGL games, not DirectX. DirectX also has some problems with triple buffering in older versions of DirectX, in some cases it's just unsupported and in other cases it creates further input lag or dropped frames. It's also up to the game to support.

Quote from THE WIZARD DK :

it drops only sometimes and inside those areas. but otherwise maintains a steady 60fps.
so basically youre saying i can do nothing about that or?

So your PC can't maintain a steady 60 FPS if it drops down to 30 FPS via Vsync in some situations. "Steady except sometimes" means that it's, by definition, not steady.

The texture mods that you are using could be placing additional load or paging on the system, leading to missed frames and frame drops.

A background process could be stealing enough CPU time at the wrong moment to cause frame time to take too long, dropping the frame rate.

Again, it could be possible that for the races you're running, with the settings you're using, the mods that you're using, that your PC is just too weak and can't maintain 60 FPS.

Disabling vsync would help (albeit adding frame tearing) by ensuring that a slow frame doesn't immediately halve the frame rate.