1 hour ago, Reset XPDR said:

FYI, trying out imgbb like you suggested.

I can see clearly now, it's gonna be a bright bright sunny day.😀

I haven't tried your tool yet because it sounds like studying again more readme's, but I might if it increases my fps (which are not bad: 60-70 in VR, 80-150 in 2D at mostly low density airports and other areas where I usually fly).

I like your cute doggy avatar, say hello from me.

Edited January 26Jan 26 by turbomax

34 minutes ago, turbomax said:

I can see clearly now, it's gonna be a bright bright sunny day.😀

I haven't tried your tool yet because it sounds like studying again more readme's, but I might if it increases my fps (which are not bad: 60-70 in VR, 80-150 in 2D at mostly low density airports and other areas where I usually fly).

I like your cute doggy avatar, say hello from me.

No need to read the whole readme. Just do this from the FAQ and you will be fine:

What is the simplest way to use this app to make my MSFS experience better?

• Leave your relevant MSFS graphics settings set as you normally would without this app,
• Start the app before you load your flight,
• Leave Use Expert Settings unchecked,
• Pick what type of flight you are doing via the drop down list ie. either VFR (GA aircraft) or IFR (airliners),
• If using an FPS cap, enter that as your target FPS otherwise enter a target FPS your system can usually easily achieve or click on auto target FPS for the app to pick it for you,
• Click back on MSFS and wait until any FPS settle or TLOD seek events have finished (60 seconds max), then
• Go fly!
• Due to potential settings conflict, don't change any MSFS graphics settings that could be adjusted by AutoFPS while in a flight with AutoFPS already running.
• If performance still drops significantly in complex scenarios or you receive memory capacity warnings, see the VRAM+ FAQ entry.

Today, while updating FSUIPC to the latest version, I found its uninstaller stuck in a loop while trying to update the MSFS exe.xml. After digging into it, the issue turned out not to be FSUIPC at all, but a legacy AutoFPS behaviour: recent versions saved the exe.xml in a non‑standard format when enabling Auto‑start with MSFS. MSFS accepted it, but the FSUIPC uninstaller did not.

The fix is now in place — the installer automatically detects this legacy format and rewrites the exe.xml into a fully compatible one without altering any of its contents.

If this is affecting you, the fix is available in 0.4.6.4‑test1 or later and will be formally released shortly. Please don’t raise this with the FSUIPC developer if you hit the issue after using AutoFPS with Auto‑start enabled — it’s an AutoFPS problem, and it’s already being resolved for everyone.

Nice catch - and thanks for fixing it so promptly. I upgraded my FSUIPC a day or so ago and didn't have a problem (phew!). I have huge respect for the Dowsons and hope they didn't get too many support requests 😉

3 minutes ago, Adamski_NZ said:

Nice catch - and thanks for fixing it so promptly. I upgraded my FSUIPC a day or so ago and didn't have a problem (phew!). I have huge respect for the Dowsons and hope they didn't get too many support requests 😉

No one has reported it to me but I can see why because the way the issue presents itself, it looks very much like an FSUIPC issue. If you have never used Auto-start with MSFS it should not be a problem and, as I found out today while poking the bear, FSUIPC will still uninstall everything else and won't modify your exe.xml when reinstalling, which actually means FSUIPC will continue to auto-start with MSFS regardless of this issue. Talk about luck!

I did read the FAQ on FSUIPC exe.xml issues and they do actually have a section on what the right and wrong file save formats are, so it is covered. Nonetheless, users should not have to go to such lengths to fix something caused by another app and to the Dowsons, if you are reading this, I am truly sorry this happened and went on for so long due the extremely subtle nature in which it manifests it self. Rest assured, it will not happen again!

Overseeing and - if needed - correcting such important files manually every other day pays off.

It's a shame how careless (or clueless..., NOT YOU, ResetXPDR !) some add-on producers are when it comes to correct *.xml formatting.

 

Edited February 4Feb 4 by MaGer1965

Also worth noting for the upcoming 0.4.6.4 formal release is that I will no longer be providing one‑on‑one support for individual SimConnect Exception 31 cases. The popup now gives clear, step‑by‑step instructions, and the readme explains the process in full. Almost all of the support load has come from users not following those steps in order or exactly as written, and I’m simply not going to keep walking people through something that’s already been laid out for them.

This might sound a bit blunt, but this is a freeware app and I’ve put a lot of work into making both the app and the recovery instructions as robust as possible. The only time I’ll revisit this is if a large number of users suddenly start seeing the issue again, for example due to an MSFS or SimConnect change. In that case I’ll likely be affected too and will work on a fix.

Thanks for correcting this. FSUIPC does have an issue installing or uninstalling if the EXE.xml is a badly formed xml document or is in an encoding format that it cannot read (mainly the non-standard *-BOM formats, and UTF-8).

The installer handles this by logging a message and continuing, and means that the FSUIPC entry in the EXE.xml won't be added. However, it seems that the uninstaller just hangs if it can't open/parse the EXE.xml, and the only solution is to stop/kill it. I will see if I can update the uninstaller to just log a message and continue.

There seem to be several 3rd-party installers that write or change the encoding of the exe.xml file to a BOM or UTF-8 format. Unfortunately its not easy for me to update the installer/uninstaller to handle such formats, but the uninstaller should at least fail gracefully and not hang.

Cheers,

John / FSUIPC

17 hours ago, John Dowson said:

Thanks for correcting this. FSUIPC does have an issue installing or uninstalling if the EXE.xml is a badly formed xml document or is in an encoding format that it cannot read (mainly the non-standard *-BOM formats, and UTF-8).

The installer handles this by logging a message and continuing, and means that the FSUIPC entry in the EXE.xml won't be added. However, it seems that the uninstaller just hangs if it can't open/parse the EXE.xml, and the only solution is to stop/kill it. I will see if I can update the uninstaller to just log a message and continue.

There seem to be several 3rd-party installers that write or change the encoding of the exe.xml file to a BOM or UTF-8 format. Unfortunately its not easy for me to update the installer/uninstaller to handle such formats, but the uninstaller should at least fail gracefully and not hang.

Cheers,

John / FSUIPC

Thanks for commenting and again sorry for any incovenience this caused - I was simply not aware it was doing this. eg. here is the offending line in the original code:

                        // Save modified file in UTF-8
                        File.WriteAllLines(path, newLines, Encoding.UTF8);

which I had no idea would save the file as UTF8 with BOM, but I live and learn.

I am not sure what language your installer is written in, but if C# and .NET 8 it is two lines to ensure that, if BOM is detected, EXE.xml is BOM free before you do any further operations on the file:

                   bool hasBom = false;

                   // Inline UTF‑8 BOM detection
                   using (var fs = new FileStream(path, FileMode.Open, FileAccess.Read))
                   {
                       if (fs.Length >= 3)
                       {
                           int b1 = fs.ReadByte();
                           int b2 = fs.ReadByte();
                           int b3 = fs.ReadByte();
                           hasBom = (b1 == 0xEF && b2 == 0xBB && b3 == 0xBF);
                       }
                   }

                   if (hasBom)
                   {
                       // Read as UTF‑8 (BOM handled automatically), write as UTF‑8 without BOM
                       string xml = File.ReadAllText(path);
                       File.WriteAllText(path, xml, new UTF8Encoding(encoderShouldEmitUTF8Identifier: false));
                   }
    

While AutoFPS and DynamicLOD_ResetEdition will no longer BOMify the file like before, other apps may so you may wish to add something like it to your next installer to defend against any other dodgy devs out there like me 😜😆 

Edit: Just for completeness, your own FAQ actually matches what I saw during testing. It says the EXE.xml should be either standard UTF‑8 or Windows‑1252, and that UTF‑8 BOM is not recommended. That lines up exactly with what I ran into: UTF‑8 without BOM worked fine for both install and uninstall, while UTF‑8 with BOM was the only format that consistently caused problems. So from everything I’ve seen, plain UTF‑8 is safe for FSUIPC, and it’s only the BOM variant that needs defending against.

Edit2: I realise your strong preference is to keep the file in Windows‑1252, but after spending a solid hour trying every supported .NET 8 mechanism for forcing that encoding, the runtime still consistently outputs UTF‑8 without a BOM. Since BOM‑free UTF‑8 works reliably across MSFS, AutoFPS, and FSUIPC, and the version I released two days ago has had zero negative feedback, I’m planning on leaving the behaviour exactly as it is.

Edited February 6Feb 6 by Reset XPDR

MSFS_AutoFPS 0.4.6.4 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 update fixes EXE.xml formatting so all MSFS tools read it reliably and improves Exception 31 handling with clearer guidance.

On 2/6/2026 at 3:48 AM, Reset XPDR said:

So from everything I’ve seen, plain UTF‑8 is safe for FSUIPC, and it’s only the BOM variant that needs defending against.

Yes, it is the BOM format that causes issues, in fact, any BOM format. Standard UTF-8 is fine.

On 2/6/2026 at 3:48 AM, Reset XPDR said:

I realise your strong preference is to keep the file in Windows‑1252

I don't really have a strong preference here. If FSUIPC creates the EXE.xml, it will use windows-1252, mainly for historical reasons. But it will not change the format if the file already exists.

On 2/6/2026 at 3:48 AM, Reset XPDR said:

I am not sure what language your installer is written in, but if C# and .NET 8 it is two lines to ensure that, if BOM is detected, EXE.xml is BOM free before you do any further operations on the file:

I actually use a scripting language called NSIS (Nullsoft Scriptable Install System), and an XML plugin for NSIS that handles XML documents. Unfortunately it is this plugin which has issues with xml documents encoded with a BOM.

Also note that the BOM header is not required or recommended in the unicode standard. Not sure why writing a UTF-8 file in a standard way would also write a BOM, which seems to be the issue with quite a few installers.

Anyway, thanks for updating your installer for this. l will see if I can do anything about this in the FSUIPC7 installer, when I get a chance.

Regards,

John

 

@Reset XPDR So I have to say. I was a huge skeptic of this app. Read so many of these pages… and I was to the point that I disagreed with friends about its functionality. Even labeled it as just another placebo app to make folks think their sim has really improved.

Well, I’m here to say I was dead wrong. I have done about 20-30 flights so far and I really do see the benefits of this app. At cruise, seeing improved textures that I’ve never seen before, all while maintaining my fps. To coming in on approach and final with so few (if any!) stutters. Flying into DFW, LAX, JFK without a single hint of a stutter, all while flying in 4K has been amazing.

I went from someone who swore off using these apps to now it’s apart of my daily process for setting up my sim. Thanks for this excellent add-on! Just thought I’d post this here for any others on the fence and to also say thanks!

Thank you kindly for the generous feedback. I really appreciate it. I have put a lot of time into refining the app over the past year, so it is great to hear it is still helping people get a smoother experience.

The core idea behind it has always been simple: use lower TLOD down low where the extra detail cannot really be seen, and raise it at altitude where the clarity actually matters. It is the one thing the built‑in Dynamic Settings still does not handle, even though they have improved a lot since release. The two now work well together when both are enabled.

Thanks again for taking the time to share your experience. It means a lot.

 

If you don't hear from me too often, it's because everything is working flawlessly! That doesn't stop me adding to the votes of thanks 😉 

Your AutoFPS and Addons Linker (from BadT) are by far and above the best addons for MSFS (with LittleNavMap close behind). Superb programming from all! 

4 hours ago, Reset XPDR said:

Thanks again for taking the time to share your experience. It means a lot.

such a friendly developer with the cutest avatar!