Reset XPDR

FYI for anyone wondering the outcome, it was Steam being unknowingly run as Admin, with MSFS inheriting that same privilege level, that was blocking AutoFPS being able to attach to the MSFS executable. All resolved now.

Before you do anything too drastic, send me via PM the contents of one of your app logs, located in %appdata%\MSFS_AutoFPS\log, and I will see if I can tell what is going on.

Did you try everything the readme suggests to try? If after installing and running the app your simconnect always stays red, your TLOD and OLOD values show as zero or you see "Critical Exception occurred: MSFS_AutoFPS - Unable to load DLL 'GpuzShMem.x64.dll' or one of its dependencies" in the log file: Try reinstalling the app with the Repair option selected, then reboot. If any of the redistributables fail to install during this process, try downloading and installing/repairing (as applicable): A Microsoft official version of “Microsoft Visual C++ 2015 - 2022 Redistributable”, which may be missing from your Windows installation. Try installing this and this. The NET desktop runtime from here if still available. Alternatively, go to the Micrsoft .NET 8.0 download page here and download and install the latest .NET Desktop Runtime X64 version. If still not resolved and the error code in your AutoFPS log file is Exception 31, you most likely have a corrupt MSFS WASM installation. First, try deleting the MSFS WASM folder, located under the Microsoft Flight Simulator directory in either %appdata% or %localappdata% for Steam and MS Store install directories respectively, which will rebuild when you next run MSFS. Rebooting is also recommended. If that doesn't fix it, a full clean reinstall of MSFS will be required per the explicit instructions in the FAQ entry here.

Nothing has changed in recent app versions re auto detecting a fixed FPS in Auto Target FPS mode. In this mode, the app will switch to AFixedFPS if recent FPS history is within a very tight tolerance (FPS must stay within ±1%, and the jitter must be extremely small: only 0.25%.) of the dominant FPS detected, but will only stay that way if it is detected that way 5 times in a row. Your experience is basically saying that at least the first assessment meet this criteria but then doesn't after that. This can happen with no fixed FPS set but the view stays constant meaning the FPS is not varying much anyway. Unfortunately, there is no way to tell the difference from a detection point of view, other than confirming that it does the same 4 more times as the app already does. Edit: Just to demonstrate what it takes to get a permanent auto fixed FPS with a real fixed FPS, here's what a run of 5 detections would need to look like: 2026-08-03 08:57:42.759 [DBG] [ LODController:DetectFixedFPS ] RawFPS: 39.8, 39.8, 39.7, 39.8, 39.8, 39.6, 39.8, 39.8, 39.5, 39.8, 39.8, 39.8, 39.8, 39.6, 39.8, 39.8, 39.7, 39.8, 39.8, 39.7 2026-08-03 08:57:42.759 [DBG] [ LODController:DetectFixedFPS ] Atmpt:1 DomFPS:40 Tol:±0.50 SD+:0.000 SDMax:0.125 In:20 Out+:0 FixedFPS:Y 2026-08-03 08:57:42.759 [DBG] [ LODController:DetectFixedFPS ] Fixed FPS detected at 40 FPS 2026-08-03 08:57:42.759 [INF] [ LODController:DetectFixedFPS ] Auto Target Fixed FPS detected at 40 FPS (override applied) 2026-08-03 08:57:42.759 [DBG] [ LODController:DetectFixedFPS ] Auto Target Fixed FPS detection 1/5: confirmed consistent at 40 FPS 2026-08-03 08:58:03.051 [DBG] [ LODController:DetectFixedFPS ] RawFPS: 39.8, 39.8, 39.7, 39.8, 39.8, 39.6, 39.8, 39.8, 39.7, 39.8, 39.8, 39.7, 39.8, 39.8, 39.6, 39.8, 39.7, 39.8, 39.8, 39.7 2026-08-03 08:58:03.051 [DBG] [ LODController:DetectFixedFPS ] Atmpt:1 DomFPS:40 Tol:±0.50 SD+:0.000 SDMax:0.125 In:20 Out+:0 FixedFPS:Y 2026-08-03 08:58:03.051 [DBG] [ LODController:DetectFixedFPS ] Fixed FPS detected at 40 FPS 2026-08-03 08:58:03.051 [DBG] [ LODController:DetectFixedFPS ] Auto Target Fixed FPS detection 2/5: confirmed consistent at 40 FPS 2026-08-03 08:58:23.343 [DBG] [ LODController:DetectFixedFPS ] RawFPS: 39.8, 39.8, 39.7, 39.8, 39.7, 39.7, 39.8, 39.8, 39.7, 39.8, 39.8, 39.7, 39.8, 39.7, 39.7, 39.8, 39.8, 39.6, 39.8, 39.8 2026-08-03 08:58:23.343 [DBG] [ LODController:DetectFixedFPS ] Atmpt:1 DomFPS:40 Tol:±0.50 SD+:0.000 SDMax:0.125 In:20 Out+:0 FixedFPS:Y 2026-08-03 08:58:23.343 [DBG] [ LODController:DetectFixedFPS ] Fixed FPS detected at 40 FPS 2026-08-03 08:58:23.343 [DBG] [ LODController:DetectFixedFPS ] Auto Target Fixed FPS detection 3/5: confirmed consistent at 40 FPS 2026-08-03 08:58:43.651 [DBG] [ LODController:DetectFixedFPS ] RawFPS: 39.7, 39.8, 39.7, 39.8, 39.8, 39.7, 39.8, 39.8, 39.7, 39.8, 39.8, 39.7, 39.8, 39.8, 39.6, 39.8, 39.8, 39.7, 39.8, 39.8 2026-08-03 08:58:43.651 [DBG] [ LODController:DetectFixedFPS ] Atmpt:1 DomFPS:40 Tol:±0.50 SD+:0.000 SDMax:0.125 In:20 Out+:0 FixedFPS:Y 2026-08-03 08:58:43.651 [DBG] [ LODController:DetectFixedFPS ] Fixed FPS detected at 40 FPS 2026-08-03 08:58:43.651 [DBG] [ LODController:DetectFixedFPS ] Auto Target Fixed FPS detection 4/5: confirmed consistent at 40 FPS 2026-08-03 08:59:03.933 [DBG] [ LODController:DetectFixedFPS ] RawFPS: 39.7, 39.8, 39.8, 39.6, 39.8, 39.6, 39.8, 39.8, 39.7, 39.8, 39.8, 39.7, 39.8, 39.8, 39.7, 39.8, 39.8, 39.7, 39.8, 39.8 2026-08-03 08:59:03.933 [DBG] [ LODController:DetectFixedFPS ] Atmpt:1 DomFPS:40 Tol:±0.50 SD+:0.000 SDMax:0.125 In:20 Out+:0 FixedFPS:Y 2026-08-03 08:59:03.933 [DBG] [ LODController:DetectFixedFPS ] Fixed FPS detected at 40 FPS 2026-08-03 08:59:03.933 [INF] [ LODController:DetectFixedFPS ] Auto Target Fixed FPS confirmed stable after 5 identical detections.

Further to this, the first 0.5.3.0 test build has been released which automatically enforces MSFS as the FPS source, regardless of whether RTSS is running or not. Also, DynFG now shows on the app status line in lieu of Man FG that was previously shown:

@kevinfirth , as promised, the first 0.5.3.0 test build is now released and reinstates the spike detection/protection. Note you must have RTSS running, spike protection enabled AND Log+ enabled for this stack panel to show:

No popped out displays on mine. It used to CTD in the past when I had RTSS running, but even with that turned off it still CTDs. Apart from testing with my app on the rare occasions it doesn't cause an MSFS CTD, I rarely use FG of any form as I mainly fly in VR where it is not applicable anyway, so no big deal.

I will do that, since I have made it so that the spike protection checkbox only ever appears if you have RTSS running anyway and could do the same for the hide-able stack panel upon which it would live, so users not using RTSS would not see it anyway. It will make it reappear in the first 0.4.3.0 test build.

@xsever , unfortunately MSFS CTDs as soon as I enable any form of FG with the Nexus mod running, so I am currently unable to assess this. Nonetheless, the underlying principle of using an NFR base for DynFG-related Target and displayed FPS in MSFS_AutoFPS should be sound as that is the lowest common denominator of any form of FG. Let me know what you discover with Nexus mod settings relating to this feature.

That would be helpful. I have the mod, but just haven't used it as I am quite happy with plain old FSR3 2X. I will give it a go now to see what I find too.

Per the readme excerpt I posted a few posts ago, when using DynFG, everything in the app is in NFR-speak so your target FPS should have been set to 29 FPS (Actually, if you are using a true Fixed 30 FPS cap, then you should be using Fixed and the target set to 30 per my last post). Regardless, the mod you are using could be the one capping your FPS to 30 if that is what you have set for its target in the mod, which would explain the 15 FPS NFR the app is showing. I believe that with the mod you should be setting your desired post-FG FPS ie 60, not the NFR FPS AutoFPS requires, so I suggest you try that. I know that it can be a bit confusing with all this NFR and post-FG speak, but the general rule is as follows: MSFS Settings - all NFR-speak. MSFS_AutoFPS - all post-FG speak, EXCEPT DynSet which is NFR-speak. Dynamic/Adaptive FG driver/mod settings - target FPS post-FG speak.

Yes it was removed from the UI as I received no feedback during the test program that anyone had tried changing that value so IMO it was not worth it taking up UI real estate. It can still be changed in the common config file per the readme description of this new feature:

I'll revise my advice to say that it depends on whether your FPS cap of 36 is a Fixed or NTE FPS, as defined in the readme FAQ as follows: If your FPS cap of 36 is Fixed, as defined above, then use Fixed Target Man 4X FG and try a target value of 136 (based on what you say the Nexus mod caps it to, not its real 144 potential). If your FPS cap of 36 is NTE, as defined above, then use Manual Target Man 4X FG and try a target value at least 5% below 136. 128, as you have suggested, should be fine. If you are still struggling with what to set, PM me the contents of the log file, located in %appdata%\MSFS_AutoFPS, of your best attempt and I will take a look.

The readme FAQ covers this as follows: ie. Select this: then this:

Alrighty then. It's a new day so I'll have another go at answering the queries from yesterday. Firstly: There were no functional changes to auto-start functionality in the app installer in 0.5.2.0 (in fact since Feb this year), so it should still be working. Just run the installer, select MSFS as the auto-start option, make sure MSFS 2024 is checked then click update. You should then see the following: To confirm it has been added correctly, open your MSFS 2024 Exe.xml file in notepad and look for an MSFS_AutoFPS auto-start entry: Start MSFS 2024 and it the app should auto-start about halfway through the loading process. If this still isn't working, please tell me specifically where in these instructions it occurs.

Sorry, I think I have mixed a few conversations together and I have confused things. It is late where I am and I am not in a position to respond properly now. I will have another go tomorrow. My apologies everyone!

Try Man FG 4X, Manual Target FPS of 125 and adjust from there. That will give it some headroom below your 136 cap and should work fine.

I am yet to come across a case where all installer options are not present. Also, auto-start has not been touched for a couple of app versions now, so nothing has changed in that regard in this latest version. You need to answer my questions re what specific installer option is missing that is not otherwise able to be exposed by clicking on the appropriate radio button before I can help you any further.

Which specific setting can you not find? The only setting you might not see is the option for auto-start for MSFS 2020 if you do not have that MSFS version installed, otherwise every other option there should be present. Make sure you click on MSFS under auto-start to expose which MSFS versions you want to apply auto-start to. If you are still not finding it, post up a screenshot of your installer window if you can.

Are you are aware that you can auto update the app, without having to first manually uninstall the old version and lose your settings, through the update options in the app when it first starts up? If not, I strongly recommend you do it that way in future. Here is what it would have shown with Prompted Updates option selected. Clicking on Yes would auto install it and keep your existing settings: In any case, what is done is done so to fix your issue all you have to do is run the 0.5.2.0 installer again and this time selection which auto-start option you want before clicking on the update button. ie for a MSFS 2024-only install with an MSFS auto-start, set it like this:

FYI, for users trying the new Dynamic FG option in 0.5.2.0, please note that you should use MSFS, not RTSS, as the FPS source as it provides the NFR FPS required for this mode. RTSS provides post-FG FPS, which will conflict with your NFR-based Target FPS. For now you will have to manually change back to MSFS if you were using RTSS as your FPS source, but only for Dynamic FG specifically. ie: This should affect very few, if any, users as you would need to be using both RTSS as FPS source and Dynamic FG together. Nonetheless, it will be automatically enforced in 0.5.3.0 when it is released in the future. The online 0.5.2.0 readme has also been updated with this advice.

MSFS_AutoFPS v0.5.2.0 has just been formally released, available either through auto update in the app or from here. My thanks goes out to all who provided valuable feedback during the test phase. This release delivers additional profile slots, profile reset capability, Dynamic/Adaptive FG support, periodic spike protection, improved VRAM+, steadier FG‑inactive behaviour, clearer UI and broad reliability fixes. Please review the release notes and the updated readme here, which provides a detailed description of the app, installation, features and settings, before asking any questions or raising any issues about this new version.

No criticism taken. In fact, I have been impressed with the level of analysis you have done with all of this. I probably wouldn't have taken this feature on if you didn't make it so easy to quantify the issue. Also, just because I will formally release 0.5.2.0 soon doesn't mean it has to be over. If it can be improved further, we can continue on in the next release test build.

No worries. I have been testing this feature quite a lot lately and, as I mentioned in a recent post, I have been on the SU6 beta and recently have been unable to reproduce this periodic spikes at all, so it looks like Asobo may fixed it just to spite my efforts to work around it 😄 Re what the RTSS frame buffer contains versus PresentMon, I cannot say for sure. You can see in the logs that the app now does a dump of the first 10 seconds of frame time data whenever you switch graphics mode, so you can perhaps see for yourself eg: 2026-07-27 20:43:28.601 [DBG] [ ServiceController:GetRTSSFrameTi ] BufPos:87 FrameTimesCSV:16605,16886,16630,16570,16641,16873,16659,16690,16577,16541,16625,16893,16621,16696,16614,16390,16722,16967,16581,16631,16582,16714,16664,16489,16853,16740,16592,16517,16621,16913,16601,16691,16618,16775,16625,16708,16571,16718,16582,16597,16702,16837,16544,16728,16622,16682,16718,16744,16586,16657,16616,16712,16648,16699,16644,16693,16600,16472,16651,16866,16576,16743,16613,16688,16604,16902,16651,16445,16665,16813,16662,16542,16657,16728,16716,16520,16680,16681,16736,16680,16498,16592,16629,16890,16697,16683,16658,16826,16672,16573,16706,16715,16632,16558,16652,16841,16581,16788,16637,16640,16688,16474,16594,16975,16622,16531,16715,16543,16576,16808,16589,16807,16637,16559,16632,16920,16631,16553,16642,16667,16628,16487,16663,16878,16646,16714,16774,16340,16802,16765,16728,16625,16658,16729,16615,16576,16648,16845,16500,16904,16587,16677,16625,16399,16772,16854,16642,16651,16620,16853,16578,16662,16616,16720,16630,16757,16617,16671,16637,16595,16658,16735,16690,16602,16644,16440,16669,16486,16589,16554,16629,16500,15977,15863,16249,16167,16224,16166,16217,16211,16221,16143,16195,16253,16253,16218,16088,16345,15901,16470,15935,16568,16691,27128,16661,16784,16655,16580,16637,16922,16576,16688,16606,16592,16610,16914,16595,16509,16606,16948,16570,16751,16585,16688,16629,16771,16568,16735,16626,16526,16619,16718,16600,16878,16617,16607,16608,16635,16747,16713,16626,16542,16646,16779,16613,16786,16638,16731,16630,16610,16597,16797,16620,16557,16668,16619,16721,16859,16584,16586,16625,16818,16597,16670,16763,16474,16673,16774,16638,16796,16581,16584,16643,16816,16645,16779,16611,16674,16605,16611,16566,16765,16603,16811,16604,16612,16627,16891,16586,16721,16546,16709,16595,16815,16571,16507,16590,16478,16655,17061,16654,16445,16818,16488,16671,16600,16731,16541,16663,16617,16756,16573,16615,16797,16662,16587,16767,16801,16650,16573,16687,16630,16679,17053,16637,16605,16644,16782,16659,16791,16591,16631,16630,16487,16730,16782,16616,16840,16592,16699,16621,16578,16719,16736,16593,16720,16570,16668,16599,16722,16606,16738,16604,16696,16613,16594,16693,16566,16645,16608,16646,16635,16646,16599,16607,16726,16711,16305,16710,16931,16768,16746,16675,16793,16751,16635,16692,16541,16831,16664,16662,16585,16695,16597,16869,16304,16872,16837,16661,16550,16716,16513,16683,16343,17112,16758,16715,16591,16669,16627,16689,16778,16670,16339,16750,16492,16856,16530,16877,16484,16684,16597,16865,16451,16878,16580,16813,16573,16823,16510,16667,16647,16762,16595,16683,16677,16612,16686,16672,16780,16646,16525,16701,16660,16733,16702,16690,16552,16646,16564,16756,16757,16529,16920,16630,16674,16647,16690,16637,16556,16541,16813,16708,16357,16814,16832,16559,16611,16841,16675,16644,16800,16661,16672,16640,16536,16614,16873,16618,16537,16587,16928,16644,16594,16638,16565,16667,16837,16641,16726,16628,16603,16697,16554,16689,16780,16648,16571,16720,16558,16642,16667,16828,16535,16806,16496,16757,16672,16702,16651,16658,16766,16620,16593,16707,16469,16814,16710,16663,16631,16593,16810,16648,16490,16841,16576,16624,16763,16766,16419,16633,16946,16557,16658,16632,16432,16626,16390,16656,16413,16595,16459,16574,16483,16593,16359,16670,16460,16632,16394,16635,16354,16699,16488,16597,16489,16641,16213,16862,16507,16660,16427,16614,16567,16174,16177,16304,16310,16483,16553,16469,16502,16483,16532,16369,16410,16210,16223,16042,16141,16000,16201,15656,16232,15983,16446,15679,16348,14775,14759,14037,14039,15383,15167,15577,15186,15825,15366,15847,15512,15910,15626,15952,15750,15954,15702,16063,15722,16963,16554,17717,65958,16715,16474,16927,16822,16620,16548,16719,16803 From what I have observed, this frame time buffer captures FG frames too because when using nVidia FG every other frame is a really low value, sometimes zero.

Just as I was about to formally release 0.5.2.0! 😄 I am looking through your data now but the quick answer is that while recovery is gated by a minimum time, it is distance, altitude and vertical speed trend that determine the recovery rate. ie: Minimum activation conditions: step stays at 0 until 30 s have elapsed, distance has grown past 1.5 NM, altitude has risen above the mode‑specific base (500 ft or AltTLODBase), and vertical trend is level flight, so all factors begin contributing. Maximum activation conditions: step reaches its full value only after 30 s, distance reaches 5 NM, altitude reaches 3000 ft or AltTLODTop, and vertical trend is a continuous climb, allowing all factors to hit 1.0 and maximise the step multiplier. I can increase these thresholds if you like, but it looks to me as it was actually working quite well, especially if you didn't even get long enough to notice the periodic stutters. The issue with increasing them too much is that you could be missing out on available TLOD range. Re: The log shows that while there were spikes in that 100 second time frame, none met the the periodic spike criteria (4+ fresh spikes > 2x of median frame time and the same 0.3-1.8s cadence) until 21:04:26 when they did. This is most likely because most of the spikes you were seeing were below 2x median frame time, wherever you were reading them from. You can reduce that threshold in the common config file (SpikeThresholdMultiplier key) but just be aware that you were the one who had me increase it to 2x as a default as it was triggering too often in earlier iterations of this feature, so chose your poison wisely. FWIW, my own observation is that 2x is just right as there is negligible stuttering when they are just below that - it is the big ones that cause observable stuttering.