v0.5.4.3-test Widget Improvements & OFXR Support

[ResetXPDR]

MSFS Compatibility: 1.39.12.0, 1.8.16.0, 1.9.16.0.
MSFS Widget Version: 1.3.0

Release notes for 0.5.4.3-test

Test1:

• Added a user-configurable Show/Hide keyboard shortcut to the in-game widget to toggle its visibility on demand:
  • Defaults to "No Hotkey" to prevent unintended key assignment conflicts.
  • To assign: Click the Show/Hide button on the widget toolbar and press your desired key combination (e.g. Alt+Shift+A).
  • To clear: Click the button a second time while listening (or press Escape, Backspace, or Delete) to reset to "No Hotkey".
  • Disclaimer: Users are responsible for ensuring their chosen key combination does not conflict with existing MSFS controls, camera views, or aircraft keybindings.
• Reinstated special symbols (▲ ▼ ⊥ ⊤ Δ ⚡ ⏸ ❄️ 🔒) on applicable in-game widget status lines to exactly match the app UI.

---

This discussion was created from the release v0.5.4.3-test Widget Improvements.

[ResetXPDR]

By default when first run:

Clicking the hotkey button:

After setting:

Then pressing that key combo should hide/show it. Note it must be opened first before the widget will respond to the hotkey. It's just the way the MSFS interface works without getting all hacky and running the risk of it breaking in future - a small price to pay!

Oh, and in that last image you will see that all your favourite symbols are there to match what you see in the app UI. Enjoy!

[jerryyyyy]

Looks good. Will run a flight later today.

[ResetXPDR]

Looking at your screenshot, the installer was trying to install the widget into the root game folder (...\Microsoft.Limitless_8wekyb3d8bbwe), which is neither your default MSFS 2024 community folder nor your Addon Linker folder, which explains why it gave that warning.

To help me confirm what happened and get your widget set up cleanly, could you please do these exact steps in order:

1. BEFORE running the installer again:

• Please find your current install.log file (located in the app root directory, where your app config files are) and attach it here.

2. Open the installer:

• Change the MSFS 2024 Community Folder location to:
  D:\MSFS_Addons_Linker\Linker_Community
• Click Update.

3. During/after the update:

• Take a screenshot of any message popups that appear.
• Attach the new install.log and the screenshot in your reply.

4. In MSFS Addons Linker:

• Refresh/check Addons Linker to make sure autofps-html-widget-panel is enabled and linked into MSFS.

[jerryyyyy]

I think I fixed it reading the screenshot looks like the plug in went to the root folder. I cut it out of there and put in my root folder for Add on Linker, then activated it in Add on linker....

Boy, when I put my mind to it I can certain screw up a program!

All these changes are at the end of the log if they were recorded.

MSFS_AutoFPS20261006.log

[ResetXPDR]

You are definitely making this much harder to fix by going rogue on me! 😄

As you saw with that new warning popup, manually cutting and pasting files doesn't fix the root problem. AutoFPS actually remembers where it thinks your folders are. Because you moved the files by hand, the app's internal settings are still pointing to the game's root folder. That means every time an auto-update runs in the future, it will keep breaking and dumping files back into that root folder again!

To fix your setup cleanly once and for all, please follow these exact steps in order (and please don't move anything manually this time!):

1. Close MSFS.

2. Clean up the manual copies:

   Delete any autofps-html-widget-panel (and mobiflight-event-module) folders you manually pasted or cut (check your Addons Linker folder, the real Community folder, and the root Microsoft.Limitless folder). Let's wipe the slate completely clean.

3. Run the AutoFPS 0.5.4.3-test2 Installer:

   In the installer window, set your MSFS 2024 Community Folder location to your Addons Linker folder:
   D:\MSFS_Addons_Linker\Linker_Community

   Click Update.
   (This tells AutoFPS where your mods actually live, saves the correct path to the config file, and cleanly installs the latest widget files there).

4. In MSFS Addons Linker:

   Refresh Addons Linker and enable/link autofps-html-widget-panel so it activates in MSFS.

5. Hands off!

   Never touch or move those folders manually again! From now on, the installer knows where your Addons Linker folder is and will handle all future updates cleanly on its own.

[jerryyyyy]

Back to baseline... promise to leave the folders alone....

[ResetXPDR]

@jerryyyyy , I don't know if you have tried the OFXR bridge mod which gives FG 2X and 3X in VR yet, but I did today and updated the app in test3 to fully support it. Coding challenge aside, the mod itself gave me really good results, so I will probably stick with it for now.

You can read about the change to AutoFPS here. You can find the mod here. If you do try it, don't forget to turn off motion reprojection in your VD settings on the headset!

[jerryyyyy]

Had a false start as did not have OFXR running after a reboot. Here is a short flight. Again busy today.

MSFS_AutoFPS20261009.log

Longer flight and OFXR shortcut now in startup folder (C:\Users\yesav\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup)

Looks good with a few spikes maybe in high demand situations.

Test4_MSFS_AutoFPS20261009.log

[ResetXPDR]

Thanks for that. I can see that the new logging is showing you using 3X FG, which is good.

I see you changed your target FPS to 80, however you still have it as Fixed whereas you are not consistently getting a Fixed FPS like you used to, so you should change that to Manual.

2026-10-09 12:44:50.968 [DBG] [ LODController:DetectFixedFPS     ] RawFPS: 25.9, 22.7, 24.9, 17.4, 7.4, 17.2, 16.2, 18.7, 26.8, 26.3, 21.6, 20.6, 23.9, 28.9, 27.9, 25.3, 21.2, 21.9, 21.5, 24.0 
2026-10-09 12:44:50.968 [DBG] [ LODController:DetectFixedFPS     ] Atmpt:1 DomFPS:64.5 Tol:±0.50 SD+:0.150 SDMax:0.125 In:4 Out+:10 FixedFPS:N 
2026-10-09 12:45:05.412 [DBG] [ LODController:DetectFixedFPS     ] RawFPS: 25.9, 22.7, 24.9, 26.5, 21.9, 26.7, 26.3, 21.5, 26.1, 29.2, 22.6, 29.7, 29.8, 29.8, 27.3, 29.6, 29.9, 21.9, 21.5, 24.0 
2026-10-09 12:45:05.412 [DBG] [ LODController:DetectFixedFPS     ] Atmpt:2 DomFPS:90 Tol:±0.50 SD+:0.047 SDMax:0.125 In:5 Out+:0 FixedFPS:N 
2026-10-09 12:45:26.011 [DBG] [ LODController:DetectFixedFPS     ] RawFPS: 26.5, 29.3, 29.8, 29.7, 29.8, 29.4, 29.4, 29.5, 28.0, 24.2, 21.7, 27.4, 29.6, 29.6, 28.8, 27.7, 27.1, 29.2, 29.0, 26.9 
2026-10-09 12:45:26.011 [DBG] [ LODController:DetectFixedFPS     ] Atmpt:3 DomFPS:88.5 Tol:±0.50 SD+:0.089 SDMax:0.125 In:9 Out+:0 FixedFPS:N 

[jerryyyyy]

I think this is the latest version. I ran the Aussi Corp Ops plan for today at 16X using p42-util-flow-Tim Wells-sim-rate in Flo. I think your software survived. The 1.5h plan ran very fast.

16X MSFS_AutoFPS20261010.log

[ResetXPDR]

Your app correctly didn't actually update until you exited MSFS, because there was a widget update. This is the first time I have seen it in someone else's log, which is good.

BTW, when you next run the app with MSFS, take a look at the changes in test5 to the widget while in VR. Of particular note is that I have introduced auto height sizing of the widget window, as I have seen in a few screenshots from others that they have a lot of unnecessary dead space on the bottom margin. Now you can't change the bottom margin, because it is the one being auto sized, so you change the widget window size by width on the right.

Have a play with resizing the widget in VR and make sure it auto resizes without any clipping of the bottom margin. I had to reduce the font scaling slightly so that it would not clip on mine and I want to make sure it is acceptable on yours too. Send a screenshot if anything looks odd. You can take one by pressing ALT Print Screen while looking at the widget in VR, then crop it down so it looks something like this:

Here is an example of what it looks like when it is clipping, which it should no longer be doing BTW:

Thanks.

[jerryyyyy]

Hi, well I actually noticed the change in a long flight today. I think the log is Ok but I had one MsfS crash along the way fooling with a flight plan.

In any case I now have 4 panels floating around the cockpit so tried to arrange yours and was happy to see that I could rearrange it to make it level and even. The resizing worked for me. I noticed the new version number. I actually fooled with it for a while and seemed OK...

MSFS_AutoFPS20261010.log

The actual VR etc. seems to run fine. Was looking for aliasing artifacts and saw a little bit from the side window.

[jerryyyyy]

I saw your extensive write up on the MSFS Forum. I think if I have the time and energy I will try the to do some quantification like I used to do with the 5080... maybe it behaves differently than your 4090. I guess I can use the same set-up as you did at the gate. I wonder what airport, gate and aircraft you were using to load the program the same. I do not get the impression that the 3X is overloading the GPU.

Here is a long flight and looks like it ran at pretty much 89 FP and 70% or so GPU.

MSFS_AutoFPS20261011.log

I have to do my RENO flight and also the gate at SFO and see what it looks like but this looks pretty smooth to my eye.

PS Looks like it updated at the end to a RC1. Widget looked fine.

[ResetXPDR]

I dreamed up the test matrix and conditions then had Gemini parse my AutoFPS log data to come up with that analysis and recommendations. There was nothing special where I was, which was in fact not at a gate as my post mentions but on the runway at YCKN in the C208.

I was surprised there was so much of a hit with FG on my system ie roughly 20% for 2X and 30% for 3X. As I already know, you were using 36 FPS and SSW to get 72 FPS whereas now you are using 30 x 3 to get 90 FPS most of the time, so a roughly 20% drop for 3X versus 30% on mine. I was using an older nVidia driver for that test, so yesterday after doing the test I updated to the latest but have not tested those scenarios again with it. In the past, it generally make little difference which driver I use as long as it is reasonably current.

The main point I wanted to get across in my post is that if you already had an acceptable SSW arrangement like I do, then it might be worth staying with it and forgo the 10% better frame rate for a smoother experience with less artifacts.

BTW, RC was out just recently, but I will likely just go formal release imminently as I am going away tomorrow and I like to be around the day after a release in case there are any issues. As always, thanks for your continued feedback and logs, which have helped me shape this into the final form you are now experiencing. I am quite happy with the Widget's UI state in this release and intend to only touch it for maintenance in the future.

[jerryyyyy]

Yes, was pretty happy with the 36->72 result but just subjectively the 30->90 looked better.

I ran the 787 short NUQ->SFO flight and there is no free lunch. Still slowed down close to the complex airport. Not sure if it is that much different.

I am running the latest NVIDIA driver as I have just automatically upgraded after about a week to make sure it was not a disaster.

This is the edited down file for the 787 flight.

Cheers

NUQ SFO MSFS_AutoFPS20261011.log