2 hours ago, MNORM said:

Anyone else getting a permanent TLOD: 0  OLOD: 0  displayed in the box in version 3.6? Previous versions worked but this one doesn't seem to change the values as I fly.

 

This is the first report of such an issue with 0.3.6 I heard of. Can you please send me a screenshot of when this happens as well as the associated log file, located at C:\Users\<username>\AppData\Roaming\DynamicLOD_ResetEdition\log,  so I can look into it. Thanks.

5 hours ago, GSalden said:

If you are stressed for FPS, lower Object LOD first.

Strange, highest OLOD setting has no performance cost at all for me, I keep it at 200 all the time.

OLOD is not so much about FPS but more about smoothness, in particular on lower systems.

Loading in all the clutter of a third party addon airport could result in stutters when you are on short final. A low OLOD setting can prevent that.

If your system is strong enough that you don't see those stutters, OLOD can be kept at 200.

 

Edited February 6, 20242 yr by RALF9636

1 hour ago, Reset XPDR said:

This is the first report of such an issue with 0.3.6 I heard of. Can you please send me a screenshot of when this happens as well as the associated log file, located at C:\Users\<username>\AppData\Roaming\DynamicLOD_ResetEdition\log,  so I can look into it. Thanks.

Sent the Log text.

 

I'm not sure how to attach a jpeg file to a DM...any help is appreciated.

Also confirm with 0.37 test - PC Mode and FG active MSFS 1.36.20

However what I have noted is that fps in both 0.36 and 0.37 when app is focused on screen are showing correct fps with frame generation - but when not focused off screen are indicating half the fps. Don't know if this is an issue?

Just to say extremely impressed with the way this app works and my thanks to Reset XPDR for all the work he has done.

 

1 hour ago, MNORM said:

Sent the Log text.

 

I'm not sure how to attach a jpeg file to a DM...any help is appreciated.

The log file should be sufficient for now, thanks. I'll look into it.

14 minutes ago, MartinP said:

However what I have noted is that fps in both 0.36 and 0.37 when app is focused on screen are showing correct fps with frame generation - but when not focused off screen are indicating half the fps. Don't know if this is an issue?

This is what I am trying to address with the FG auto detection code. I haven't adjusted the app detected FPS yet as I wanted to make sure it detected FG correctly before I did so which, from feedback so far, seems to be working properly. The next test version I put out will attempt to display the corrected (doubled) FPS when in FG mode.

Quick update on today's progress on 0.3.7 development.

FG detection progressed slowly but surely and I am nearly there. Turns out there are three things that need to be checked (FG setting, DX mode, VR mode) to correctly identify when it is in use. As such, I had to create some DX detection code based on what's in your UserOpt.cfg file, which I can confirm works on Steam MSFS version but will need someone to check the my MS Store version checker actually works. When FG is detected as active, the FPS reading, and anything that uses it is, doubled.

The boundary testing of MSFS memory addresses that the utility changes is coming along well. I check the allowable value ranges of TLOD, OLOD, Cloud Quality and, for good measure, Ansiotropic Filtering because it can only be 1, 2, 4, 8 or 16. If any variable fails it's range check, which likely means the MSFS memory map has changed in a new update, the utility gets limited to read only of those memory addresses until updated and verified in a new version. As this code is experimental at this time, the utility does not actually switch to read only in the upcoming 0.3.7 test version but does show a red message to let me know that it happened. Once I am happy with its reliability, I will switch it on. Interestingly, I did accidentally trigger this message when I used a wrong memory address, so it does seem to do what it is supposed to ie. stop the utility going rogue in a changed MSFS memory map.

I also discovered an unintended consequence of changing my app's name in that it is possible to still have the original DynamicLOD version run at the same time as DynamicLOD_ResetEdition if you didn't uninstall DynamicLOD and it was still set to autorun. Having two apps messing with MSFS memory settings is not a good thing! As such, I have extended the check of whether the app is already running to BOTH versions.

That's it for now. I hope to have a test release ready tomorrow for adventurers to try, noting most of these changes are just visual, so existing under the hood 0.3.6 functionality will be retained if you do try it out.

 

Edited February 7, 20242 yr by Reset XPDR

23 minutes ago, Reset XPDR said:

Quick update on today's progress on 0.3.7 development.

@Reset XPDR

Your work, your communication and your product-outcome is just incredible remarkable! I would like to THANK YOU for all this. I enjoy using this tool and for me it is, combinded with the openXR-Toolkit, the ABSOLUTE NUMBER 1 MUST HAVE PRODUCT!

😉

I would like to wish you a great day!

Regards

Marcus

Latest test version is here with:

• FG detection - When FG is detected as active, the FPS reading is doubled and FPS Adaption works off that doubled FPS value, otherwise with FG turned off, using DX11 or in VR your FPS should show and work as normal.
• Compatibility testing - You should always see a green message saying Compatible MSFS version detected when in a flight session. If you see a red message saying Simulated memory boundary test failed, the app will still function (for now).
• App already running check - has been extended to check whether the original DynamicLOD or DynamicLOD_ResetEdition are currently running and exit if either are detected.

If these functions don't work as advertised, especially the compatibility test failing or FG not being detected on the MS Store MSFS version, let me know and message me your log file too.

Edited February 7, 20242 yr by Reset XPDR

stop it i cant keep up Loool !!. keep up the great work 😁

22 minutes ago, sonny147 said:

stop it i cant keep up Loool !!. keep up the great work 😁

The main reason I am pushing ahead at the moment is I am concerned that SU15 is supposedly making changes to MSFS memory management so I want to get the compatibility check functionality working so that no harm is done by the app if they do change the memory map where the settings reside, otherwise I'll cop all sorts of grief from you lot 😄

Other than that, the other changes and those I have planned for the future are mostly spit and polish of the functionality we already have in 0.3.6, so no great rush for them.

 

36 minutes ago, Reset XPDR said:

Latest test version is here with:

• FG detection - When FG is detected as active, the FPS reading is doubled and FPS Adaption works off that doubled FPS value, otherwise with FG turned off, using DX11 or in VR your FPS should show and work as normal.
• Compatibility testing - You should always see a green message saying Compatible MSFS version detected when in a flight session. If you see a red message saying Simulated memory boundary test failed, the app will still function (for now).
• App already running check - has been extended to check whether the original DynamicLOD or DynamicLOD_ResetEdition are currently running and exit if either are detected.

If these functions don't work as advertised, especially the compatibility test failing or FG not being detected on the MS Store MSFS version, let me know and message me your log file too.

Used the 0.3.7 from yesterday and saw the message:

“Newer MSFS version detected - LOD/Cloud changes disabled - update app !”

Will try this new version tomorrow. Thanks 

 

15 minutes ago, GSalden said:

Used the 0.3.7 from yesterday and saw the message:

“Newer MSFS version detected - LOD/Cloud changes disabled - update app !”

Will try this new version tomorrow. Thanks 

Interesting! In any case, I have moved away from detecting the actual MSFS version and will do the compatibility test mentioned above instead, which checks expected memory value boundaries, so you will no longer encounter this specific message when you update to the new test version. Thanks for the feedback.

35 minutes ago, Reset XPDR said:

.... so that no harm is done by the app if they do change the memory map where the settings reside...

 

I have very limited computer knowledge, so this is a genuine question:

What harm could be done? I imagine that in the worst case MSFS freezes or crashes, but after a reboot and the deactivation of this app MSFS runs normally again. Or can any damage be done that persists even after a reboot?