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.