58 minutes ago, FakeWayne said:

Hey sorry for not responding, I was out of town until today. But yes, I just figured it out. For some reason AutoFPS was thinking OFXR was paused, even though it wasn't. So I toggled the Pause function on and off, and that straightened things out for me.

It's awesome to hear you and djules are collaborating on this. Thanks for the hard work!

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.

11 hours ago, Reset XPDR said:

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.

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.

Edited yesterday at 02:37 AM1 day by Reset XPDR

22 hours ago, Reset XPDR said:

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.

I did a 3-hour flight with it yesterday and everything was working flawlessly. I admit that I don't use the widget much because AutoFPS is just perfect.

AutoFPS Widget update: Forgive me if I'm simply doing things wrong. I can't seem to get the hang of auto-updating the widget (main app is absolutely fine).

1) Because of [the understandable] file-locking when I update in-sim, the widget is set to update on the next AutoFPS launch ... except it doesn't.

2) If I grab the latest from GitHub, the installer/updater doesn't follow the symlink to the external folder (I link to it with Addons Linker). Instead, it deletes the symlink and places the widget in my Community folder. I then have to move it to its usual (external) location.

What am I doing wrong?

As xzever (above) has said ... I rarely use the widget (as the main app works perfectly), but I'm intrigued all the same. What's the correct procedure if you're using Linker (for manual and in-sim updates)?

It's trivial, really, but it does give me another opportunity to thank you again for such an indispensable addon :)

16 minutes ago, Adamski_NZ said:

AutoFPS Widget update: Forgive me if I'm simply doing things wrong. I can't seem to get the hang of auto-updating the widget (main app is absolutely fine).

1) Because of [the understandable] file-locking when I update in-sim, the widget is set to update on the next AutoFPS launch ... except it doesn't.

2) If I grab the latest from GitHub, the installer/updater doesn't follow the symlink to the external folder (I link to it with Addons Linker). Instead, it deletes the symlink and places the widget in my Community folder. I then have to move it to its usual (external) location.

What am I doing wrong?

As xzever (above) has said ... I rarely use the widget (as the main app works perfectly), but I'm intrigued all the same. What's the correct procedure if you're using Linker (for manual and in-sim updates)?

It's trivial, really, but it does give me another opportunity to thank you again for such an indispensable addon :)

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.

OK - thanks for your detailed instructions. Things are set up as in your screenshots (and AutoFPS is set to open/close with MSFS).

I think I see what the problem is: the Custom Path. I think I need to set that path to my custom location for only the AutoFPS addon. I expected that the updater would simply follow the symlink - but it doesn't. As it stands, that last screenshot implies that it should be set to your regular Community folder - the path to which is stored correctly

I've just re-run the installer, setting the custom location to my externally linked location - and got the prompt about making sure its enabled via Linker (and then the prompt about removing the old symlink) - which is good. Maybe it's just semantics/terminology, but I find it a little confusing: the external location for the widget is not my Community folder.

OK ... I'm still not getting it right (arrrrgh)! After setting the custom folder, I re-ran the installer - with the widget enabled via Linker. I got the same warnings as before - but the existing symlink was deleted, so I had to recreate/re-enable it via Linker. Why can't the installer simply follow the existing symlink to the custom folder (and not delete it)?

This is how I think it should work (tell me if I'm wrong!!):

Path set in AutoFPS to the normal/regular Community folder.

1) No symlink or Widget found, so create it there (in the Community folder).

2) Existing symlink found: follow the link and update the old widget files (in the external/non-community folder).

I hope I've explained that properly!!! ;)

43 minutes ago, Adamski_NZ said:

OK - thanks for your detailed instructions. Things are set up as in your screenshots (and AutoFPS is set to open/close with MSFS).

I think I see what the problem is: the Custom Path. I think I need to set that path to my custom location for only the AutoFPS addon. I expected that the updater would simply follow the symlink - but it doesn't. As it stands, that last screenshot implies that it should be set to your regular Community folder - the path to which is stored correctly

I've just re-run the installer, setting the custom location to my externally linked location - and got the prompt about making sure its enabled via Linker (and then the prompt about removing the old symlink) - which is good. Maybe it's just semantics/terminology, but I find it a little confusing: the external location for the widget is not my Community folder.

OK ... I'm still not getting it right (arrrrgh)! After setting the custom folder, I re-ran the installer - with the widget enabled via Linker. I got the same warnings as before - but the existing symlink was deleted, so I had to recreate/re-enable it via Linker. Why can't the installer simply follow the existing symlink to the custom folder (and not delete it)?

This is how I think it should work (tell me if I'm wrong!!):

Path set in AutoFPS to the normal/regular Community folder.

1) No symlink or Widget found, so create it there (in the Community folder).

2) Existing symlink found: follow the link and update the old widget files (in the external/non-community folder).

I hope I've explained that properly!!! ;)

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.

Edited yesterday at 08:35 AM1 day by Reset XPDR

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

Phew!! This is turning out to be a 1,000pp non-fiction novel LOL! Apologies to all our forum guests!

I really appreciate the time you've put in to explaining how things actually work (as opposed to me guessing how they might work) ;).

Now that I have some very clear instructions I will try and stay out of your hair (!!). :)))

Duplicate

Edited 14 hours ago14 hr by Reset XPDR
Duplicate Deleted

9 hours ago, Adamski_NZ said:

Phew!! This is turning out to be a 1,000pp non-fiction novel LOL! Apologies to all our forum guests!

I really appreciate the time you've put in to explaining how things actually work (as opposed to me guessing how they might work) ;).

Now that I have some very clear instructions I will try and stay out of your hair (!!). :)))

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.

May I please ask whether to use auto, ofxr, vr or nvidia fg mode? Do I lock frames in nvidia cp at 36 for my quest 3 @ 72hz and 2x framegen in bridge?

Thanks in advance. A ton of conflicting info out there right now.

Edited 10 hours ago10 hr by glennc
Clarification

1 hour ago, glennc said:

May I please ask whether to use auto, ofxr, vr or nvidia fg mode? Do I lock frames in nvidia cp at 36 for my quest 3 @ 72hz and 2x framegen in bridge?

Thanks in advance. A ton of conflicting info out there right now.

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.

Edited 9 hours ago9 hr by Reset XPDR

On 10/13/2026 at 6:21 AM, FakeWayne said:

Hey sorry for not responding, I was out of town until today. But yes, I just figured it out. For some reason AutoFPS was thinking OFXR was paused, even though it wasn't. So I toggled the Pause function on and off, and that straightened things out for me.

It's awesome to hear you and djules are collaborating on this. Thanks for the hard work!

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!

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.