Reset XPDR

OK, in that case don't set MSFS Max Frame Rate and just use Manual Target FPS and set it to say 40 FPS so that it takes action before getting to your Dynamic Settings 35 FPS threshold. Just be aware that with 0.5.0.0-RC that if you are capping frame rate to 45 somewhere, even it is only in your VR headset, and your FPS sits locked at that FPS because performance conditions are so good, then to the app it is indistguishable from a Fixed FPS and it may warn you via changing the background of affected settings to orange to 30 seconds and providing corrective advice in the tooltip. You can just ignore it of course, as it is not a common occurrence, and you probably won't see it in VR anyway, unless you have AutoFPS visible by something like OpenKneeboard. In short, yes what you are suggesting should work 😊

I am not understanding what you are trying to achieve. Can you please clarify.

When set to use RTSS as the source, AutoFPS shows the FPS that RTSS is telling it, without alteration for everything except LSFG. If you can decipher it, the display code is simply this: if (serviceModel.fpsSourceRTSS) { if (serviceModel.LsModeEnabled) return serviceModel.fpsAverage * serviceModel.LsModeMultiplier; else return (float)Math.Round(serviceModel.fpsAverage); } This strongly suggests that your RTSS framerate limit is not currently active. You can verify by using another FPS reporting source, such as the FPS overlay with the OpenXRToolkit, the MSFS in-game FPS view or even the the nVidia overlay. With the latter two methods, you will obviously need to lift your headset off to see them. My recommendation, for VR in particular and is what I do, is to set Max Frame Rate in MSFS to 40 and remove all doubt about whether the frame rate limit is active or not and also for the optimal experience with having Dynamic Settings set to the same value, which in my testing results in expected behaviour when used in conjunction with AutoFPS.

Further to this, here is the one-time message box users will be presented from now on the first time they enable, or reenable after disabling, MSFS Performance Optimisation:

I just checked and the link on the first page does still work, taking you to an redirect webpage which does contain the link to the latest app version here.

Wow! I don't really see how these settings could be related, but here we are! 😄 FWIW, the tooltip for this feature in the next release will have a warning that performance may or may not improve and to monitor accordingly, as a few users have experienced performance/stuttering issues with it enabled. I may need to change that to include watching out for strange MSFS behaviour and to promote it to a one-off message box warning on enabling for the first time instead!

@airbusa333, I just had another thought about your issue, and it's a long shot, but I notice from your screenshots you are using the app's MSFS Performance Optimiser option. It is remotely possible that the change to either CPU core affinity, MSFS process priority or Windows power plan could be upsetting something with the Fenix A320. As such, suggest you try disabling it and seeing if you still have the issue. Let me know how it goes.

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

As I can't reproduce it and it only seems to affect the Fenix A320, all I can suggest is that you let them know the issue is still present when used with this particular addon. They will probably say that they don't provide support for issues with other 3rd party apps, particularly ones like DynamicLOD_ResetEdition that unofficially interact directly with MSFS memory, but at least you can give them a data point of the few settings the app does directly write, which as previously mentioned are TLOD, OLOD, Cloud Quality and Dynamic Settings enable/disable and have nothing to do with cabin alt, which could help find what it is. If they do come back with anything that still points to DynamicLOD_ResetEdition's behaviour, be sure to pass the details on to me and I will look into it.

Thanks for the screenshots. I can clearly see what you mean now. Sorry, but I misunderstood your original post and thought you meant aircraft, not cabin altitude, vertical speed, which is even stranger as that is not something the app either reads or writes at all. Unfortunately, I do not own the Fenix A320 so cannot test this exact configuration to try and replicate. Does it do this with any other aircraft, default preferably, or just the Fenix A320? Edit: I just looked through the code and the only things this app can set directly in MSFS are OLOD, TLOD, Cloud Quality and Dynamic Settings enable/disable. Everything else is read only. Cabin alt and associated vertical speed are not even looked at. Are you absolutely sure it is not just a bleed air or cabin alt settings issue and just happens to be coincidental with using the app? I also tried to trigger the issue with the default A320, with no success: At this stage I am stumped as to what it could be, but I will keep investigating. Edit2: I've found a couple of discussion topics that, even though not recent, indicate this is a known issue with the Fenix A320 and there is no mention of DynamicLOD_ResetEdition in any of them.

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.

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.

I am not sure how that is possible, given the app only ever reads V/S, not write it. Is the warning valid because you are actually climbing or are you straight and level when this is happening? Or are you saying the aircraft is climbing faster than it normally does because of the app? Can you post a screenshot of DynamicLOD_ResetEdition when it does this?

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.

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.

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

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!

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.

I see in your video what you are saying. I note that you still have MSFS performance optimiser enabled, so as mentioned previously it could be the cause. Try running AutoFPS without that enabled. FYI, I just tried the same thing on my gaming laptop, and with AutoFPS running I get a render time of around 13ms at TLOD 25, 14ms at TLOD 50 and 15 ms at TLOD 100. Without AutoFPS, I get around 14ms at default TLOD 50. ie. The results are the same at the same TLOD and scale slightly up and down correspondingly, indicating there is no impact of running AutoFPS. I will try the same test on my dev PC when I am at it tomorrow morning.

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. Re DTLOD, that is because I have MSFS dynamic settings enabled and set to my native target frame rate of 40 FPS, the same as I have set for MSFS max frame ratet . Even prior to 0.4.6.8, the app works very well when all three of these are set the same.

My first instinct was that your AutoFPS set TLOD is greater than your MSFS default, but it is doing it at TLOD 25 which I seriously doubt is higher than your MSFS default, especially with your high system specs! I will try and recreate tomorrow when I am back at my dev PC, but in the interim try unchecking the MSFS performance optimiser option and see if that recovers it. Edit: That seems pretty low performance for such hefty hardware, even if AutoFPS is contributing (although excluding the perf option, at a TLOD 25 floor AutoFPS would not be interacting with MSFS much at all, possibly not at all). What FPS do you get without AutoFPS and at what default TLOD?

I have now found and fixed the issue you were experiencing in Test18. eg. with your settings and MFG complements of the DLSS Enabler mod: I had made a late breaking change to Test17 to fix FreeTLOD just before I released it and even though I had tested the other modes, I had only done so on the ground, so the issue that you found was not caught by my test net. Lesson learnt, so I have tested Test18 in all TLOD Extra modes at all altitude thresholds and with each Target FPS type and it seems to be behaving itself well now. I should also note to you, and any other (M)FG users out there, that there is also a change in FPS Sensitivity and Tolerance modes where when MSFS is no longer the active window and (M)FG becomes inactive, the app will no longer allow TLOD and Cloud Quality increases and you will see the FPS and TLOD values be shown in orange. This is consistent with FPS Cap mode and is done so because the performance conditions when FG is inactive are too favourable compared to how they will be when FG comes back on, so it is prudent to not allow the app to react to such unrealistic favourable performance. As such, please don't be surprised when TLOD in particular stops increasing if you move away from MSFS and be assured it will resume when MSFS gets the focus again. Re what FPS setting to use in FPS Sensitivity mode if you were using FPS Cap mode with an FPS cap set before like you have been, the auto settings the app has chosen for you will be correct, which is to use Fixed Target FPS and to set it to the 120 FPS you previous had it set to in FPS Cap mode. Previous app versions would not have worked set this way, and you would have needed to set a Target FPS lower than the FPS cap, but the new Fixed mode is specifically designed to have them match and does does away with the TLOD/Altitude schedule and Max Extra overheads that FPS Cap required because of the way it was built on AutoTLOD mode. In short, stay with Fixed and 120 FPS as your target. Once I get the kinks ironed out, as I hope we are close to doing in this test phase, and release 0.4.6.8, this paves the way to retire FPS Cap mode and to make FPS Tolerance mode legacy only (ie. you can only use it if you already had it enabled, otherwise it will not be available to set), thus simplifying the app to two distinct modes - FPS Sensitivity (the core AutoFPS experience) and AutoTLOD (the DynamicLOD-like experience). You can get Test18 in the usual place here. Please continue to report any issues.

Never mind sending the log file, as I am able to reproduce with your stated post-migration settings on my dev system, so I will work on a fix. Thanks for letting me know about the issue!

Re new modes being potentially confusing for now, yes this will be the case when converting over but once FPS Cap mode is eventually removed these changes will provide more consistent terminology between the modes. eg. with TLOD Top, all modes with have TLOD Top Max, as FPS Cap with its TLOD Top Min and locked multiplier will be gone. The auto conversion should have set TLOD Top Max to TLOD Top Min X the Top multiplier for equivalency. I have to go out for a few hours, so will not be able to look into this or answer your other questions until I am back. In preparation, can you PM me the contents of your log file, located %appdata%\MSFS_AutoFPS\log, associated with this happening and I will take a look, particularly as to why your TLOD refused to scale up on the flight you mention. Thanks.

Just click on the FS icon to the immediate right of the FPS value and it should change to RTSS. It will stay that way for future startups, unless you don't have RTSS running beforehand, in which case it auto switches to MSFS as the source and stays that way until you click it again. If you have RTSS auto load when windows starts, this setting will always stick.