1 hour ago, MarcG said:

Having tried the AutoApp again yesterday I can confirm that for my personal needs this app is best for me, with Auto I see the terrain altering LOD too much and it becomes an eyesore, but when I'm in control with this app I know exactly when it's going to happen and then it won't change again for X amount of time until the next change.

I agree. That's one of several reasons why the new AutoFPS app is just not for me. I also still prefer the DynamicLOD app.

 

Edited February 25, 20242 yr by RALF9636

Since no one seems to be objecting to my simple profile name proposal, here is release candidate for DynamicLOD_ResetEdition 0.3.8.. Not many changes, just a few optimisations from the AutoFPS development effort and a few bug fixes:

• Added simple profile name capability whereby after the first run of this new version you can go into your config file and edit the profile name lines to reflect what you want to see in the app. In future I aim to have the user do this in the app itself, but for now this simple method is all I could work out how to do and it works, albeit manually.
• Expanded memory boundary test with water waves setting to make test even more robust.
• Changed upper limit on allowable LODs from 300 to 1000 in case a user has manually set in usercfg.opt a higher TLOD than is otherwise possible to set in the MSFS settings menu.
• Expanded app already running test to check whether the new MSFS2020_AutoFPS app is running.
• Added more extensive logging of memory integrity test failures.
• Incorporated AutoFPS improvements applicable to DynamicLOD
  • Auto pause to make FPS Adaption more usable with FG
  • Different FPS targets for VR, FG and PC modes
  • Single call of memory access variables per tick to minimise MSFS memory interaction
  • Add detected DX version and FG active/inactive to status line and other status line refinements
  • App version recorded at start of log file
  • Auto settle time on display mode and MSFS lost focus change
• Changed installer's MSFS auto run's MSFS version check to look for Steam version first as it was causing an issue for some users who tried out MSFS on GamePass then subsequently bought it on Steam and this app's installer was changing the remnant MS Store exe.xml file in lieu of the current Steam one.

If I could get a couple of users to trial it and let me know if there are any issues with the changes I made or with existing functionality. Pending nothing major being raised, I will formally release it. Thanks.

1 hour ago, Reset XPDR said:

Since no one seems to be objecting to my simple profile name proposal, here is release candidate for DynamicLOD_ResetEdition 0.3.8.. Not many changes, just a few optimisations from the AutoFPS development effort and a few bug fixes:

• Added simple profile name capability whereby after the first run of this new version you can go into your config file and edit the profile name lines to reflect what you want to see in the app. In future I aim to have the user do this in the app itself, but for now this simple method is all I could work out how to do and it works, albeit manually.
• Expanded memory boundary test with water waves setting to make test even more robust.
• Changed upper limit on allowable LODs from 300 to 1000 in case a user has manually set in usercfg.opt a higher TLOD than is otherwise possible to set in the MSFS settings menu.
• Expanded app already running test to check whether the new MSFS2020_AutoFPS app is running.
• Added more extensive logging of memory integrity test failures.
• Incorporated AutoFPS improvements applicable to DynamicLOD
  • Auto pause to make FPS Adaption more usable with FG
  • Different FPS targets for VR, FG and PC modes
  • Single call of memory access variables per tick to minimise MSFS memory interaction
  • Add detected DX version and FG active/inactive to status line and other status line refinements
  • App version recorded at start of log file
  • Auto settle time on display mode and MSFS lost focus change
• Changed installer's MSFS auto run's MSFS version check to look for Steam version first as it was causing an issue for some users who tried out MSFS on GamePass then subsequently bought it on Steam and this app's installer was changing the remnant MS Store exe.xml file in lieu of the current Steam one.

If I could get a couple of users to trial it and let me know if there are any issues with the changes I made or with existing functionality. Pending nothing major being raised, I will formally release it. Thanks.

Will test it with some weather tomorrow

5 hours ago, Reset XPDR said:

Since no one seems to be objecting to my simple profile name proposal, here is release candidate for DynamicLOD_ResetEdition 0.3.8.. Not many changes, just a few optimisations from the AutoFPS development effort and a few bug fixes:

 

didn't rename profile but otherwise it's working fine on msfs store version.

btw, had couple of weird runaway tlod sessions on the auto tlod version v0.4 where tlod kept going up even as fps crashed.  happened on 2nd flight in the sessions, didn't happen immediately after flying.  it's a vr setup with fps locked at 30, target set to 28 to give it a chance to increase tlod.  

regardless, on my setup don't think it's powerful enough to chase fps with tlod.  the reset edition seems the best for it.

Edited February 26, 20242 yr by kdfw__

1 hour ago, kdfw__ said:

didn't rename profile but otherwise it's working fine on msfs store version.

btw, had couple of weird runaway tlod sessions on the auto tlod version v0.4 where tlod kept going up even as fps crashed.  happened on 2nd flight in the sessions, didn't happen immediately after flying.  it's a vr setup with fps locked at 30, target set to 28 to give it a chance to increase tlod.  

regardless, on my setup don't think it's powerful enough to chase fps with tlod.  the reset edition seems the best for it.

Thanks for the feedback on the test version of DynamicLOD_ResetEdition working fine.

Re AutoLOD runaway TLOD, I haven't seen or heard of that before. Looking at the code, at that altitude and descent rate it should have already been at TLOD min of 85. The conditions were such that it should have been dropping TLOD by a forced 20 per second to get as rapidly to TLOD min as it could, unless you had been climbing moments before that screenshot.

Also, your target FPS set to 28 with a 30 FPS lock is probably not enough headroom for the app to work and that may have contributed to the issue. The maximum Target FPS you should have set is 27 (10% less than your 30 cap) in that configuration.

In any case I have changed the logic in this are for the upcoming 0.4.1 are such that if you are descending below 1000 ft, after having climbed to at least 2000 ft, then TLOD min mode will be locked to only ever decrease or stay the same but never to increase unless you go over 1000 ft again. See how you go with that version when it is released and let me know if it happens again.

 

Edited February 26, 20242 yr by Reset XPDR

@Reset XPDR great job on the latest version ! I think you even managed to reduce to almost 0 the ground texture tearing on DX12.

I think the reduced calls to memory did it.

I have a question as to the "reduce cloud quality" feature. I apologize if this has already been discussed, but I have tried to find information about this in the 79 page thread without luck.

How does the reduce cloud quality feature work? By how much is quality degraded and how quickly?

As I understand it, TLOD will be reduced first down to minimum, and then cloud quality will start reducing. But how much and how quickly?

Can this feature be triggered stand-alone without having the FPS TLOD reduction ticked?

I find on my system that the cloud quality is a heavy FPS hitter, and just being able to reduce cloud quality instantly as FPS drops (e.g from ultra to high) would be a welcome feature (and it may already be implemented, sorry for my ignorance).

 

 

 

2 hours ago, LGKR said:

I have a question as to the "reduce cloud quality" feature. I apologize if this has already been discussed, but I have tried to find information about this in the 79 page thread without luck.

How does the reduce cloud quality feature work? By how much is quality degraded and how quickly?

As I understand it, TLOD will be reduced first down to minimum, and then cloud quality will start reducing. But how much and how quickly?

Can this feature be triggered stand-alone without having the FPS TLOD reduction ticked?

I find on my system that the cloud quality is a heavy FPS hitter, and just being able to reduce cloud quality instantly as FPS drops (e.g from ultra to high) would be a welcome feature (and it may already be implemented, sorry for my ignorance).

 

 

 

There is a solid post a ways back that covers this. Reduces them by 1. If you have the app open you can see the cloud setting in real time.

FYI, DynamicLOD_ResetEdition 0.3.8 has just been formally released and is available for download here. Those on 0.3.7 should get an in app notification advising of the update and a download link to get it. Changes are:

• Added simple profile name capability whereby after the first run of this new version you can go into your config file and edit the profile name lines to reflect what you want to see in the app. In future I aim to have the user do this in the app itself, but for now this simple method is all I could work out how to do and it works, albeit manually.
• Expanded memory boundary test with water waves setting to make test even more robust.
• Changed upper limit on allowable LODs from 300 to 1000 in case a user has manually set in usercfg.opt a higher TLOD than is otherwise possible to set in the MSFS settings menu.
• Expanded app already running test to check whether the new MSFS2020_AutoFPS app is running.
• Added more extensive logging of memory integrity test failures.
• Incorporated AutoFPS improvements applicable to DynamicLOD
  • Auto pause to make FPS Adaption more usable with FG
  • Different FPS targets for VR, FG and PC modes
  • Single call of memory access variables per tick to minimise MSFS memory interaction
  • Add detected DX version and FG active/inactive to status line and other status line refinements
  • App version recorded at start of log file
  • Auto settle time on display mode and MSFS lost focus change
• Changed installer's MSFS auto run's MSFS version check to look for Steam version first as it was causing an issue for some users who tried out MSFS on GamePass then subsequently bought it on Steam and this app's installer was changing the remnant MS Store exe.xml file in lieu of the current Steam one.

Edited February 26, 20242 yr by Reset XPDR

1 hour ago, Reset XPDR said:

FYI, DynamicLOD_ResetEdition 0.3.8 has just been formally released and is available for download here. Those on 0.3.7 should get an in app notification advising of the update and a download link to get it. Changes are:

• Added simple profile name capability whereby after the first run of this new version you can go into your config file and edit the profile name lines to reflect what you want to see in the app. In future I aim to have the user do this in the app itself, but for now this simple method is all I could work out how to do and it works, albeit manually.
• Expanded memory boundary test with water waves setting to make test even more robust.
• Changed upper limit on allowable LODs from 300 to 1000 in case a user has manually set in usercfg.opt a higher TLOD than is otherwise possible to set in the MSFS settings menu.
• Expanded app already running test to check whether the new MSFS2020_AutoFPS app is running.
• Added more extensive logging of memory integrity test failures.
• Incorporated AutoFPS improvements applicable to DynamicLOD
  • Auto pause to make FPS Adaption more usable with FG
  • Different FPS targets for VR, FG and PC modes
  • Single call of memory access variables per tick to minimise MSFS memory interaction
  • Add detected DX version and FG active/inactive to status line and other status line refinements
  • App version recorded at start of log file
  • Auto settle time on display mode and MSFS lost focus change
• Changed installer's MSFS auto run's MSFS version check to look for Steam version first as it was causing an issue for some users who tried out MSFS on GamePass then subsequently bought it on Steam and this app's installer was changing the remnant MS Store exe.xml file in lieu of the current Steam one.

Thank you for both of these mods!

Is the AutoFPS one intended to be more "automatic" and interpolate the changes based on headroom available on FPS? And this one is more configurable if you want things at specific altitudes?

I'm trying to understand why one would pick one versus the other. Which one (assuming it's not both) do you think you will continue to maintain in the long run?

11 minutes ago, mmcmah said:

Thank you for both of these mods!

Is the AutoFPS one intended to be more "automatic" and interpolate the changes based on headroom available on FPS? And this one is more configurable if you want things at specific altitudes?

I'm trying to understand why one would pick one versus the other. Which one (assuming it's not both) do you think you will continue to maintain in the long run?

Yes. See the readme(s) for more detail and earlier posts in this thread outlining detailed differences.

Hi,

Is this affected by using ASW (motion smoothing for Meta headsets) when in VR?

 

Thanks

10 hours ago, Flugpig said:

Hi,

Is this affected by using ASW (motion smoothing for Meta headsets) when in VR?

 

Thanks

You should be fine with ASW and any DynamicLOD variant as they are not FPS driven. The new AutoFPS app is FPS driven and would likely conflict with what your ASW is trying to achieve.

On 2/27/2024 at 12:37 AM, mmcmah said:

Thank you for both of these mods!

Is the AutoFPS one intended to be more "automatic" and interpolate the changes based on headroom available on FPS? And this one is more configurable if you want things at specific altitudes?

I'm trying to understand why one would pick one versus the other. Which one (assuming it's not both) do you think you will continue to maintain in the long run?

I’m also wondering about this, having used AutoFPS exclusively for the last few days. I think Reset mentioned that DynLOD is more intended for smoothness whereas AutoFPS is more for FPS. IIRC.

2 minutes ago, Cpt_Piett said:

I’m also wondering about this, having used AutoFPS exclusively for the last few days. I think Reset mentioned that DynLOD is more intended for smoothness whereas AutoFPS is more for FPS. IIRC.

I saw the same response, but I'm not sure how to interpret the difference between smoothness and FPS.