9 minutes ago, Reset XPDR said:

Why did you kill the AutoFPS process instead of just closing the app down normally? I am not surprised AutoFPS won't reconnect to simconnect if you kill it because you left MSFS's interface thinking AutoFPS was still connected and therefore would not allow another connection to the same app. Not only that, you didn't give the app the chance to restore all MSFS settings back to default so MSFS will be stuck in what ever state it was when you killed it.

The simple solution is to stop killing AutoFPS and just close it down normally or just manually switch between IFR and VFR in the app when you are picking your different aircraft.

Edit: I just had a thought that I could provide a command line option in the app where it auto exits the app whenever a flight ends rather than waiting for another flight to occur. Would that work?

Thanks for the quick reply, yeah would maybe help. Dont know how you will detect the flight Ends? Would hell if i could change between VfR and ifr setting in the APP via command line? The Problem is that my simulator doesnt have a mouse and extra screen so i wanted to Automaten the switching of the autofps profile without me doing anything :)

51 minutes ago, Bam2000 said:

Thanks for the quick reply, yeah would maybe help. Dont know how you will detect the flight Ends? Would hell if i could change between VfR and ifr setting in the APP via command line? The Problem is that my simulator doesnt have a mouse and extra screen so i wanted to Automaten the switching of the autofps profile without me doing anything :)

The app already detects when a flight ends, but it currently always stays running. You already can change between IFR and VFR profiles via command line, which I thought was how you were doing it. As I said, I could make it so you can configure the app to auto exit after the first flight session has ended, whether that be via a command line option or something you manually set in the config file, then you can auto start in IFR or VFR by using the command line switch. That way you could have your controlling app auto start AutoFPS between flight sessions.

15 minutes ago, Reset XPDR said:

The app already detects when a flight ends, but it currently always stays running. You already can change between IFR and VFR profiles via command line, which I thought was how you were doing it. As I said, I could make it so you can configure the app to auto exit after the first flight session has ended, whether that be via a command line option or something you manually set in the config file, then you can auto start in IFR or VFR by using the command line switch. That way you could have your controlling app auto start AutoFPS between flight sessions.

Okay, so i use the command to start the app in either VFR or IFR Mode, but can i change it on the fly without closing the app? Then my Problem would be solved already :D if not yeah i would need to close the app Properly without forcing and destroying it and then reopen it in the other Profile mode when i switch airplanes

1 hour ago, Bam2000 said:

Okay, so i use the command to start the app in either VFR or IFR Mode, but can i change it on the fly without closing the app? Then my Problem would be solved already :D if not yeah i would need to close the app Properly without forcing and destroying it and then reopen it in the other Profile mode when i switch airplanes

No you can't change IFR or VFR by command line argument when the app is already running as these arguments are only passed to the app when starting it. Also, if the app is already running it is normal for you to change it yourself but I understand your desire to automate this instead.

In any case, it was a simple change to the app to have it be able to auto exit after you finish a flight session, so I have implemented it in 0.5.2.0-test10 or later available here. To enable it, do the following:

• Run the updated app at least once for it to create the required configuration file key, then exit the app.

• Edit MSFS_AutoFPS.config, located in %appdata%\MSFS_AutoFPS, as a text file.

• Locate the line <add key="ExitAppAfterFlightSession" value="false" />, which should be near the end of the file, and change "false" to "true".

• Save the config file then run AutoFPS.

• AutoFPS will remain running until about 5-10 seconds after you have completed your first flight session, then it will auto exit without prompting you.

Give it a try and let me know if this new auto shutdown after the first flight session combined with using IFR or VFR command line arguments on startup meets your desired automation needs.

FYI, the latest 0.5.2.0 test version, available here, now supports dynamic/adapative FG. When using this type of FG, the multiplier varies constantly to provide your in-game target FG FPS, which was not and still is not detectable by AutoFPS. Therefore in order for AutoFPS to automate correctly, the target FPS must be specified as a Native Frame Rate (NFR), not a post-FG FPS target like all other auto FG modes.

To achieve this, you firstly select Man FG:

Then select DynFG:

Now specify your DynFG target FPS as an NFR value slightly lower than what your system can regularly achieve on the ground. If you use MSFS as the FPS source in AutoFPS (ie. the FS image next to your FPS reading), then it will show you what NFR FPS you are currently achieving when DynFG has been chosen. Also, choose Manual for the target FPS option because your FPS is going to vary with this type of FG.

eg. Below you can see I am achieving 56 NFR FPS (which roughly corresponds with the 110 FPS shown in game on the RTSS overlay in this instance ie. 2X FG is currently active), so I set the DynFG target FPS to 50 to be slightly below it.

Anyway, if you use dynamic/adapative FG, please give this a go and let me know if it works for you and if I have made the instructions clear enough for me to update the readme with when I formally release this new version. I have already had the user who originally requested it have a go and they were happy with it, so I hope others find it useful too.

Is there a fix to where autofps keeps making the cockpit get really bright for a few moments then back to normal ...

2 hours ago, Reset XPDR said:

FYI, the latest 0.5.2.0 test version, available here, now supports dynamic/adapative FG. When using this type of FG, the multiplier varies constantly to provide your in-game target FG FPS, which was not and still is not detectable by AutoFPS. Therefore in order for AutoFPS to automate correctly, the target FPS must be specified as a Native Frame Rate (NFR), not a post-FG FPS target like all other auto FG modes.

To achieve this, you firstly select Man FG:

Then select DynFG:

Now specify your DynFG target FPS as an NFR value slightly lower than what your system can regularly achieve on the ground. If you use MSFS as the FPS source in AutoFPS (ie. the FS image next to your FPS reading), then it will show you what NFR FPS you are currently achieving when DynFG has been chosen. Also, choose Manual for the target FPS option because your FPS is going to vary with this type of FG.

eg. Below you can see I am achieving 56 NFR FPS (which roughly corresponds with the 110 FPS shown in game on the RTSS overlay in this instance ie. 2X FG is currently active), so I set the DynFG target FPS to 50 to be slightly below it.

Anyway, if you use dynamic/adapative FG, please give this a go and let me know if it works for you and if I have made the instructions clear enough for me to update the readme with when I formally release this new version. I have already had the user who originally requested it have a go and they were happy with it, so I hope others find it useful too.

Thank you for this info. Going to try it ( 3x 4K view ).

Just wondering : I have always used Dyn Settings with AutoFPS and it looked liked they worked together. I have changed to FSR3 becauase then the 3 sceens are all hardware accelerated. Can I benefit from this new feature or only when using the MSFS24 FG ?

Edited July 14Jul 14 by GSalden

5 hours ago, steve 86 said:

Is there a fix to where autofps keeps making the cockpit get really bright for a few moments then back to normal ...

What app settings are you using and what does it show it is doing when the cockpit changes brightness like this?

3 hours ago, GSalden said:

Thank you for this info. Going to try it ( 3x 4K view ).

Just wondering : I have always used Dyn Settings with AutoFPS and it looked liked they worked together. I have changed to FSR3 becauase then the 3 sceens are all hardware accelerated. Can I benefit from this new feature or only when using the MSFS24 FG ?

MSFS dynamic settings should work the same with the app regardless of what flavour of FG, or none at all, you are using. I have used it myself with pretty much all of them out there.

12 hours ago, Reset XPDR said:

Anyway, if you use dynamic/adapative FG, please give this a go and let me know if it works for you and if I have made the instructions clear enough for me to update the readme with when I formally release this new version. I have already had the user who originally requested it have a go and they were happy with it, so I hope others find it useful too.

Hi, just a short little test feedback: works great. Seems to be less fluctuating compared to reading the postFG numbers via RTSS. In my case, I have limited FS to 31 frames, giving me 62 with build in FG on, dynamic frames set to 30 for small headroom. So, I set FIXED under General tab, Target to DynFG and FPS to 30. but there seems to be one side effect: during pre flight preparation , I have to switch between several windows. With the older FG reading via RTSS, AutoFPS recognized FG to become inactive and ignored the lower framerate. Now, it detects spiking, and so, it lowers TLOD to min, but being on ground, TLOD does not recover when switching back to FS main window. I remember, that is was designed to freeze TLOD reduction in certain situations. Clicking on the RESET button brings back a TLOD plus recovery, but as I use AutoFPS minimized in normal situations, it would be nice to ignore spike protection when switching between several windows. I hope, my writing is clear enough 🫣

Greetings, Matthias

4 hours ago, ankh21 said:

Hi, just a short little test feedback: works great. Seems to be less fluctuating compared to reading the postFG numbers via RTSS. In my case, I have limited FS to 31 frames, giving me 62 with build in FG on, dynamic frames set to 30 for small headroom. So, I set FIXED under General tab, Target to DynFG and FPS to 30. but there seems to be one side effect: during pre flight preparation , I have to switch between several windows. With the older FG reading via RTSS, AutoFPS recognized FG to become inactive and ignored the lower framerate. Now, it detects spiking, and so, it lowers TLOD to min, but being on ground, TLOD does not recover when switching back to FS main window. I remember, that is was designed to freeze TLOD reduction in certain situations. Clicking on the RESET button brings back a TLOD plus recovery, but as I use AutoFPS minimized in normal situations, it would be nice to ignore spike protection when switching between several windows. I hope, my writing is clear enough 🫣

Greetings, Matthias

When MSFS loses focus and FG becomes inactive your capped NFR FPS should, if anything, be easier for your system to achieve as the overhead of performing FG has been removed, so your TLOD should have held. For the AutoFPS automation engine, the original auto FG modes scale up the NFR FPS being sent by MSFS by the set multiplier it reads from MSFS settings regardless of whether FG is active or not for consistent calculations, so when FG is inactive the NFR FPS when uncapped is usually higher.

This is why TLOD increases are not allowed when FG is inactive because the current performance is too optimistic compared to when FG becomes active again. TLOD decreases though are fair game. This new DynFG option actually works the same except that it uses a scale of 1x (ie. NFR), because it does not know the current multiplier dynamic FG has chosen. ie it has simply removed the multiplier from the equation, thus giving the same result as if it were known.

The following screenshots show my attempt at recreating your stated scenario. Firstly, with FG on, where you can see the in-game FPS is double what the app shows as the NFR frame rate and TLOD ranges up to maximum:

Now, when FG becomes inactive, you can see the in-game FPS drops to NFR and the GPU load decreases from 51% to 42%, meaning even more headroom and TLOD therefore does not decrease.

Nonetheless, it is possible that you have uncovered a unique settings combination where the above does not happen, so I'd like to look into that. To that end, can you PM me the snippet of your log file where you see TLOD dropping when FG becomes inactive, or the entire log file if it is not clear where that is as the log is a bit cryptic. The logs are located in %appdata%\MSFS_AutoFPS\log. Thanks.

Edited July 14Jul 14 by Reset XPDR
Clarified with more relevant example.

On 7/14/2026 at 7:48 AM, Reset XPDR said:

eg. Below you can see I am achieving 56 NFR FPS (which roughly corresponds with the 110 FPS shown in game on the RTSS overlay in this instance ie. 2X FG is currently active), so I set the DynFG target FPS to 50 to be slightly below it.

I will test this build today but I have a question first. I always set my FPS limit and dynamic settings in the sim to 30 FPS and use Lossless Scaling adaptive mode to achieve 60 FPS. My system can almost always achieve the 30 FPS so should my DynFG target FPS be set to 30 or 28 or what?
Thanks.

Will do as soon as i am at home today.

Thanks for your detailed explanations!! The critical point seems to be, that loosing focus of the FS main window generates spikes. AutoFPS says, that it has detected several spikes. So the reduction is not by general load on the GPU, but by spike detection during focus switch.

Log will be sent soon!

Thanks a lot!

3 hours ago, ankh21 said:

Will do as soon as i am at home today.

Thanks for your detailed explanations!! The critical point seems to be, that loosing focus of the FS main window generates spikes. AutoFPS says, that it has detected several spikes. So the reduction is not by general load on the GPU, but by spike detection during focus switch.

Log will be sent soon!

Thanks a lot!

I saw you mention spikes but didn't think to ask you whether this was with the new periodic spike detection or they were just run of the mill spikes, so I am assuming it is the former. If that is the case, then it is a very simple change for me to disable spike detection whenever MSFS does not have the focus, regardless of what graphics mode or FG type you are using. I'll update the app with that change first thing tomorrow when I am at my dev PC. I would still like to see your log as I really want to see what spike signatures you were getting when MSFS does not have the focus as I have not experienced that myself.

Edit: I have a bit of time shortly, so I'll update it with that change in the next hour or so.

Edited July 15Jul 15 by Reset XPDR

3 hours ago, xsever said:

I will test this build today but I have a question first. I always set my FPS limit and dynamic settings in the sim to 30 FPS and use Lossless Scaling adaptive mode to achieve 60 FPS. My system can almost always achieve the 30 FPS so should my DynFG target FPS be set to 30 or 28 or what?
Thanks.

Since you say you mostly achieve your 30 FPS cap, I suggest trying Fixed DynFG 30for your Target FPS.