10 hours ago, GSalden said:

The Lower Lower framerate is caused by 40+ parked and moving AC in Realtime using PSXT.

One screen 70+ 

Two screens 38 / 35 AutoFPS

Three screens 29 / 27 AutoFPS

Default test tLOD = 150

So with 150 I am heffing higher FPS and lower Render Thread load than with AutoFPS with tLOD at 25.

 

I just tried it on my dev/main PC and the results are the same as on my gaming laptop, namely negligible impact of running AutoFPS and render thread changing proportional to TLOD, even after changing to FSR3 and SU5 beta and in the last screenshot having the MSFS Performance Optimiser enabled:

 

As such, I am not sure what this issue is with your setup. Perhaps it is a conflict with another addon you are running, maybe something to do with running MSFS over multiple screens? Maybe try disabling them and see if that clears it and if it does let me know which app is causing the conflict and I will see what I can come up with.

11 hours ago, Reset XPDR said:

When I get a few more ripples sorted out, the app will soon auto correct for you if you have a Fixed FPS cap like you do and have set the target FPS lower, because leaving it set like that will skew the automation to be too generous with TLOD increases, potentially resulting in your Fixed FPS being compromised, which is contradictory to the term Fixed. As suggested, with Test18 if you set Fixed Target FG FPS to 120 it will automate correctly.

I have thought about this some more and I have decided not to force auto correct the target FPS if it is detected to be different than the detected fixed FPS. The reason is that sometimes what appears to be a fixed FPS, which the app defines as a long series of FPS readings very tightly clustered around one value, could in fact be a not-to-exceed (NTE) FPS cap, such as a vsync limit or FPS ceiling a user has set, that just happens to look like a fixed FPS because performance conditions are so favourable it is pegged at it. eg. if a user normally flies airliners at complex airports and gets performance well below their NTE FPS cap, then there is no issue as a Fixed FPS will not be detected, but if they decide to fly VFR in the middle of nowhere their performance could have them pegged at the cap, which would look like a Fixed FPS for the condition right now, but isn't actually one. 

As such, it would be presumptious of the app to force a target FPS setting change that may not be applicable in all instances. Instead, what I propose is to still detect Fixed FPS situations and if there is such a mismatch with the target FPS to simply warn the user, not by message box, which would get annoying if it happened too often, but by subtly changing the target FPS option background to orange and clarifying in the tooltip what this actually means. This is consistent with how the app handles users changing their target FPS graphics mode to one that is currently not active by making that UI control background organge, to essentially warn them that what they are changing is not applicable to the current graphics mode.

ie. instead of being blunted by this:

you will see this:

I'm pretty sure I won't get any objection to this change, but I am posting this here in any case as a sanity check in case my reasoning is not correct.

Edit: The just released Test19 implements this change. Apart from @GSalden's issue currently being investigated, which I don't think is anything specifically related to 0.4.6.8 if we do uncover something, there have been no major issues identified with Test18 so I am hoping that 0.4.6.8 is getting close to release candidate status. Thanks everyone for your feedback!

Edited April 24Apr 24 by Reset XPDR

6 hours ago, Reset XPDR said:

I just tried it on my dev/main PC and the results are the same as on my gaming laptop, namely negligible impact of running AutoFPS and render thread changing proportional to TLOD, even after changing to FSR3 and SU5 beta and in the last screenshot having the MSFS Performance Optimiser enabled:

 

As such, I am not sure what this issue is with your setup. Perhaps it is a conflict with another addon you are running, maybe something to do with running MSFS over multiple screens? Maybe try disabling them and see if that clears it and if it does let me know which app is causing the conflict and I will see what I can come up with.

@GSalden, I am too late to edit this post, but again I stress you try disabling AutoFPS's MSFS Performance Optimiser option as the first thing you do, as a few users have had issues with it (mostly stuttering) and it could very well be the cause.

Edited April 24Apr 24 by Reset XPDR

2 hours ago, Reset XPDR said:

@GSalden, I am too late to edit this post, but again I stress you try disabling AutoFPS's MSFS Performance Optimiser option as the first thing you do, as a few users have had issues with it (mostly stuttering) and it could very well be the cause.

With beta 19 and the MSFS Performance Optimizet disabled it is a little better. 

tLOD = 150

AutoFPS : tLOD = 25 ( min )

AutoFPS not running : RT is 39-30 ms

AutoFPS running : RT is 27-33 ms

Here a vid. See the RT and the red spikes when AutoFPS is running :

 

Edited April 24Apr 24 by GSalden

I have a question.

I'm using an FG (2)x (4080S) and have locked my sim to 30.

This gives me 60 FPS in MSFS 2024.

Should I set AUTOFPS to 30 or 60 under General?

I've been using this tool for a long time, but I'm not sure anymore.

Thank you so much for developing this tool. I wouldn't fly without it.

1 hour ago, f.skywalker said:

I have a question.

I'm using an FG (2)x (4080S) and have locked my sim to 30.

This gives me 60 FPS in MSFS 2024.

Should I set AUTOFPS to 30 or 60 under General?

I've been using this tool for a long time, but I'm not sure anymore.

Thank you so much for developing this tool. I wouldn't fly without it.

Set it to your post-frame generated frame rate ie. 60 FPS in your case. And if you are using 0.46.7 or earlier, you should be using FPS Cap automation mode whereas in 0.4.6.8-test (very close to release) use Fixed Target FPS in FPS Sensitivity mode, as these modes both work properly when your target FPS is set to the same as your system-set fixed FPS.

Thanks,

i am on the lastet test version.

48 minutes ago, f.skywalker said:

Thanks,

i am on the lastet test version.

I will update the target frame rate text box tooltip in the next test update to clarify the number being set is after any frame generation has been factored in.

Edited April 24Apr 24 by Reset XPDR

On 4/19/2026 at 11:07 PM, Reset XPDR said:

Why are you trying to set and select NFR when you are using FG? Just set the FG, which the app is auto-detecting you are using, FPS to 120 (3X your FPS lock). 

Re trying the free setting, yes it may not be effective in situations such as yours, and that is why it is optional, but in remote/VFR areas it may still be worthwhile to try.

Thanks, I suppose I was trying to get the base FPS very stable but have reverted to FG at 120 fps and works well (minimum fixed to 100 and max 400). 

I was reading in earlier posts that you have been trying to change the aggressive TLOD behaviour of fixed mode, but with the latest RC1 I am still getting TLOD being returned to 100 after I get an FPS drop when I switch views from the flight deck to a wing view for instance where FPS would generally recover quickly back to my 120 fps target. Are there any other settings I can play with to make this less aggressive? 

Have also noticed for me that using the optimising settings at the top (i.e. physical cores/power plan etc) increases my RDRthread significantly so turned if off - believe this has been reported before but thought I'd give it as feedback anyway if helpful. 

@Reset XPDR

Just updated to RC1 and with 1 monitor the Render Thread graph looks the same, with and without AutoFPS.

With 2 monitors sometimes there is a small red spike when using AutoFPS.

With 3 monitors there are red spikes every few seconds. Without AutoFPS the Render Thread shows no red spikes.

 

 

On 4/24/2026 at 7:58 AM, f.skywalker said:

Thank you so much for developing this tool. I wouldn't fly without it.

Same here🫡

1 hour ago, AlexMD11 said:

Thanks, I suppose I was trying to get the base FPS very stable but have reverted to FG at 120 fps and works well (minimum fixed to 100 and max 400). 

Glad to hear.

1 hour ago, AlexMD11 said:

I was reading in earlier posts that you have been trying to change the aggressive TLOD behaviour of fixed mode, but with the latest RC1 I am still getting TLOD being returned to 100 after I get an FPS drop when I switch views from the flight deck to a wing view for instance where FPS would generally recover quickly back to my 120 fps target. Are there any other settings I can play with to make this less aggressive? 

Yes it is now less aggressive, requiring at least two successive FPS drops before triggering and then dropping proportional to the average of those drops, so if TLOD is still dropping rapidly and significantly on view changes then it indicates your system is struggling to hold the fixed FPS you have set and it is just responding trying to recover that. The only way I can really tell what is really going on is to see a log file from you from a representative flight where you have Log+ enabled, which will give me performance data every second to analyse. If can provide one by PM I will take a look. The log files are located in %appdata%\MSFS_AutoFPS\log.

FYI, I did a couple of flights myself today with free TLOD over LA, so heavy PG, with TLOD Max at 400 in high res VR at fixed 40 FPS, which is pretty taxing for my system. For the most part TLOD ranged up and down quite gently., and generally not at all on single view switches. The only time it dropped notably was when new scenery was visibly loading, but even then the drops were no more than 50 and quickly recovered to what they were within 30 seconds, and the overall experience was relatively smooth flight considering the very high load I intentionally placed on my system. I have also received logs from two other users that correspond with my experience, so I am surprised you are not getting good results too. As I have suggested, a log file from you with Log+ data will reveal all to me.

1 hour ago, AlexMD11 said:

Have also noticed for me that using the optimising settings at the top (i.e. physical cores/power plan etc) increases my RDRthread significantly so turned if off - believe this has been reported before but thought I'd give it as feedback anyway if helpfu

Thanks for that data point. I will update the tooltip to warn that performance degradation is also a possibility.

48 minutes ago, GSalden said:

@Reset XPDR

Just updated to RC1 and with 1 monitor the Render Thread graph looks the same, with and without AutoFPS.

With 2 monitors sometimes there is a small red spike when using AutoFPS.

With 3 monitors there are red spikes every few seconds. Without AutoFPS the Render Thread shows no red spikes.

 

 

Interesting. I don't believe that I changed anything in particular that would affect this between Test18 and RC1, but this is software so anything is possible, even if seemingly unrelated. What you are now experiencing is what I would expect, namely that when AutoFPS changes TLOD there may be a corresponding temporary load increase on the render thread, which would explain those red spikes and their increasing intensity as you increase load when adding more monitors.

What did not make sense is the constant increase you were getting in render thread at times AutoFPS didn't appear to be changing any settings, specifically when your TLOD was floored at 50. In any case, I am glad this constant render thread increase behaviour does not seem to be occurring any more.

18 hours ago, Reset XPDR said:

Glad to hear.

Yes it is now less aggressive, requiring at least two successive FPS drops before triggering and then dropping proportional to the average of those drops, so if TLOD is still dropping rapidly and significantly on view changes then it indicates your system is struggling to hold the fixed FPS you have set and it is just responding trying to recover that. The only way I can really tell what is really going on is to see a log file from you from a representative flight where you have Log+ enabled, which will give me performance data every second to analyse. If can provide one by PM I will take a look. The log files are located in %appdata%\MSFS_AutoFPS\log.

FYI, I did a couple of flights myself today with free TLOD over LA, so heavy PG, with TLOD Max at 400 in high res VR at fixed 40 FPS, which is pretty taxing for my system. For the most part TLOD ranged up and down quite gently., and generally not at all on single view switches. The only time it dropped notably was when new scenery was visibly loading, but even then the drops were no more than 50 and quickly recovered to what they were within 30 seconds, and the overall experience was relatively smooth flight considering the very high load I intentionally placed on my system. I have also received logs from two other users that correspond with my experience, so I am surprised you are not getting good results too. As I have suggested, a log file from you with Log+ data will reveal all to me.

Thanks for that data point. I will update the tooltip to warn that performance degradation is also a possibility.

@AlexMD11, further to this discussion, today I came across a log where the user was in Fixed Target FPS mode and was experiencing a lot of TLOD large reductions, like you say you have been experiencing. On further analysis of their data, which is graphed below, you can see that while their FPS sits around and never exceeds 72 FPS (36 x 2 with motion reprojection in VR), this is not what I would classify as a "Fixed" FPS, as there is way too much variance, rather it is acting like a not to exceed FPS cap.

 

In this case, Fixed Target FPS is not the appropriate option to be using in the app and they should instead be using Manual Target FPS with a lower target FPS like 34 (x2 = 68) to achieve more stable TLOD. When changed like this, it is still possible the app may still detect that a Fixed FPS is in use if the flight start conditions have the FPS pegged at the 72 (36 x 2) FPS cap for five 20 second detection events that must all result in the same FPS super stable reading ie. 72 72 72 72 and 72. In that case, the settings mismatch warning will trigger, but I have now watered the warning down to a 30 second change of background of either Target FPS option or value as applicable to orange, with the tooltips being dynamically updated to show the recommended rectification action, then everything goes back to normal, so it should not be too much of nuisance if it does happen.

If a user is actually running at a true Fixed FPS, like in the chart below, then in that case the settings mismatch detection will be doing its job if it is going off every flight, alerting the user to take action to resolve and acheive an optimal app experience. In this particular case, the user did have the right settings configured (Fixed Target FPS and Target FPS matching the Fixed FPS), so no alerts are given. You can also see in this chart that the app ignores one-off FPS dips, like on a view change, and only takes action when two or more occur.

 

It is a fine balancing act to get this right and so far the test results I have seen show it being achieved.

Hi All,

 

I have recently had to reformat my PC so need to install this again and went back to the start of this thread and the original download link is not working please could someone kindly post the link to download this again please.

 

Thanks

 

Daz