Reset XPDR

Coincident with MSFS 2024 SU7 formal release today, MSFS_AutoFPS v0.5.4.4 has also 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 re-baselines MSFS 2024 support for the Sim Update 7 (SU7) formal release and SU8 beta, incorporates bundled SimConnect v1.8.1 library updates, delivers comprehensive In-Game Widget usability and window management enhancements for both 2D and VR, and resolves a false pause detection issue with Optical Flow OpenXR (OFXR). It also introduces an exit confirmation prompt for deferred auto-updates to prevent missed installations when exiting while MSFS is still running.

You will get a laugh out of this! Literally minutes before I was about to hit the publish button on the 0.5.4.4 formal release today, I stumbled headfirst into the exact same bug myself. It turned out to be a very sneaky log-parsing quirk. When checking whether OFXR is currently paused, AutoFPS reads the OFXR Bridge lifecycle log backwards from the bottom of the file. If the bridge had restarted or re-armed without you ever hitting pause or resume in that new session, the parser happily kept reading backwards in time right past the bridge startup boundary. It then latched onto an old "pause OK" from an earlier session sitting further up in the log from hours ago, and falsely decided OFXR was paused! Toggling pause on and off straightened it out for you because it forced the bridge to write a fresh "resume OK" at the very bottom of the log for AutoFPS to find. I have now added startup, cleanup, and disarm boundaries to the parser so it stops scanning once it reaches the current bridge session. The fix is baked right into the 0.5.4.4 release coming out shortly, so neither of us will have to play the pause-toggle game again. Thanks for reporting it, you saved me from a massive post-release headache!

If you mean what do you set specifically for your VR flying using OFXR, then set Fixed OFXR Target FPS at 72 in the app before you go into VR and it should auto detect OFXR 2X when you switch to VR. Re locking your FPS, I believe that the OFXR dev says to not use an FPS lock, but I have used one with it with no harm. If you do set one, I'd set it in MSFS under the Max Frame setting rather than in nVidia CP, but either way should work.

Well, you did make me question my sanity about how I put these features together, and I am glad we finally resolved it! Nonetheless, having to explain myself like this does make me question whether what we are talking about is intuitive enough for all users, not just yourself. In the case of using custom Community folders, I still consider that if a user uses a tool like Addons Linker, it is a reasonable expectation they know to install an addon to their linker folder first, then subsequently enable it via Addons Linker to create the relevant symlink in the MSFS Community folder. I also think there are enough checks and balances and suitable warning messages in place should anything need to be done to get it to work or if things get inadvertently misconfigured. In short, I don't think any further action is required for this. In the case of deferred updates, it is clear to me from your experience that you were not aware that your SOP actions were preventing the auto-update from ever occurring. While the log would reveal exactly why to nerds like me, it is not explicit enough for normal users and that needed to be addressed. To that end, in 0.5.4.4-RC2, I have added a message box that informs a user if they are trying to close the app while a deferred update is pending that is unable to be installed due to MSFS still running, which looks like this: Note that you will not see this message until you go to update to the next app version, as it is this new version that introduces the new logic. Also note that the frequency of widget updates should be dropping drastically soon, if not already, as I am now pretty happy with how it looks and behaves in both 2D and VR, within the limitations of the MSFS interface that it uses. As such, deferred updates, which are only required when a widget update is present and MSFS is currently running, should be very rare in future.

Duplicate

@Adamski_NZ , just to add, the installer actually already has the exact symlink-checking logic you described built into it. When an update runs, it inspects any existing symlink in your Community folder, checks where that link points, and if it already points to your configured custom location, it leaves the link completely untouched and quietly updates the files in place. The reason it wiped your link is because of how the custom path was set. That setting is specifically for a custom Community folder, not a widget folder. The installer manages more than just the widget, as it also installs the MobiFlight WASM module. If the custom path were set directly to a widget subfolder, it would try to install MobiFlight inside the widget folder and break the module completely. Because the setting is meant to be a parent Community folder, the installer always takes your custom path and appends the widget folder name to it. When you set the path directly to the widget itself, the installer looked for a target ending in widget-folder\widget-folder. Since your Addons Linker symlink did not match that path, the installer assumed the link was stale or conflicting and removed it. To get it working seamlessly, just set your custom Community path to the parent library folder where your addons live in Addons Linker, rather than the widget subfolder itself. Once that path is set properly, the installer will see that your symlink in Community points directly to where the files are going, leave the link alone, and update the widget without prompting you or needing Linker to be re-opened.

While it is technically possible for an installer to query a Windows reparse point and resolve the target folder behind a symlink, having an installer back-trace through links into external staging repositories causes a lot of headaches in practice. The biggest issue is what happens if the widget is temporarily disabled or unlinked in Addons Linker when you run an update. In that scenario, the symlink doesn't even exist in your Community folder. The installer would find nothing, drop the files straight into Community, and you would end up with duplicate folder conflicts the next time you enable it in Linker. There is also the clean update routine to consider. The installer clears out the previous version's folder so you don't end up with orphaned, obsolete files from older builds. In Windows, deleting a directory that happens to be a symlink only removes the link itself, which is why extracting the new files immediately creates a standard folder in Community. Having an installer follow links to recursively wipe directories in an external library is far too risky and can easily cause unintended data loss. Looking at what happened in your case, it sounds like you already had the widget linked via Addons Linker before pointing the installer to your custom folder. The installer doesn't know that the existing link in Community is tied to your Addons Linker setup, so to avoid having two conflicting paths, it removes the link in Community first. The proper sequence is to run the installer, set your custom folder to your external Addons Linker library, and hit update to put the files there. Once that finishes, just follow the pop-up prompt by opening Addons Linker and enabling the widget from there.

Re deferred updating, it does it when you exit MSFS with AutoFPS still running. If you are closing down AutoFPS before MSFS, which you don't need to do BTW because AutoFPS auto-closes itself when it detects MSFS is no longer running, then it never gets a chance to run the deferred update because it needs MSFS to be not running. If MSFS is already running the next time you start AutoFPS, eg via auto-start, then it still cannot auto update, hence your endless loop of it not updating. The app should clearly be telling you that it will update when MSFS, ie. NOT AutoFPS, exits eg. TL;DR, just exit MSFS and leave AutoFPS running and all will be good. Re symlinks being destroyed and the widget getting installed to community directly, this should only happen if you uninstalled AutoFPS first and therefore it has lost the location of your custom install folder, which is stored in install.log that the uninstall would have deleted. If you haven't uninstalled, you should see the correct custom community location shown when you hover the mouse over the 2024 button eg. If it is not showing your custom folder location, change it to it, click update, which will update the app and save the custom location in the install.log file, then the next time you go to update, regardless of whether auto or manually, it will populate the custom folder location that it finds in install.log by default. ie. You only have to set it once and update then it will be there perpetually.

Further to this, I uncovered another widget bug in 2D which, again, appears to be a result of the way the MSFS toolbar window interface works, or in this case, doesn't. The bug is that if you move the window to, say, the left side of the screen, close it, then reopen it, it appears on the opposite side. Interestingly, the issue only occurs horizontally, not vertically. eg. here is a before and after of a close/reopen sequence: This issue has affected all previous versions of the widget, not just the new experimental build I released yesterday. It also affects most of the other add-on toolbar windows I use, including SimBrief Panel, FSLTL Traffic and FCR Embedded, so it appears to be another MSFS quirk. The good news is that I found a fix for it and, after extensive testing in both 2D and VR, I am finally happy enough with it to promote the app to test status in the newly released 0.5.4.4-test1 for a broader audience to try. There is still one minor issue whereby the VR panel resets its size if you close it using either the toolbar button or the widget's X button and then reopen it. However, if you use the widget's Show/Hide hotkey feature to close and open it, it correctly remembers its size. Aside from that, the widget can now be closed and reopened while retaining its position and, in 2D, its size. It can be moved freely around the screen without encountering false floors or walls, resized vertically, and will automatically adjust its width to suit. In my opinion, and in the opinions of Claude, Gemini and Copilot, this is about as good as it is likely to get given the current limitations of the MSFS toolbar window interface.

Thanks for getting back to me on what happened. FYI, the current code scans the log file for the last app state entry and goes off that. As you have experienced, it is not a 100% reliable way to detect app state but it is all I had to work with at the time. The good news is that I have already proposed the creation of a current app state file, which would remove all such potential ambiguity, and djules75 is considering doing that in near-future OFXR update. Of course, I will update AutoFPS to incorporate this when it comes out.

I recently discovered that a side effect of the new Widget auto-height adjustment is that, due to current limitations (or perhaps shenanigans 😄) in the MSFS widget panel interface, MSFS displays the correct widget height but internally remembers the original window height when it is opened, which is often much taller than the widget actually shown. The result is that in 2D mode you may not be able to move the widget as close to the bottom of the screen as expected because MSFS thinks the window is taller than it really is. This is not an issue in VR because there is effectively no screen edge limiting widget placement. I've now found an alternative resizing method that completely eliminates this false floor in 2D. The trade-off is that in VR, if the widget is closed and reopened, it will revert to its default size due to more MSFS shenanigans. Fortunately, the widget's 3D position is retained and the default size is generally quite usable, so I expect little to no impact for most VR users. To test this approach, I have released 0.5.4.4-exp1, available via auto-update on the Exp+ channel or from here. This build contains only this change. If you've been frustrated by not being able to position the widget fully at the bottom of the screen in 2D, this should resolve that issue. VR users may be less enthusiastic about the size-reset behaviour, but if you're happy with the default widget size or don't mind doing a quick resize in the rare event you do close then reopen the widget in a flight session, I'd still appreciate feedback on how it behaves in general use. If the word "experimental" concerns you, don't worry. If you decide you don't like the change, simply restart AutoFPS and switch to any channel above Exp+. Auto-update will immediately return you to the current 0.5.4.3 formal release. The reason this experimental build is being released so quickly is that I'll be away from my development PC for a few days. I suspect someone would eventually run into this issue while I'm gone, so I'd rather make a potential solution available now than leave it unresolved.

MSFS_AutoFPS v0.5.4.3 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 introduces comprehensive Optical Flow OpenXR (OFXR) frame generation support for VR users and delivers major enhancements to the In-Game Widget—including automatic vertical window sizing, a persistent show/hide toggle hotkey, and improved visual scaling—alongside installation and version detection refinements for custom Community folder configurations.

@FakeWayne , did you manage to sort that out or is it still an issue. 0.5.4.3 has entered RC status now, meaning I intend to release it soon, and I would like to resolve your issue beforehand if it still exists.

Are using 0.5.4.3-test version test3, which is what introduced OFXR support, or newer? If not you need to update to that first. FYI, the app is looking for the OFXR Bridge Tray app to be running before you switch to VR and for the bridge to be enabled (should be by default). It should look something like this in your system tray, with the tooltip showing when you hover over it: Once you switch to VR it should auto detect in the app. If still not working, can you message me the first section of your AutoFPS log file, located in %appdata%\MSFS_AutoFPS\log, which will show what the app detected.

FYI, djules75, the maintainer of the current 0.2.X version of OFXR Bridge, reached out to me about my recent integration with AutoFPS. djules75 is happy to collaborate so our two apps stay aligned as reliably as possible, which is great news moving forward.

Some good news! I have added full OFXR for VR support to the app, available for early access testing in 0.5.4.3-test3 here or via auto-update via the Test+ update channel in the app. Relevant release notes are: Added Optical Flow OpenXR (OFXR) for VR support: Automatically detected whenever OFXR Bridge Tray is running and armed while in VR mode. Dynamically tracks active and paused states in real time: applies the detected frame generation multiplier (2X or 3X) when active, and displays native sim FPS when paused via hotkey. Automatically pauses LOD adjustments and displays "OFXR ⏸" while paused to keep visual quality locked steady for seamless A/B comparison without exiting the OFXR profile. Automatically reverts to standard VR mode if the bridge is disarmed. Adds a dedicated OFXR Target FPS graphics mode with its own independently saved target FPS setting. Displays the live OFXR status and multiplier (e.g. OFXR 3X, OFXR ⏸) directly on the app status line and UI. In action with 3X FG active: Now with OFXR paused via OFXR's hotkey, showing LOD changes are currently paused as a result: As an aside, this is the first time I have tried this mod and I have to say I am pretty impressed with it for VR users. Prior to this mod, I had my FPS locked in MSFS to 40 and used my Quest 3's motion reprojection to double that to 80. Now with OFXR I have lowered my FPS lock to 30 and with 3X FG get 90 FPS in headset, and it looks just as good to me. So not only do I get slightly higher FPS but I am able to increase AutoFPS TLOD settings because the target FPS has been reduced by 25%. Finally, a win for Team VR!

I had a feeling support for this new mod would be coming my way shortly, and here we are! 😄 At the moment, AutoFPS is FG for VR unaware. In fact, it is also Motion Reprojection (MR), the predecessor to this FG mod that does a similar thing, unaware because there is no way for the app to detect it. As such, until I work out whether the FG multiplier for this FG mod is detectable or not, just do what you always did if you used MR - just set your target VR FPS as pre-FG/MR. As for whether to set 29 or 30 FPS in your scenario, if you have capped your VR FPS to 30 and it maintains that pretty much all the time, then switch to Fixed target FPS type and use 30 as the target. If you regularly dip below 30, then set a target of 28 (29 is too close to 30) and stay on Manual target FPS type.

Following reports of some third-party aircraft and add-on camera views utilizing previously unhandled MSFS camera states (which caused DynamicLOD_ResetEdition to remain paused or stuck waiting for a session indefinitely), I have decided to release v0.6.0 ahead of schedule to deliver this fix promptly. DynamicLOD_ResetEdition v0.6.0 is now formally released and available either via the in-app auto-updater or by downloading directly from here. A huge thank you to everyone who provided valuable feedback during the test phase! This maintenance update expands camera state compatibility for third-party aircraft and views (fixing the stuck pause/waiting issue), improves camera state transition resilience, adds pause and unpause transition logging, and updates the bundled SimConnect libraries to the latest MSFS 2024 SDK version.

Following reports of some third-party add-ons utilising previously unused MSFS camera states (which caused AutoFPS 0.5.4.1 and earlier to remain paused indefinitely), I have decided to release v0.5.4.2 ahead of schedule to deliver this fix promptly. MSFS_AutoFPS v0.5.4.2 is now formally released and available either via the in-app auto-updater or by downloading directly from here. A huge thank you to everyone who provided valuable feedback during the test phase! This maintenance update expands Mountains+ in Free TLOD mode to all altitudes, resolves an issue with in-game widget telemetry when starting minimised to the system tray, expands camera state compatibility for third-party aircraft and views, improves camera state detection resilience, and refines upgrade logging and onboarding prompts.

All I was saying is that if you choose to set a custom Community folder location in the AutoFPS installer itself, it requires you to ensure that either MSFS knows of this custom Community folder location directly or, if you are using Addons Linker, that you have enabled the mobiflight and, if applicable, widget simlinks within Addons linker if you expect AutoFPS to find them, regardless of whether MSFS is running or not. ie. you can't configure a custom Community location for MSFS without telling MSFS, and hence AutoFPS, where to find it, and this applies to any addon you choose to configure this way. The fact that AutoFPS could not locate a module suggests you did not enable those symlinks before you ran it. As already mentioned, the installer now gives you a warning to configure proper linking if you choose a new Custom Community location in the installer.

If you don't mind the input lag and visual glitches from dynamic FG when your base FPS drops low, you won't need this app. But if you want to avoid those artifacts caused by keeping TLOD too high during demanding flight phases, the app is worth using.

A base-only toggle would actually work against what Mountains+ is designed to do. It was originally built around the idea that the mountain bump started at TLOD Max, so you get consistently better mountain terrain the higher you go. The change I just made extends that bump to cover all altitudes in TLOD Free mode, including on the ground. Making it apply only at the base would mean deliberately turning that off everywhere except below Alt TLOD Base, which includes being on the ground, and that's really the reverse of the feature's original purpose and would confuse and likely displease other current users of the feature. It's also not a small change under the hood. Quite a few places in the code assume TLOD Max already has Mountains+ factored in, so scoping it to base-only would mean adding protection against TLOD Min + Mountains+ ending up higher than TLOD Max, which gets fragile fast for what's really a fairly narrow use case. Given you've already got six profiles to play with, I'd suggest just setting up one specifically for ground-level mountain flying with a higher TLOD Base to start with. You get the visual improvement you're after on the ground without needing a new, more delicate code path, and you can keep your other profiles exactly as they are for everything else.

@agent00729 , well that was a storm in a teacup on my part! 😄 It turns out it was a simple edit of only one line of code to allow Mountains+ to apply up high, down low and on the ground in TLOD Free mode. Note, this only works in FPS Sensitivity and Tolerance modes. Mountains+ still behaves the way it previously did in AutoTLOD mode, as this mode works to a very specific altitude/TLOD schedule. Imgbb is down for maintenance at the moment so I can't upload and post up the screenshot I did of it working until it is back up. FWIW, the screenshot shows me on the ground at Lukla (9300 ft elevation) with TLOD Base 50, TLOD Top 200, Free TLOD, Mtns+ enabled Mtns Extra +200 and trigger elevation of 5000 ft. Before the change, these settings and location would have achieved TLOD 200 as the maximum. Now with the change it goes all the way up to 400 (ie. 200 + 200). I have released it in 0.5.4.2-RC4 available here or via auto update with the RC+ update channel selected as a minimum, so give it a go and let me know if that is what you were after. Edit: Of course, just as I post this Imgbb comes back up. Here is the screenie:

The Mountains+ feature was really intended for greater than Alt TLOD Top flying, so your suggestion doesn't quite fit with that. You could always use TLOD Base Extra and a high enough multiplier to get you to TLOD Max (albeit without Mountains+, but still better than TLOD Base). Alternatively, you can use TLOD Free mode, which will also give you up to TLOD Max on the ground. Finally, you can do either of those and just set a higher TLOD Max in the first place for such flights, as you have six profiles you can customise. Having said that, while I have 0.5.4.2 in development, I will look at whether I can expand TLOD Free to allow up to TLOD Max + Mountains+ when active on the ground, so that way you have the full band. I am reluctant to extend that to TLOD Extra and Fixed, as in those modes users specifically want a lower TLOD on the ground and this would go against that. No promises though, as my recollection of the code for Mountains+ is a bit complex and it has been a while since I touched it. If it is too hard for 0.5.4.2, which is in the final phase of testing so I don't want to add potentially buggy new features at this late stage, but is still possible, I will aim to put it in the 0.5.4.3 test program.

Thanks for the extra feedback. In your earlier post you said this, which I currently cannot explain: When AutoFPS is not running, there is no interaction with MSFS whatsoever other than the existence of the widget, if you chose that installation option, or the mobiflight module folders in your community folder. The mobiflight module is a requirement for both 0.5.3.0 and 0.5.4.1 and is the same version, so it should not be that. You say you tried without the widget installed, but did you try it without the widget installed AND AutoFPS 0.5.4.1 not running? One thing worth double-checking: did you enable the Auto-Start option during install? If so, AutoFPS would actually launch automatically whenever MSFS starts, even if you never open it yourself. Could you check Task Manager for AutoFPS.exe right after MSFS launches, before you manually open the app, just to confirm it's genuinely not running in that state? I am happy to keep diagnosing this issue, but as we have had a few posts on this now it is probably best we take it to a PM and carry on from there. I really would like to get to the bottom of it!