Reset XPDR

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.

No worries! Re the custom Community folder locations, I have discovered a minor issue where it can result in you having the widget installed in your new custom Community folder but not delete the one in your default Community folder should you have originally installed it there. It does not affect operation of the app, but it is untidy to have two widget install locations and may cause conflict with symlinks (none reported so far) so I will issue a fix that can differentiate between symlinks and real folders and only delete the latter in RC3 tomorrow when back at my dev PC.

Duplicate post

This is usually because you have set the custom text size in Windows settings to anything other than the default left setting: Instead, I strongly recommend you use the Windows Scaling setting below instead, which does play nicely with the app per my app screenshot above (which is actually with 225% scaling for my 85" 4K TV), and IMO scales everything in Windows much better anyway.

I have put the final polishing touches on 0.5.4.0 by rejigging the UI slightly to accommodate a Widget connection status indicator, which required me to move the Dark checkbox next to On Top, which is a more intuitive placement anyway, and in turn move Log+ down next to Expert. Failing any more significant feedback being received on 0.5.4.0, I will let RC2 sit for a few days then will formally release it. Thanks to all those who provided feedback during the test phase as it really did help shape what it has become.

Unfortunately your attached log doesn't have enough detail to show what is going on as normal logging is very limited on the ground where settings reduction occurred for you. Can you provide a log with Log+ enabled as it provides the one second interval data I need to really tell what is going on. Just a short one will do, long enough to show when settings reduction activated. In any case, nothing has changed in 0.5.4.0 test versions that affects reduction settings activation. The likely reason for reduction settings activating is that your FPS did actually drop for long enough below the trigger threshold. The Log+ log should show that and, if not, I will investigate further.

The new MSFS in-game widget has been working out well with testers. The final item I wanted to address before the formal release is making auto-updates less intrusive when MSFS is running. When an update includes widget changes, it will now be deferred automatically until after MSFS has closed (since updating widget files while MSFS is running will fail). Updates that do not involve widget changes will continue to install immediately, even while MSFS is running. These auto-update enhancements, along with a few other refinements, are now live in 0.5.4.0-test9 in preparation for formal release. If you are updating from test7 or test8, the widget version remains at 1.2.0, so the update will apply immediately without needing a deferred install. Users updating from earlier test builds (or from formal release 0.5.3.0) will experience the deferred auto-install if MSFS is running and the widget needs to be installed or updated. If any of that sounds confusing, especially if you only stick to formal release builds, don't worry too much about the technical details. For the upcoming 0.5.4.0 release: Auto-upgrading from 0.5.3.0 will not install the widget by default. After the update, users without the widget will see a one-time message explaining the new feature, with instructions to run the installer and enable the MSFS Widget option if they wish to use it. Once enabled, the smart auto-installer takes care of everything in the background, only ever prompting you in the rare event that a widget update is needed and MSFS is currently running.