Reset XPDR

A bit of progress today of MSFS periodic frame time spike detection. Turns out that the spikes are around, not at 1Hz, and can vary by+-0.2Hz. Also, on my system at least, it is really hard to get these spikes to trigger, with me having to resort to 1000+ TLOD to get it there, which often overflows my VRAM at that level even with 24GB available. Nonetheless, I seem to be able to detect the spikes, as evidenced in the following test log which shows TLOD increasing from 680 through to 900, at which point the spikes appear in the RTSS graph and are detected by the app: 2026-06-28 14:52:07.494 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 0, Periodic: False, AvgInterval: 0.00s, StdDev: 0.00 2026-06-28 14:52:08.513 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 0, Periodic: False, AvgInterval: 0.00s, StdDev: 0.00 2026-06-28 14:52:08.519 [INF] [ LODController:RunTick ] VRAM Limiting Inactive 2026-06-28 14:52:09.532 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 0, Periodic: False, AvgInterval: 0.00s, StdDev: 0.00 2026-06-28 14:52:10.549 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 0, Periodic: False, AvgInterval: 0.00s, StdDev: 0.00 2026-06-28 14:52:11.567 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 0, Periodic: False, AvgInterval: 0.00s, StdDev: 0.00 2026-06-28 14:52:11.572 [INF] [ LODController:UpdateVariables ] Mode:NFR FPS:30 Pri:TLOD+ 680 TLOD:730 TLODRng:50-2000 OLOD:200 AGL:16 FPM:0 GPU:53% VRAM:95% 2026-06-28 14:52:12.581 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 0, Periodic: False, AvgInterval: 0.00s, StdDev: 0.00 2026-06-28 14:52:13.602 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 0, Periodic: False, AvgInterval: 0.00s, StdDev: 0.00 2026-06-28 14:52:14.623 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 0, Periodic: False, AvgInterval: 0.00s, StdDev: 0.00 2026-06-28 14:52:15.643 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 0, Periodic: False, AvgInterval: 0.00s, StdDev: 0.00 2026-06-28 14:52:16.666 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 0, Periodic: False, AvgInterval: 0.00s, StdDev: 0.00 2026-06-28 14:52:17.690 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 0, Periodic: False, AvgInterval: 0.00s, StdDev: 0.00 2026-06-28 14:52:18.714 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 0, Periodic: False, AvgInterval: 0.00s, StdDev: 0.00 2026-06-28 14:52:19.733 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 0, Periodic: False, AvgInterval: 0.00s, StdDev: 0.00 2026-06-28 14:52:20.752 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 0, Periodic: False, AvgInterval: 0.00s, StdDev: 0.00 2026-06-28 14:52:21.770 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 0, Periodic: False, AvgInterval: 0.00s, StdDev: 0.00 2026-06-28 14:52:21.776 [INF] [ LODController:UpdateVariables ] Mode:NFR FPS:30 Pri:TLOD+ 752 TLOD:802 TLODRng:50-2000 OLOD:200 AGL:16 FPM:-0 GPU:60% VRAM:94% 2026-06-28 14:52:22.793 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 0, Periodic: False, AvgInterval: 0.00s, StdDev: 0.00 2026-06-28 14:52:23.815 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 0, Periodic: False, AvgInterval: 0.00s, StdDev: 0.00 2026-06-28 14:52:24.844 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 0, Periodic: False, AvgInterval: 0.00s, StdDev: 0.00 2026-06-28 14:52:25.866 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 0, Periodic: False, AvgInterval: 0.00s, StdDev: 0.00 2026-06-28 14:52:26.888 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 0, Periodic: False, AvgInterval: 0.00s, StdDev: 0.00 2026-06-28 14:52:27.906 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 0, Periodic: False, AvgInterval: 0.00s, StdDev: 0.00 2026-06-28 14:52:28.927 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 2, Periodic: False, AvgInterval: 0.00s, StdDev: 0.00 2026-06-28 14:52:29.949 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 1, Periodic: False, AvgInterval: 0.00s, StdDev: 0.00 2026-06-28 14:52:30.968 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 1, Periodic: False, AvgInterval: 0.00s, StdDev: 0.00 2026-06-28 14:52:31.988 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 1, Periodic: False, AvgInterval: 0.00s, StdDev: 0.00 2026-06-28 14:52:31.993 [INF] [ LODController:UpdateVariables ] Mode:NFR FPS:29 Pri:TLOD+ 852 TLOD:902 TLODRng:50-2000 OLOD:200 AGL:16 FPM:-0 GPU:55% VRAM:94% 2026-06-28 14:52:33.006 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 1, Periodic: False, AvgInterval: 0.00s, StdDev: 0.00 2026-06-28 14:52:34.024 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 3, Periodic: False, AvgInterval: 2.64s, StdDev: 2.45 2026-06-28 14:52:35.043 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 4, Periodic: False, AvgInterval: 2.15s, StdDev: 2.11 2026-06-28 14:52:36.063 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 5, Periodic: False, AvgInterval: 1.89s, StdDev: 1.89 2026-06-28 14:52:37.090 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 6, Periodic: False, AvgInterval: 1.76s, StdDev: 1.71 2026-06-28 14:52:38.111 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 5, Periodic: True, AvgInterval: 1.21s, StdDev: 0.08 2026-06-28 14:52:39.129 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 6, Periodic: True, AvgInterval: 1.12s, StdDev: 0.13 2026-06-28 14:52:40.148 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 7, Periodic: True, AvgInterval: 1.12s, StdDev: 0.13 2026-06-28 14:52:41.172 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 8, Periodic: True, AvgInterval: 1.12s, StdDev: 0.13 2026-06-28 14:52:42.199 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 9, Periodic: True, AvgInterval: 1.12s, StdDev: 0.13 2026-06-28 14:52:42.205 [INF] [ LODController:UpdateVariables ] Mode:NFR FPS:26 Pri:TLOD+ 908 TLOD:958 TLODRng:50-2000 OLOD:200 AGL:16 FPM:-0 GPU:59% VRAM:95% 2026-06-28 14:52:43.219 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 10, Periodic: True, AvgInterval: 1.12s, StdDev: 0.13 2026-06-28 14:52:44.240 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 10, Periodic: False, AvgInterval: 0.95s, StdDev: 0.34 2026-06-28 14:52:45.264 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 10, Periodic: False, AvgInterval: 0.96s, StdDev: 0.34 2026-06-28 14:52:46.284 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 9, Periodic: False, AvgInterval: 0.95s, StdDev: 0.34 2026-06-28 14:52:47.305 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 9, Periodic: False, AvgInterval: 0.97s, StdDev: 0.35 2026-06-28 14:52:48.323 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 10, Periodic: False, AvgInterval: 1.04s, StdDev: 0.36 2026-06-28 14:52:49.346 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 9, Periodic: True, AvgInterval: 1.20s, StdDev: 0.07 2026-06-28 14:52:49.353 [INF] [ LODController:RunTick ] VRAM Limited Hold Activated @ 96% 2026-06-28 14:52:50.364 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 9, Periodic: True, AvgInterval: 1.17s, StdDev: 0.10 2026-06-28 14:52:51.386 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 10, Periodic: True, AvgInterval: 1.17s, StdDev: 0.10 2026-06-28 14:52:52.405 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 9, Periodic: False, AvgInterval: 0.96s, StdDev: 0.38 2026-06-28 14:52:52.415 [INF] [ LODController:UpdateVariables ] Mode:NFR FPS:25 Pri:TLOD+ 942 TLOD:992 TLODRng:50-2000 OLOD:200 AGL:16 FPM:-0 GPU:59% VRAM:96% LTD 2026-06-28 14:52:53.430 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 9, Periodic: False, AvgInterval: 0.97s, StdDev: 0.39 2026-06-28 14:52:54.455 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 9, Periodic: False, AvgInterval: 0.98s, StdDev: 0.39 2026-06-28 14:52:55.479 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 9, Periodic: False, AvgInterval: 0.98s, StdDev: 0.39 2026-06-28 14:52:56.499 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 9, Periodic: False, AvgInterval: 1.02s, StdDev: 0.40 2026-06-28 14:52:57.522 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 9, Periodic: True, AvgInterval: 1.22s, StdDev: 0.01 2026-06-28 14:52:58.542 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 8, Periodic: True, AvgInterval: 1.22s, StdDev: 0.01 2026-06-28 14:52:59.563 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 8, Periodic: True, AvgInterval: 1.21s, StdDev: 0.01 2026-06-28 14:53:00.579 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 8, Periodic: True, AvgInterval: 1.22s, StdDev: 0.01 2026-06-28 14:53:01.601 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 8, Periodic: True, AvgInterval: 1.22s, StdDev: 0.00 2026-06-28 14:53:02.619 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 8, Periodic: True, AvgInterval: 1.21s, StdDev: 0.00 2026-06-28 14:53:03.630 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 9, Periodic: True, AvgInterval: 1.21s, StdDev: 0.00 2026-06-28 14:53:04.641 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 8, Periodic: True, AvgInterval: 1.22s, StdDev: 0.00 2026-06-28 14:53:05.653 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 8, Periodic: True, AvgInterval: 1.21s, StdDev: 0.00 2026-06-28 14:53:06.671 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 8, Periodic: True, AvgInterval: 1.24s, StdDev: 0.05 2026-06-28 14:53:07.690 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 8, Periodic: True, AvgInterval: 1.22s, StdDev: 0.06 2026-06-28 14:53:08.710 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 8, Periodic: True, AvgInterval: 1.22s, StdDev: 0.06 2026-06-28 14:53:09.730 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 9, Periodic: True, AvgInterval: 1.22s, StdDev: 0.06 2026-06-28 14:53:10.748 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 8, Periodic: True, AvgInterval: 1.23s, StdDev: 0.06 2026-06-28 14:53:11.768 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 8, Periodic: True, AvgInterval: 1.23s, StdDev: 0.06 2026-06-28 14:53:12.791 [DBG] [ ServiceController:UpdateAverageF ] Spikes: 8, Periodic: True, AvgInterval: 1.20s, StdDev: 0.03 What it looks like graphically when the spikes are steady state @ 966 TLOD. Anyway, a bit of progress but still far from being reliable.

I agree that would be useful. Despite nothing coming to mind right now of how to do that, I will keep thinking about a potential solution. At least we are now aware that when this issue occurs, backing TLOD down for that particular flight phase eradicates it. Edit: It turns out that the RTSS interface I am using does support frame time buffer dumps of the last 1024 entries, but it just wasn't enabled. I have managed to expose it to AutoFPS, which is good news. Turning it into something that can reliably interpret 1Hz spikes without being fooled by other spikes will be a bit trickier but should be possible. I'll keep you posted on any major progress I make.

AutoFPS does work on two asynchronous 1Hz cycles, one for the automation logic and one for the UI display updating, but I can get those 1Hz spikes in MSFS if I set the TLOD high enough, beyond what is settable in MSFS settings eg 1000, in the UserCfg.opt file and not have AutoFPS running. Also, if you are not seeing any changing values in AutoFPS when these spikes occur, which it looks like you weren't with your TLOD sitting at TLOD max and being displayed green, then AutoFPS is not injecting anything into MSFS and hence is likely not the cause. You are using FreeTLOD with a high TLOD max and a complex aircraft at a complex airport surrounded by complex photogrammetery, so I would say your AutoFPS settings are too aggressive for this scenario. I would be using TLOD Min 50 and TLOD Extra, not Free TLOD, here and limiting it to TLOD 100 (ie. x2 multiplier) for better results on the ground here. I'd have to think about this some more but my gut feeling is no as the app doesn't have access to 1% low FPS like RTSS can produce and I'm not sure how I would use this without dumbing down the experience for everyone for what is really an edge case that could easily be spoofed by quick view changes.

I set it in the VD PC app settings here: You can see I also adjust horizontal and vertical FOV tangent, as this is not visually noticeable to me and offsets some of the render resolution increase from the VDXR render resolution. Warning, setting VDXR render resolution to 150% in conjunction with all my other settings sees my GPU load and VRAM use in the region of 80-95%. While a 5080 is roughly the performance equivalent of a 4090, it only has two thirds the VRAM hence it is very likely my specific settings will overflow VRAM on any GPU with 16GB VRAM or less and make performance unacceptable. The point I am trying to make with posting my settings is that it is possible to even further improve the default visual quality of the Quest 3 for a given FPS target but it requires tuning those settings to your specific hardware and supporting apps. Even at default settings, the Quest 3 has very good image quality so I would not worry if your system is unable to push it much past that, particularly since it is in the region of diminishing returns. Oh and yes I use FFV in MSFS, set to the default 50.

I have a BoboVR S2 and originally used batteries with it until i got sick of having to charge everything. Now for flight simming I just use the S2 as a head strap and don't even put the battery on the back and instead run a 90 degree USB cable to the Quest 3 power port and plug that into a phone charger. I don't even turn the headset off, just letting it sleep when no in use and instantly powering back on when I put the headset on. I has been fine like that for over two years now.

I am not familiar with the Pimax eco system but it is entirely possible you are already super sampling because what many headsets call 100% render resolution is actually a super sampled resolution. Nonetheless, I would just leave it if you are happy with what you are currently getting visual quality-wise, especially since the Crystal is higher resolution to start with. I am pretty sure nVidia SmoothMotion is a 2D-only feature. I tried it myself a while back and while it doubles the FPS of the mirrored VR image on my monitor, it does not double it in the headset, which you can verify by turning on the FPS overlay in OpenXR Toolkit. The Crystal light does have Smart Smoothing and Lock to Half Framerate for motion smoothing but from what I have read and from what Pimax users I know have told me, it is not very good (stuttering and artifacts) and I don't know anyone that actually uses it.

I specifically mention render resolution just a few words before what you quoted. It is called super sampling, which is rendering the scene at a higher‑than‑native resolution and downscaling it to produce a sharper image while also helping in VR counteract barrel‑distortion stretching at the edges of the lenses. eg. even without the extra scaling I am using, default godlike render resolution in Virtual Desktop for the Quest 3 is 3072 × 3216 pixels per eye. I run it higher because I have spare performance capacity with my GPU and it slightly improves visual quality over godlike.

Render resolution != hardware resolution

I use a Quest 3 with the specs in my signature. It connects to my PC via a dedicated FAST5393LTE-A (dual-band Wi-Fi 6) router with the Quest 3 being the only device connected by Wi-Fi through Virtual Desktop (VD) and an Ethernet connection from it goes to my PC. This router is connected by Ethernet to another FAST5393LTE-A which in turn is connected to my fibre optic internet and supplies the Wi-Fi connection to many other devices in my house (10+). I get great VR results with this hardware setup. I run MSFS 2024 at default high graphics settings and DLSS 4.5 Balanced Preset M. I have VD set to max bitrate AV1, which it has no problem maintaining smoothly at all times, with godlike render resolution with 150% scaling, giving me roughly 4000x4000 per eye that, combined with my DLSS settings, gives about the best clarity possible from the Quest 3 while maintaining 40 FPS locked (to give 80 FPS with SSW) and up to 400 TLOD with AutoFPS. While you won't be able to run as high a render scale as I do with your hardware, and may even need to drop back to 36/72 FPS for consistent performance, you should still be able to get a good result with a Quest 3. Of course, there are other options out there with higher resolution panels, but the price and PC hardware requirements go up significantly. IMO the Quest 3 is excellent value for money, has the best motion re-projection I have ever used, and works very well on older, but still respectable, hardware.

If by "recovery" option, you mean something that resets all settings in the app, just rerun the installer, select Reset Configs then Update. Warning, this will reset all app profiles to default for MSFS 2020 and 2024, not just the current profile, so make sure you really want to do this. Start Max is shown here: It defaults to disabled, so if you are unaware of it you likely don't have it enabled. Just leave it unchecked and set a reasonable TLOD min and you should be right.

If you are using the Start Max option in the app, then yes your FPS could start lower because of the higher starting level of TLOD. If not using that option and your FPS drops, that implies your minimum TLOD is too high and should be no different than if you manually set this TLOD in MSFS without using this app. Dynamic Settings may not decrease your FPS because it is brutally fast at butchering both TLOD and OLOD, so choose your poison wisely.

A slight change to my recommended settings when using AutoFPS 0.5.1.0, not because of SU5 but because of recent changes to AutoFPS: For your particular configuration, I would try using an FPS cap setup and set max frame rate in MSFS to 30, dynamic settings to 30 and Fixed Target FSR3 FPS to 60 in FPS Sensitivity mode.

Notwithstanding that MSFS is quite happy to CTD all of its own accord and is therefore the most likely explanation. I see from the associated log you sent me via PM that you were changing a few AutoFPS TLOD Base and Top settings just before the CTD, the last of which was selecting Fixed as the TLOD Base option about 10 seconds before the CTD. These changes should have done nothing more than vary TLOD in MSFS, which the app does all the time anyway, so should not have been the cause of the CTD. I ran a test with your settings and attempted to recreate your final settings change sequence and was not able to trigger a CTD, despite changing AutoFPS settings repeatedly for a couple of minutes, so I do still think it is just coincidence that a CTD happened for you. FYI, I note that the last setting you tried to change was the TLOD Base option, which can only ever be set to Fixed when using Auto Target FPS, as at least one parameter must be fixed to vary the other. In the next version of the app, likely to be released as a test version when the SU6 beta makes an appearance, the TLOD Base option will be removed from the UI when you are using Auto Target FPS as Fixed TLOD Base is forced anyway. eg.

Your AutoFPS settings look fine to me. The only thing I would suggest is running GPU-Z as a companion app, so that GPU load and VRAM usage is reported to the app, then enable VRAM+ in the app to protect you from potential VRAM overflows. Instructions for where to download and how to configure GPU-Z correctly to work with the app are contained within the readme.

Your new screenshot still shows the app is set to FG 2X. Set it to Auto, then after loading into a flight, take a screenshot to show that you have correctly configured it. Also, you haven't told me what FG are you using and exactly where are you setting it. Please advise. Re: When FG is inactive, TLOD can still decrease (but not increase, as the FG inactive GPU load is not the same as the FG active load) if you are not achieving the NFR of the target FG FPS you have set. In your case, you have set 72 FPS for the target FG FPS, in which case 36 is the NFR of that when FG is inactive so if you get less than 36 FPS then your TLOD will drop. Is this what is happening? The only real way I can tell what is going on is by looking at your log. If you can extract a small snippet like I did above then you can post here, otherwise send me the contents of the whole log in a PM so as not to clutter up this discussion. BTW, you don't have to wait until you have finished a flight to extract the snippet. It is only an unlocked text file so you can do it while the app and your flight is running.

I think you are referring to TLOD not FPS. In any case, the TLOD you can achieve in non-expert mode is based on your default MSFS TLOD. which must be low if you are only getting 90 max, whereas in expert mode you have set TLOD max to 400, so that is what you are able to achieve. If you want higher TLOD in non-expert mode, change your default MSFS TLOD to something higher than what is currently set to either not in a flight or with AutoFPS not running.

It is by design, has always been that way and is mentioned in the last bullet point for Auto Target FPS in the Readme. In short, Auto Target FPS and TLOD Extra are mutually exclusive as the former needs a fixed TLOD when it calculates the target FPS and vice versa. Free is just an extension Extra, hence it is excluded too. Edit: I concur the readme is not really explicit with the current implementation that include Free TLOD, so I have updated it as follows: Auto settings reduction and TLOD Base Extra and Free are mutually exclusive with Auto Target FPS, hence are not selectable. Fixed TLOD must be used.

Yes. AutoFPS is responding as it should. What you observe it is not actually an issue specific to MSFS, rather it is how nVidia FG behaves with any game. The difference with MSFS is that we often don't run the game exclusively, often switching focus to supporting apps while flying, whereas most other games when you are in the game, you stay in the game until you quit it, making it seem like FG is active all the time when it is only so because the game always has the focus.

I am not really able to tell from your screenshot that the issue you report is present because the settle timer still has two seconds on it, hence no automation is currently active and likely has not even started yet, and while your TLOD value is shown in orange, it does not have a down arrow next to it hence it is showing a fixed, not reducing value and 0.5.0.0 shows that to indicate that TLOD is currently limited because FG is inactive. Nonethless, I have tried to recreate your issue with 0.5.0.0 and your specific settings and, after letting FPS settle and allowing TLOD to climb to its maximum level with MSFS having the focus, I cannot get TLOD to reduce when clicking away from the MSFS window eg. It could possibly be the type of FG you are using, because when configuring the app with your settings I note that you are using manual FG X2 and not Auto, which detects MSFS-set FG. What FG are you using and exactly where are you setting it? BTW, you are using Fixed Target FPS, which has been significantly improved in the just-released 0.5.1.0 update, so I strongly suggest you update to that version. It will also be the baseline version to which I will be making any fixes should I be able to recreate your issue. Once you have updated to 0.5.1.0, try it again, start a flight, let the settle timer finish, let TLOD increase as high as it will go for your current altitude, click away from MSFS and it you see TLOD decreasing (ie. not just orange but the number decreasing and a down arrow to the right of it), take a screenshot and post that here. Also, could you go into your associated log file, located in %appdata%\MSFS_AutoFPS\log, and post the snippet of where you did this. eg. here is my snippet showing TLOD increasing up to 300 at cruise with FG active (2X shows), then staying at 300 when FG is inactive (1X shows), then back again to FG being active and still holding TLOD at 300 ie. I do not see TLOD decrease when MSFS loses focus: 2026-05-14 08:30:51.356 [INF] [ LODController:UpdateVariables ] Mode:Man FG 2X FPS:72 Pri:FPS TLOD:68 TLODRng:68-300 Mtns+:0 OLOD:20 AGL:37357 FPM:478 GPU:53% VRAM:67% 2026-05-14 08:31:01.503 [INF] [ LODController:UpdateVariables ] Mode:Man FG 2X FPS:72 Pri:FPS+ 42 TLOD:108 TLODRng:108-300 Mtns+:0 OLOD:20 AGL:37421 FPM:318 GPU:54% VRAM:67% 2026-05-14 08:31:10.636 [DBG] [ LODController:DetectFixedFPS ] Fixed FPS detected at 72 FPS 2026-05-14 08:31:11.649 [INF] [ LODController:UpdateVariables ] Mode:Man FG 2X FPS:72 Pri:FPS+ 66 TLOD:148 TLODRng:132-300 Mtns+:0 OLOD:20 AGL:37460 FPM:175 GPU:54% VRAM:67% 2026-05-14 08:31:21.826 [INF] [ LODController:UpdateVariables ] Mode:Man FG 2X FPS:72 Pri:FPS+ 66 TLOD:188 TLODRng:132-300 Mtns+:0 OLOD:20 AGL:37475 FPM:27 GPU:53% VRAM:67% 2026-05-14 08:31:31.986 [INF] [ LODController:UpdateVariables ] Mode:Man FG 2X FPS:72 Pri:FPS+ 66 TLOD:205 TLODRng:132-300 Mtns+:0 OLOD:20 AGL:37464 FPM:-130 GPU:55% VRAM:63% 2026-05-14 08:31:42.159 [INF] [ LODController:UpdateVariables ] Mode:Man FG 2X FPS:72 Pri:FPS+ 66 TLOD:225 TLODRng:132-300 Mtns+:0 OLOD:20 AGL:37425 FPM:-298 GPU:57% VRAM:63% 2026-05-14 08:31:52.318 [INF] [ LODController:UpdateVariables ] Mode:Man FG 2X FPS:72 Pri:FPS+ 66 TLOD:245 TLODRng:132-300 Mtns+:0 OLOD:20 AGL:37355 FPM:-503 GPU:56% VRAM:63% 2026-05-14 08:32:02.491 [INF] [ LODController:UpdateVariables ] Mode:Man FG 2X FPS:72 Pri:FPS+ 66 TLOD:265 TLODRng:132-300 Mtns+:0 OLOD:20 AGL:37290 FPM:-114 GPU:56% VRAM:63% 2026-05-14 08:32:12.658 [INF] [ LODController:UpdateVariables ] Mode:Man FG 2X FPS:72 Pri:FPS+ 66 TLOD:285 TLODRng:132-300 Mtns+:0 OLOD:20 AGL:37384 FPM:960 GPU:58% VRAM:64% 2026-05-14 08:32:22.827 [INF] [ LODController:UpdateVariables ] Mode:Man FG 2X FPS:72 Pri:FPS+ 66 TLOD:300 TLODRng:132-300 Mtns+:0 OLOD:20 AGL:37588 FPM:1209 GPU:53% VRAM:64% 2026-05-14 08:32:32.970 [INF] [ LODController:UpdateVariables ] Mode:Man FG 1X FPS:36 Pri:FPS+ 66 TLOD:300 TLODRng:132-300 Mtns+:0 OLOD:20 AGL:37724 FPM:416 GPU:44% VRAM:64% 2026-05-14 08:32:43.150 [INF] [ LODController:UpdateVariables ] Mode:Man FG 1X FPS:36 Pri:FPS+ 66 TLOD:300 TLODRng:132-300 Mtns+:0 OLOD:20 AGL:37684 FPM:-642 GPU:44% VRAM:64% 2026-05-14 08:32:53.299 [INF] [ LODController:UpdateVariables ] Mode:Man FG 1X FPS:36 Pri:FPS+ 66 TLOD:300 TLODRng:132-300 Mtns+:0 OLOD:20 AGL:37521 FPM:-1044 GPU:38% VRAM:64% 2026-05-14 08:33:03.443 [INF] [ LODController:UpdateVariables ] Mode:Man FG 1X FPS:36 Pri:FPS+ 66 TLOD:300 TLODRng:132-300 Mtns+:0 OLOD:20 AGL:37391 FPM:-467 GPU:39% VRAM:64% 2026-05-14 08:33:13.588 [INF] [ LODController:UpdateVariables ] Mode:Man FG 1X FPS:36 Pri:FPS+ 66 TLOD:300 TLODRng:132-300 Mtns+:0 OLOD:20 AGL:37413 FPM:522 GPU:40% VRAM:64% 2026-05-14 08:33:23.734 [INF] [ LODController:UpdateVariables ] Mode:Man FG 1X FPS:36 Pri:FPS+ 66 TLOD:300 TLODRng:132-300 Mtns+:0 OLOD:20 AGL:37561 FPM:997 GPU:39% VRAM:64% 2026-05-14 08:33:33.910 [INF] [ LODController:UpdateVariables ] Mode:Man FG 1X FPS:36 Pri:FPS+ 66 TLOD:300 TLODRng:132-300 Mtns+:0 OLOD:20 AGL:37700 FPM:592 GPU:39% VRAM:64% 2026-05-14 08:33:42.070 [INF] [ ServiceController:ResetAverageFP ] Average FPS reset to initial state 2026-05-14 08:33:51.210 [INF] [ LODController:UpdateVariables ] Mode:Man FG 2X FPS:72 Pri:FPS+ 66 TLOD:300 TLODRng:132-300 Mtns+:0 OLOD:20 AGL:37644 FPM:-720 GPU:54% VRAM:64% Edit: Here is that data shown graphically to make it clearer what I observed: If you are unable to locate such a snippet, just PM me the entire contents of your log file and I will look for it.

The update options are only present until you start your first flight session, and has been that way since the app was created. If you start the app while in a flight already, that upgrade window can be less than 30 seconds before it locks on to your flight, so the best way to see those updates is to not be in a flight when you start the app. Better yet, if you choose Prompted or Silent Updates then the app will auto update within seconds of starting without you having to ever worry about catching it.

MSFS_AutoFPS v0.5.1.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. TL;DR - Fixed Target FPS automation is better + some other fixes/improvements. This release delivers major upgrades to Fixed Target FPS TLOD automation, with redesigned increase and decrease paths, smoother trend and peak handling, and a significantly improved reduction model that reacts more cleanly and consistently to FPS changes. It also provides comprehensive fixes to restore correct VRAM+ reduction behaviour, changes TLOD‑Halved‑at‑Night to no longer limit the lower TLOD range, uses a darker orange for changing sim values to improve readability and updates the installer to improve robustness and user experience.

RTSS is only an alternative FPS source, and lately has not been very reliable, so you definitely don't need that one. GPU-Z is optional if you want protection for when VRAM is going to overflow. Auto Target FPS will detect whether you have an FPS cap set somewhere or not and will configure accordingly, so no real need to worry about that. The basic rule for using Dynamic Settings with AutoFPS is to set it 5-10 FPS below what your system normally achieves in poor performance conditions ie. it acts as a safety net if AutoFPS reductions alone are not enough stem a big performance drop. As always, the lovingly-crafted Readme covers all this is much more detail, so I suggest you read that too.

You can easily join any test program that is running by simply selecting Test+ as the upgrade channel option when you start the app, where you will either be notified or auto upgraded to the latest version depending on which upgrade option you have chosen to the left of it. While you can post your feedback on test versions here, it is preferable that you do so over in the discussion section for the respective test release over on github, so as not to clutter up this discussion thread that is mainly about formal releases. The link to the discussion for the 0.5.0.1 test version is here.

GPUs are designed to run continuously at max load in games with no ill effect, and your Quest 3 is quite happy to gobble the results of that up to give you the best visuals possible, so I wouldn't be too worried about it. If you really want to reduce it, I suggest you set an FPS cap slightly lower than what your system generally achieves, which will give your GPU some breathing room between frames. From an AutoFPS perspective, if it is high TLODs causing the high GPU loads, then reduce your TLOD Min and Max as appropriate.

I responded to this yesterday but it seems to have disappeared. In any case, I basically said that with the settings you are using, AutoFPS should not be changing any settings between the start of your takeoff roll and getting to Alt TLOD Base, as it has a critical flight phase settings lockout active at this time, so AutoFPS is likely not the cause. The exception to this is if you are using AutoFPS's MSFS peformance optimiser feature, which can cause performance/stuttering issues on some systems (and now comes with a warning message about this possibility when you first enable or renable the feature). If so, try turning that feature off and see if it resolves it. If that isn't it, try a flight without AutoFPS running and TLOD set manually in MSFS to 50. If it still stutters as before, then AutoFPS is definitely not the droid you are looking for and you will need to look for something else on your system causing this. Edit: LOL, just as I post this my original response reappears here. Oh well, you now have two responses you can choose from 😄