Reset XPDR

In general, it is bad practice to update files currently in use by MSFS, potentially causing strange behaviour or a CTD. If you manually run the installer, it will abort before updating anything if a widget update is required and MSFS is still running. If you have set the app to auto update and a widget update is required and MSFS is running, for any reason including an auto start of the app with MSFS, the app will automatically defer the auto update until after you exit MSFS. In short, protections are in place for widget updates regardless of whether the installer is run manually or by auto update.

The changes in v5.4.1 over v0.5.4.0 are extremely minor and limited to close to system tray window behaviour. As such, what you experienced is most likely a glitch which will resolve itself with either a restart of AutoFPS, MSFS or at worst a reboot of your system. Try that and let me know if you still have the issue and, if so, attach a log as well so I can see what is going on. Edit: I just saw your log. The reason it is not recovering this time is because your FPS is n/a, which the app takes as 0 FPS so settings reduction kicks in and never recovers, regardless of what you have set recovery to. As suggested, reboot your system, make sure you see a valid FPS reading in the app when it connects to your flight session, keep settings recovery on Ground and it will recover on the ground when conditions improve.

FYI, v0.5.4.1 has just been released. It's the same as v0.5.4.0, but includes a hotfix so the widget continues updating with Sim Values while the app is minimised to the system tray. It also adds a new context menu item to close directly to tray, if that option was configured during installation. Unfortunately, the widget not updating issue wasn't identified during the test phase. It's a notable one for anyone using the close-to-tray option, which is why this hotfix needed to go out so soon. My apologies for the quick turnaround!

It is because you have settings reduction recovery set to Alt TLOD Base, which means that recovery will not commence until you are above your set Alt TLOD Base of 1000 ft. As you remained on the ground for the entire log, recovery never occurred. If you want recovery to occur on the ground, set it like this: BTW, I should have picked this up the first time you told me about the issue the other day, as it did not need Log+ to identify the issue. Perhaps I should make the logs clearer for settings like reduction recovery, because in your log it showed as RRecov:1 which is not the easiest to spot.

Oh the irony of you adding to the length of this topic! Enjoy! 😁

FYI, a few users have noted Windows Defender flagging the new installer with Trojan:Win32/Bearfoos.B!ml. This is a standard false positive caused by Microsoft Defender's automated cloud machine learning (!ml) heuristic. Because v0.5.4.0 is a new release with a widget code package that it has never contained before and the installer is unsigned, Defender's AI heuristics flag the installer's file extraction and local webserver code. I can assure you that this is the same exact same code as was released in 0.5.4.0-RC8 yesterday, except compiled with an internal flag flipped from Test to Release, with no reports of such a threat in over 600 downloads and is similar to all other test releases over the last month. As such, I am extremely confident that this is indeed a false positive. As more users install and run it over the next 24–48 hours, Defender's telemetry will automatically build reputation for the file and the warning will clear on its own. In the meantime, you can safely allow the installer in Windows Security: Open Windows Security > Virus & threat protection. Click Protection history. Select the blocked installer entry > click Actions > Allow on device.

MSFS_AutoFPS v0.5.4.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 major release introduces the new MSFS In-Game Toolbar Widget and local webserver, adds a native Dark Mode theme with title bar and window-handling enhancements, delivers a comprehensive UI layout and text scaling redesign for seamless high-DPI and accessibility scaling, expands RTSS Dynamic Frame Generation support with post-FG targeting, introduces intelligent deferred auto-updating to prevent in-flight update interruptions, adds custom Community folder and Addons Linker management to the installer, and delivers broad stability, SimConnect, and diagnostic improvements. After auto-updating to 0.5.4.0, users encountering the widget for the first time will be presented in the app with a one-time prompt to add the MSFS in-game widget. If accepted at this time, the app will auto-install the widget and restart the app. If declined and the user subsequently wishes to install the widget, they will be required to manually run the installer and select the MSFS Widget option then click Update. The app will remember your widget installation preference for all future updates until such time as you change your preference by manually running the installer again. Here is an example of what the MSFS in game widget looks like, configured here in dark mode and with the title bar showing. The title bar can be hidden by either double clicking on the title bar or anywhere in the widget window that is not a control and revealed again by performing the latter. The title bar setting and the three other controls in the Control section are syncronised with the main app UI and give you easy access to the main settings you may wish to change while in MSFS. Note, the widget does not have the full control set of the main app window as it is intended for use rather than configuration and to have the smallest in-game footprint possible, so if you wish to change other settings you will have to still do that in the main app window. The app UI improvements include dark mode, as pictured below, but also enhancements such as being able to hide the title bar, better behaviour with Windows text scaling, a right-click context menu to reveal the title bar again and exit the app, and the ability to close the app without a confirmation prompt when selected from the taskbar context menu. Finally, the Installer has had a bit of a layout makeover and adds the MSFS Widget option and the ability to change the Community folder location where the app installs your mobiflight module and widget, particularly useful for those who use MSFS Addons Linker. Enjoy!

I'm glad the widget is going well. At this late stage of development, I'll take no other news as good news and 0.5.4.0 will be released very soon. I know I didn’t take on the keybind request to hide the toolbar, but the idea you suggested to hide the toolbar itself was a good one. It made the widget nice and slim in MSFS, so thanks for that!

That is intentional. The app window is now designed around the widest line at 100% text scaling, which is what almost all users run, so its footprint stays as small as possible. When text scaling is increased above 100%, the window will accommodate the larger text and maintain its normal width up to a point, but very high scaling can require a slight expansion to fit longer strings. For rare cases like yours, this behaviour is preferable to forcing a permanently wider window on everyone, similar to how the earlier oversized window wasn’t ideal for you.

Yay! I was pretty thorough with the UI today, so hopefully that's the last we see of such shenanigans. 😊

Found the issue, which was a side effect of introducing the left click window drag capability back at Test3 whereby hyperlinks were inadvertently not excluded. I have fixed it in RC5, but you won't see the fix until you upgrade to RC5 and there is another update after that, because the fix is in RC5 if that makes sense. FYI, and this goes for anyone else using Show Updates, if you do want to install a particular update on offer easily, you can temporarily switch to Prompted Updates and click Yes, or choose Silent Updates, and the auto-update will occur. After the auto-update, you can switch back to Show Update if you desire. Edit: While I was in there, I changed the link for test versions from the general releases landing page to the more useful specific test release page and a bunch of small UI scaling improvements. RC7 is now out with those changes.

Thanks for the heads up. I'll look into it.

Further to this, I have decided not to persue right now a change away from notepad as the app the installer uses to display the release notes at the end of installation, as it is too large a change at such a late stage of 0.5.4.0's development cycle. I will look into this again when I start the 0.5.5.0 test program. As promised, RC4 has just been released and updates the MSFS in-game widget, primarily to add the dark/light mode checkbox but also as a final test of auto-updating the widget before imminent formal release. I am pleased to say that on my end at least the auto update went smoothly, regardless of whether it gets done immediately on starting the app without MSFS running, or being deferred until after MSFS closes if MSFS was open when the app was started. Hopefully everyone else will experience the same. Please let me know if you have any issues that I need to address before formal release. Thanks.

I think I have found the cause of the excessively wide app window you experienced, which I was able to reproduce on my system too. I have two url labels, one for formal release and the other for test versions, in my UI design on the status line after the status text is shown, which are used to show links for available updates should the user have the Show Updates option selected. These get collapsed when in a flight session but before that they were only hidden, which still counts width wise as being drawn even if not seen. I have changed those to collapsed by default, which removes them from any window width calculations. Here are the before and after the fix screenshots on my system, which hopefully does the same on your, and everyone else's, system too in the just-released RC4:

I see what you are are saying but it is too much of an edge use case with a potential undesirable side effect for other users of a duplicate keybind so I am still going to leave it as is, sorry.

There isn't already a shortcut/key bind to hide/show AutoFPS. Choosing a free shortcut/key bind suitable for the majority of users would be difficult as there are so many already used in MSFS and users may have customised them to collide with what I'd choose. Finally, I don't see why you would want a keybind versus the easily clickable X on the widget title line, especially in VR where keyboard access is difficult. As such, I am not planning to do this. My suggestion is that if you are going to get all screenshotty for a while, just close the widget until you are done then open it back up, the same as you would do for most other in-game widgets.

Good points. If there is a simple fix for it I will put it in what I hope will be the last RC before release, otherwise I'll defer it to the next test program. Same goes for the Notepad issue which, while annoying, is not a showstopper for those few experiencing it. As hinted, there will be another RC release, likely tomorrow, which adds the dark mode checkbox to the widget (as VR users in particular may wish to change it while flying between day and night transitions) and I added the widget version to the title and a few other minor bits of polish while I was in there. I was planning on rolling the widget version one more time before formal release anyway, as I want to live test the latest auto-update code for it with the smaller group participating in the current test program before unleashing it on everyone. Fear not, I have test this auto-update code extensively and there a safeguards in place even if things don't quite go as planned.

Thanks for the detailed feedback. While it an improvement that the panel borders are now consistent, them being unnecessarily wide, while not being a show stopper, is not really acceptable. I shall investigate what is causing that shift wider after one second and hopefully come up with a fix. Full disclosure here, UI design has never really been my thing and the code I inherited when I spawned this app from the original Dynamic LOD app had some "interesting" UI traps that I have had to work with. As such, I have been using Google Gemini, who is much more skilled at such things than I, to help me rewrite this to remove such quirks and make the app scale better, but it looks like there are a few still in there. I have run out of fun tickets today in Gemini, and it is generally not a good idea to switch AI buddies mid-stream to something like the mighty Claude, so I will have to defer this until tomorrow.

I didn't realise this issue was so common. My reasoning for always running notepad is that for test versions I want testers to be poked in the face with the changes from the last release so that I don't continuously get asked what has changed and it gives them an idea of what to expect in the new release. For the release versions, they are much more infrequent and contain a lot of changes so I'd like them to be presented with the summary of changes. Since this is affecting a few of you, I will look into alternative ways to show the release notes, the easiest and safest one being to open it as html in your default browser, but I am not sure how well that would go down with users. I am still interested in whether you can repair notepad as easy as the instructions I gave you imply, but software being software probably not. 😄

The app checks for widget existence and does a version check against the app version on startup and logs the result. If there is a mismatch, you will see the following message, which I triggered by manually changing the widget version to 1.1.0 in the installed widget's manifest.json: 2026-09-18 09:46:52.877 [INF] [ App:OnStartup ] In-Game Widget v1.2.0 for MSFS 2020 and v1.1.0 for MSFS 2024 detected 2026-09-18 09:46:52.877 [WRN] [ App:OnStartup ] In-Game Widget version mismatch detected in MSFS 2024 (Expected: v1.2.0). Aborting startup. ie. the app won't let you have an outdated widget version, so IMO no need to show the widget version or advise of update, except in the case of a mismatch which it currently does.

@Lange_666 , I've reworked app scaling in RC3 so that it now behaves with border sizing within the app window. Here is a side-by-side before and after screenshot with Windows text scaling at 120%: Please give this version a try and let me know if that now resolves it for you. For anyone else updating to RC3 that does not use Windows text scaling and the app borders pre-RC2 did display correctly, which should be most users, please let me know if there are any new UI layout issues with RC3 that may have been inadvertently introduced with this text scaling fix. FWIW, on my two systems with no Windows text scaling (but with Windows display scaling), the app window is behaving as it always has pre-RC2.

@MarcG , never mind about telling me the installation stage as this error is actually coming from your Windows Notepad installation, not AutoFPS. At the end of an update, AutoFPS asks Windows to open Release Notes.txt in Notepad. On Windows 11, modern Notepad is a Microsoft Store app that relies on the Windows App SDK (Microsoft.UI.Windowing.Core.dll). When that system dependency becomes corrupted in Windows, launching Notepad throws that error. You can test this yourself: press Win + R, type notepad, and hit Enter - you will get the exact same error without AutoFPS running. To fix it on your PC: Open Windows Settings > Apps > Installed apps. Find Notepad, click the three dots (...) and select Advanced options. Click Repair (or Reset). Alternatively, open the Microsoft Store, go to Library, and update or reinstall Windows Notepad. Once Notepad is repaired in Windows, the release notes will open normally after updates!

No you should not see that error any time, never mind every time. I shall add it to the investigation list! 😄 Edit: It would be helpful if you can tell me the exact point in the installation process that this error occurs eg. what is the last thing in the scrollable install log window.

You are welcome!. The only thing I like users to donate is their feedback when I ask for it, otherwise I just do this for the love of the flight simulation hobby and to keep learning how to code new features and solve support mysteries.

Well there is some scaling thing going on with the text in your app, as it is larger than it should be with default scaling, perhaps with your shortcut properties or some other Windows app affecting text scaling. I will investigate further when back at my dev PC tomorrow.