9 minutes ago, Reset XPDR said:

Since you say you mostly achieve your 30 FPS cap, I suggest trying Fixed DynFG 30for your Target FPS

Don't rush! As i mentioned in my original post, i already did this, but i am worried it was a little bit hidden in the text. "I have limited FS2024 to 31 frames, giving me 62 with build in FG on, dynamic frames set to 30 for small headroom (inside FS settings) So, I set FIXED under General tab, Target to DynFG and FPS to 30" (thats AutoPFS settings).

So, AutoFPS sees 31 frames in the count, but Target Frame rate is already set to 30 as you suggested.

I fixed the FS 2024 limiter to 31, to prevent interaction of the dynamic frame rate limiter too early. Sorry, i am not used to write in English, so i apologize for missleading statements.

Matthias

8 minutes ago, ankh21 said:

Don't rush! As i mentioned in my original post, i already did this, but i am worried it was a little bit hidden in the text. "I have limited FS2024 to 31 frames, giving me 62 with build in FG on, dynamic frames set to 30 for small headroom (inside FS settings) So, I set FIXED under General tab, Target to DynFG and FPS to 30" (thats AutoPFS settings).

So, AutoFPS sees 31 frames in the count, but Target Frame rate is already set to 30 as you suggested.

I fixed the FS 2024 limiter to 31, to prevent interaction of the dynamic frame rate limiter too early. Sorry, i am not used to write in English, so i apologize for missleading statements.

Matthias

The reply of mine you quoted was my response to @xsever , not you, so you can disregard it as it was a different question/issue.

Re the app update for your issue, I am working on it now and it is literally a one line fix to require MSFS being the active window as well as all the original conditions before spike protection initiated TLOD reduction will be allowed to occur, so it will be out shortly:

           if (Model.ActiveWindowMSFS && Model.SpikeDetected && Model.SpikeTLODReductionAmount < Model.MaxTLOD[Model.activeProfile] - Model.MinTLOD[Model.activeProfile])

Edited July 15Jul 15 by Reset XPDR

@ankh21 OK, I lied. 😁 It was two lines of code to change to stop periodic spike detection TLOD reductions happening when MSFS does not have the focus. The second one adds a pause symbol on the spike detection status line to show you that it is not acting on a detection ie. detections will still occur but just not be acted upon eg.

0.5.2.0-test16 is out now with that change.

Haha, you are that fast I cannot test and send log files as quick as you write new code lines…even if there are two 😜.

So, I will save the log file from yesterday as AutoFPS installs the new version as soon as I fire up Flight Simulator. And after that I will test the new version. But I am sure, that my „problem“ of spike induced TLOD decrease will be cured with this new version. During flight, the new DynFG option seems to be my favorite as i have very stable frame rates and very rare TLOD changes with a 500 set max. Just a dream!

Thank you so much!

2 hours ago, ankh21 said:

But I am sure, that my „problem“ of spike induced TLOD decrease will be cured with this new version.

Test 16, works great! No more spike triggered TLOD decrease during window change! Chapeau!

Matthias

Deleted

Edited July 15Jul 15 by GraDe
Incorrect reporting

5 hours ago, Reset XPDR said:

Since you say you mostly achieve your 30 FPS cap, I suggest trying Fixed DynFG 30for your Target FPS.

I downloaded test 16 and set DynFG and set it to 30 FPS and started my flight and everything was running fine with DTLOD at 200 and TOLOD at 20 and CLouds at Ultra. Then I realized that your instructions called for switching the target FPS option to Manual and as I soon as I did that, DTLOD dropped to 50 and got stuck there and would not go up at all despite achieving the 30 FPS very easily and FPS Settle transitioning to FreeTLOD 50-200. I was at 20,000 ft when that happened. As soon as I go back to Fixed, DTLOD goes back to 200 and stays there. Am I doing something wrong here? What other feedback do you need to troubleshoot this?

https://imgur.com/a/TJHlKA6

Edited July 15Jul 15 by xsever

2 hours ago, xsever said:

I downloaded test 16 and set DynFG and set it to 30 FPS and started my flight and everything was running fine with DTLOD at 200 and TOLOD at 20 and CLouds at Ultra. Then I realized that your instructions called for switching the target FPS option to Manual and as I soon as I did that, DTLOD dropped to 50 and got stuck there and would not go up at all despite achieving the 30 FPS very easily and FPS Settle transitioning to FreeTLOD 50-200. I was at 20,000 ft when that happened. As soon as I go back to Fixed, DTLOD goes back to 200 and stays there. Am I doing something wrong here? What other feedback do you need to troubleshoot this?

https://imgur.com/a/TJHlKA6

When I said use Manual target FPS option, that was generally speaking when using an uncapped FPS and setting the target FPS value to something lower eg:

In your case, your FPS is actually capped, hence my specific advice for you to was use Fixed DynFG 30 for your Target FPS. When you used Manual Target FPS option, your FPS could never go above your 30 target, which means TLOD can never increase from your starting TLOD.

In short, leave it as Fixed.

Edited July 15Jul 15 by Reset XPDR

Small question @Reset XPDR i have set AutoFPS in expert mode for fixing TLOD and OLOD.

With setting on auto I see that TLOD will vary but OLOD ? I don’t like TLOD on 50 it is too low

1 hour ago, Reset XPDR said:

my specific advice for you to was use Fixed DynFG 30 for your Target FPS. When you used Manual Target FPS option, your FPS could never go above your 30 target, which means TLOD can never increase from your starting TLOD.

My bad. I missed that "Fixed". I stayed with Fixed for the remainder of my flight and it worked flawlessly. I was able to increase max LOD from 200 to 350 without any impact on performance since FPS stayed at 30. Thank you so much for this update and will continue testing and reporting back if/when needed.

2 hours ago, kopek666 said:

Small question @Reset XPDR i have set AutoFPS in expert mode for fixing TLOD and OLOD.

With setting on auto I see that TLOD will vary but OLOD ? I don’t like TLOD on 50 it is too low

OLOD will vary with altitude when you have Auto OLOD enabled. If you want a higher TLOD Min, then change it. The readme covers this and much more.

I flew for the first time since this update today. I noticed that FG was inactive. Have not encountered this before. Checking during my 3 hour flight I found FG occasional active, then later inactive again. I have not made any settings changes. Seems that if I simply go into MS2024 Settings, do not make any changes, then return and check again, FG is then active. I fly for a while, check Auto FPS, and again FG is inactive. Any guidence? My hardware specs are in my signature.

2 hours ago, fppilot said:

I flew for the first time since this update today. I noticed that FG was inactive. Have not encountered this before. Checking during my 3 hour flight I found FG occasional active, then later inactive again. I have not made any settings changes. Seems that if I simply go into MS2024 Settings, do not make any changes, then return and check again, FG is then active. I fly for a while, check Auto FPS, and again FG is inactive. Any guidence? My hardware specs are in my signature.

I think you might be confusing FG enabled with FG active/inactive. I used to have a FAQ entry about this, which said something along the lines of the following.

FG enabled is as you have set in MSFS settings and the app will read that state from your MSFS config file whenever that file changes, usually because you have changed a setting. If it is not enabled, and you are not using any other form of FG, then AutoFPS will detect the graphics mode as NFR.

With FG enabled, FG can be either active or inactive. Active is when the MSFS window has the focus and the FPS will be the NFR FPS times whatever FG multiplier is in use (2X in your case). Inactive is when the MSFS window has lost the focus, ie. you have selected another app to be focused, and all FG multiplication ceases, leaving you at the NFR FPS.

If you have placed the AutoFPS window over MSFS and AutoFPS has the focus, not MSFS, then FG will be inactive and indicated as such, as your screenshot seems to show. If you want to see the app showing FG when it is active, make sure MSFS has the focus and either enable On Top in the app first so that the app window will sit over the MSFS window when MSFS has the focus or, if you have more than one monitor, move the AutoFPS window to another monitor then use MSFS on your main monitor.

eg. using the On Top method, firstly MSFS with the focus:

Now AutoFPS with the focus (you can see the AutoFPS title gets un-greyed):

BTW, I strongly recommend you update to AutoFPS 0.5.1.0, as it the most stable and commonly downloaded version ever released.

Edited July 16Jul 16 by Reset XPDR

9 minutes ago, Reset XPDR said:

BTW, I strongly recommend you update to AutoFPS 0.5.1.0, as it the most stable and commonly downloaded version ever released.

I did that later this afternoon, and I found a previous post and response here that helped. But your explanation above in response to me is much more clear to me. Thanks as always. Been a loyal user since day one! 😀

---

Periodic spike detection — real detections at normal settings, but SRed never recovers (0.5.2.0-test18)

@Reset XPDR — you said you wanted to know whether periodic spikes get detected at more normal settings, and whether they're actually real rather than false detections. I have a data point on both, plus one issue.

Setup, nothing exotic — this is my daily config:

MSFS:24 Expert Mode:FSR3 TgtFPSOpt:Fixed FltType:IFR TgtFPS:60 TLODMethod:Sens Tol:3
SDet SMult:2.0 SProt TMin:125 TMax:700 TLODBAlt:1500 TLODTAlt:6000
VRAM+:Max Vrec:93% Vhld:96% Vred:98%

RTX 3080 Ti (12GB), Citation Sovereign+, KASE→KSEA, 2h14m, offline.

1. The detections are real. Your detector fired on the climb out of Aspen, and the frame time buffer it dumped is textbook — ~16.5–17.4ms baseline with 33–50ms spikes landing about once a second:

...17149, 37251, 16561, ...  17127, 37707, ...  17162, 37812, ...

I also log raw PresentMon frame times for the whole flight separately, and an independent pass over that full record found the same thing: 5 periodic episodes at a 0.98–1.02s cadence, interval std 0.00–0.04s. So these aren't false positives, and they turn up at TMax 700 — not just at the 1000–2000 you had to force on your own systems.

2. The issue — SRed accumulates, then never releases. Protection activated three times on the climb (@TLOD 700, 640, 664), while I was in VRAM overflow (Vred firing at 98–99%). SRed built to 384 and then froze there for the remaining ~80 minutes:

t+30min   SRed:156  TLOD:475  AGL:37722  FPM:-7   GPU:42%  VRAM:90%
t+50min   SRed:384  TLOD:125  AGL:38563  FPM:-23  GPU:41%  VRAM:65%
t+60min   SRed:384  TLOD:316  AGL:37389  FPM:-4   GPU:43%  VRAM:74%
t+100min  SRed:384  TLOD:316  AGL:42901  FPM:1    GPU:44%  VRAM:78%

TMax 700 − SRed 384 = 316, and TLOD sat pinned at exactly 316 for the rest of the flight — with VRAM back down to 74–78% and the GPU at ~44%, so there was plenty of headroom by then.

I was level at FL370–420, hundreds of miles from where it activated and well above TLOD Base, which I thought met your recovery criteria. Does recovery actually make progress in level cruise (VS ≈ 0), or does it need a positive climb rate? If the rate is VS-scaled, level cruise would give near-zero recovery, which would explain what I'm seeing.

3. A thought on the trigger. The spikes that drove SRed occurred while VRAM was at 96–99% and your VRAM limiter was already reducing TLOD for it. Both limiters were reacting to the same root cause — but the VRAM one released when VRAM recovered, and the spike one didn't. Would it be worth suppressing spike accumulation while VRAM limiting is active, since spikes under memory overflow are arguably thrash rather than graphics engine overload?

I have the raw 7.3mb log if you want it. - Posted on Git discussion

Edited July 16Jul 16 by Randall Fortee22