8 hours ago, Reset XPDR said:

@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:

1. Open Windows Settings > Apps > Installed apps.

2. Find Notepad, click the three dots (...) and select Advanced options.

3. Click Repair (or Reset).

4. 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!

I see this error every time after updating AutoFPS for over half a year.

Notepad opens normally when I executie itzz

Will try your fix and see next update if it has solved the issue.

- -

Update : Repair did not fix it. Did it before updating to RC3.

Un- and reinstalled Notepad. Will see how things go after a next update.

Edited September 18Sep 18 by GSalden

7 hours ago, Reset XPDR said:

@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.

Before:
]

After:

]

As you can see, the overall window widened up to the right with RC3 (but not directly, only a second after the app opened).

I'm still looking into all scaling options i can find in Windows settings, all is on default (like it was set before RC3):
]

]

Both my monitors are on default resolution although both use a different one (main: 2560x1440, the 2nd 1920x1200) but it doesn't matter on which monitor it displays, behaviour is the same.

As a test i went back to 0.5.4.0-test5.
If i open AutoFPS then it opens with expert settings not ticked. All borders are fine then in that window as seen in the next screenshot.
]

The moment i tick the expert options, the app opens up further and then the borders become open on the right (except the General one which has full border).
]

One other thing i see with this RC3 update it that after opening, the borders are now closed (as it should be) and then only a second later, the app widens the window to the right.

2 minutes ago, GSalden said:

I see this error every time after updating AutoFPS for over half a year.

Notepad opens normally when I executie itzz

Will try your fix and see next update if it has solved the issue.

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. 😄

Edited September 18Sep 18 by Reset XPDR

5 minutes ago, Lange_666 said:

Before:
]

After:

]

As you can see, the overall window widened up to the right with RC3 (but not directly, only a second after the app opened).

I'm still looking into all scaling options i can find in Windows settings, all is on default (like it was set before RC3):
]

]

Both my monitors are on default resolution although both use a different one (main: 2560x1440, the 2nd 1920x1200) but it doesn't matter on which monitor it displays, behaviour is the same.

As a test i went back to 0.5.4.0-test5.
If i open AutoFPS then it opens with expert settings not ticked. All borders are fine then in that window as seen in the next screenshot.
]

The moment i tick the expert options, the app opens up further and then the borders become open on the right (except the General one which has full border).
]

One other thing i see with this RC3 update it that after opening, the borders are now closed (as it should be) and then only a second later, the app widens the window to the right.

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.

Edited September 18Sep 18 by Reset XPDR

Don't put it high on your priority list, it's just a quirk and does not stand in the way of the functionality of your app.
I really didn't even noticed it before dark mode entered the scene. Only then it became noticeable because the borders are white (or light grey) and only then when you posted a screenshot, i saw that your window and mine differed. Just wanted to mention it.

48 minutes ago, Lange_666 said:

Don't put it high on your priority list, it's just a quirk and does not stand in the way of the functionality of your app.
I really didn't even noticed it before dark mode entered the scene. Only then it became noticeable because the borders are white (or light grey) and only then when you posted a screenshot, i saw that your window and mine differed. Just wanted to mention it.

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.

17 hours ago, Reset XPDR said:

You can test this yourself: press Win + R, type notepad, and hit Enter - you will get the exact same error without AutoFPS running.

hmm no notepad has been and is working just fine without the error.

@Reset XPDR Widget Request; Shortcut/Keybind to Hide/Show the widget in game.

Unfortunately as is per Asobos majorly flawed quality control, an old bug re emerged whereby VR widgets are shown in external views, ruining screenshots, makes it a faff to open/close them all the time.

So if there isn't already a shortcut to hide/show AutoFPS then again I'd be most grateful if you could include it one day 🙂

47 minutes ago, MarcG said:

@Reset XPDR Widget Request; Shortcut/Keybind to Hide/Show the widget in game.

Unfortunately as is per Asobos majorly flawed quality control, an old bug re emerged whereby VR widgets are shown in external views, ruining screenshots, makes it a faff to open/close them all the time.

So if there isn't already a shortcut to hide/show AutoFPS then again I'd be most grateful if you could include it one day 🙂

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.

18 minutes ago, Reset XPDR said:

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.

The reason is ease/quickness of use, I bind most keybinds to various controller buttons thus making it quick and easy to open/close the EFB for example without ever needing the keyboard.

As it currently stands it's 1) Close the box, 2) take the screenshot, 3) press a button to open the toolbar menu (I have an app to keep it permanently hidden otherwise it gets annoyingly in the way in VR), 4) select AutoFPS to open it again - rinse & repeat when I want to take a screenshot.

vs 1) Press a button to auto hide all Widgets (using Joy2Key I sync all widgets to one button), 2) take the screenshot, 3) Press a button to auto show all widgets.

Anyway I appreciate your reasoning as I am just one person wanting it 😄

I'm wondering if this may be something that could be achieved with FSUIPC. It can do some pretty clever stuff (but don't ask me how!). I Googled "open close any window with FSUIPC" ...

You can open and close specific in-simulator user interface windows or panels in flight simulators using FSUIPC by assigning a button or key press to the PANEL ID SET control with a specific window/panel ID parameter, or by utilizing a FSUIPC Mouse Macro or Lua script. [1, 2, 3]

Also - I've seen some addons being integrated with the EFB - which is always available via the TAB key. That might be a more elegant solution, but might be hard to code <??>.

58 minutes ago, MarcG said:

The reason is ease/quickness of use, I bind most keybinds to various controller buttons thus making it quick and easy to open/close the EFB for example without ever needing the keyboard.

As it currently stands it's 1) Close the box, 2) take the screenshot, 3) press a button to open the toolbar menu (I have an app to keep it permanently hidden otherwise it gets annoyingly in the way in VR), 4) select AutoFPS to open it again - rinse & repeat when I want to take a screenshot.

vs 1) Press a button to auto hide all Widgets (using Joy2Key I sync all widgets to one button), 2) take the screenshot, 3) Press a button to auto show all widgets.

Anyway I appreciate your reasoning as I am just one person wanting it 😄

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.

13 hours ago, Lange_666 said:

Before:
]

After:

]

As you can see, the overall window widened up to the right with RC3 (but not directly, only a second after the app opened).

I'm still looking into all scaling options i can find in Windows settings, all is on default (like it was set before RC3):
]

]

Both my monitors are on default resolution although both use a different one (main: 2560x1440, the 2nd 1920x1200) but it doesn't matter on which monitor it displays, behaviour is the same.

As a test i went back to 0.5.4.0-test5.
If i open AutoFPS then it opens with expert settings not ticked. All borders are fine then in that window as seen in the next screenshot.
]

The moment i tick the expert options, the app opens up further and then the borders become open on the right (except the General one which has full border).
]

One other thing i see with this RC3 update it that after opening, the borders are now closed (as it should be) and then only a second later, the app widens the window to the right.

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:

Edited September 18Sep 18 by Reset XPDR

12 hours ago, Reset XPDR said:

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.

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 launched AutoFPS with MSFS2024 not running and when I selected show updates and it shows RC4 available "here" when I click on the "here" link nothing happens.