1 minute ago, techman said:

If allowed, I have a feature request: Auto-Update 

 

 

Good idea. I've got no idea of how to do that, but I'll take a look at it with a sense of adventure! 😁

22 hours ago, sonny147 said:

thanks RJC no problem

I just read my reply to your question and if it came across a little harsh then I apologize, it was not meant that way. There are now many pages in this thread regarding this great addon and my intent was to save you time trying to find this info.

hey no problem i didn't read it that way anyway , as i said thanks , i don't get much time to read through everything , so sometimes my questions come across as a little lazy occasionally they are lol, other times i have just not had the time

14 hours ago, Reset XPDR said:

Good idea. I've got no idea of how to do that, but I'll take a look at it with a sense of adventure! 😁

I wouldn't bother. Just for some guy who is too lazy to download a new version. Time is better spent on optimizing the actual code.

3 hours ago, Greazer said:

I wouldn't bother. Just for some guy who is too lazy to download a new version. Time is better spent on optimizing the actual code.

Well it turns out I can't work out how to do it anyway, so problem solved 😁

I jest somewhat. Yes autoupdate seems a bit complex and beyond me but I am hoping to have the app check for updates and notify you if a newer one than you are currently using is available.

Edited February 6, 20242 yr by Reset XPDR

Just a heads up of a new, potentially contentious but in reality good for you, feature I am looking at implementing in the next DynamicLOD_ResetEdition version. As Fragtality states with his DynamicLOD, this app reads and writes to the MSFS memory space while both are running. While reading any memory address is fairly harmless, writing to specific addresses could can have undesirable, and potentially game breaking, side effects should those addresses change between MSFS versions.

As it turns out, the memory address of settings is known to change between MSFS versions, so I am looking at detecting the current MSFS version you are running and to disable the actual setting of MSFS settings if a newer MSFS is detected. If a newer MSFS version does come out, I will work as quickly as I can to verify existing addresses that are used and, if required, change them then put out a new DynamicLOD_ResetEdition version.

Please note that while I have been successful in finding the offsets of some setting memory addresses myself (eg. VR enabled, cloud quality), I do not possess the skills to find the base and starting offset of the setting memory space myself. As such, I will have to rely on others to tell me what those changes are, if any, before I can do my update and hence there may be a delay in my version being released.  This delay is another good reason to disable setting MSFS memory values with a new MSFS version.

To that end, I am currently working on MSFS version detection code, which I can confirm works with the Steam Edition I have, but I need at least one volunteer using the MSFS Store version to try out a 0.3.7 test version I have created that is otherwise the same as 0.3.6 just released but with a new text label showing what the current detected MSFS version is, noting you must be in a flight, even on the ground, to see it. Unless you experience a major issue, you can keep running this version until the next formal release, otherwise you can always reinstall 0.3.6.

If anyone would like to try it please download it here and report back on MSFS version and whether you see what I see below. Thanks.

2 hours ago, Reset XPDR said:

 

If anyone would like to try it please download it here and report back on MSFS version and whether you see what I see below. Thanks.

 

msfs store version readback=1.36.2.0

But wait ... there's more!

I think I may have discovered where the Frame Generation setting resides in MSFS memory and and can reliably read the current setting on my system at least. By reading this setting, the app will be able to correct the FPS reading by doubling what it is receiving from MSFS to correctly align with what FPS you are actually getting and therefore make FPS Adaption work correctly in FG mode.

I have updated the 0.3.7 test version here to show on the PC mode label whether FG is active or not. I have not doubled the FPS reading yet if FG is detected as I want to make sure FG is reliably detected on a variety of systems first. As before, your feedback on whether FG shows on your app when FG is enabled and disappears when not with your system, as well as MSFS version info, would be appreciated.

 

2 hours ago, Reset XPDR said:

If anyone would like to try it please download it here and report back on MSFS version and whether you see what I see below. Thanks.

Hi, I have the store version and v 0.3.7 - test shows: PC Mode active   Microsoft Flight Simulator - 1.36.2.0 in the space of the UI you mention.

Looks like the MSFS version detection is working as desired. Thanks everyone!

4 hours ago, Reset XPDR said:

As it turns out, the memory address of settings is known to change between MSFS versions, so I am looking at detecting the current MSFS version you are running and to disable the actual setting of MSFS settings if a newer MSFS is detected. If a newer MSFS version does come out, I will work as quickly as I can to verify existing addresses that are used and, if required, change them then put out a new DynamicLOD_ResetEdition version.

I am not sure this would be good idea.

AFAIK the memory adresses do not necessarily change between MSFS versions. They might, but they might as well just stay the same. At least I had been using the previous tool by muumimorko through many MSFS updates before there was one that eventually broke it. And the current tool obviously still works after the latest small sim update that came with the Caribbean World Update.

So disabling the tool just because the sim version has changed would in many cases unnecessarily break the tool on every small sim update.

Instead of just looking at the MSFS version number wouldn't it be better to look at the used memory adresses and check if they still are valid and only then disable the tool, if they are not?

 

19 minutes ago, RALF9636 said:

I am not sure this would be good idea.

AFAIK the memory adresses do not necessarily change between MSFS versions. They might, but they might as well just stay the same. At least I had been using the previous tool by muumimorko through many MSFS updates before there was one that eventually broke it. And the current tool obviously still works after the latest small sim update that came with the Caribbean World Update.

So disabling the tool just because the sim version has changed would in many cases unnecessarily break the tool on every small sim update.

Instead of just looking at the MSFS version number wouldn't it be better to look at the used memory adresses and check if they still are valid and only then disable the tool, if they are not?

 

Good points! I was under the impression that each sim update broke the previous tool but if that is not the case and it has only happened once in a very long time then maybe I am worrying too much about this.

19 minutes ago, RALF9636 said:

Instead of just looking at the MSFS version number wouldn't it be better to look at the used memory adresses and check if they still are valid and only then disable the tool, if they are not?

How do you suggest I check used memory addresses to see if they are still valid? If they have moved location with a sim update and the original addresses still fall within MSFS's running memory space, what would the app look for with the original memory addresses to show they are invalid? At the moment I make sure that the value at a memory address currently known to be associated with an MSFS setting changes to the correct value when, and only when, I change that MSFS setting ie. it is a manual visual verification action. While I could do a boundary check of the current value ie. TLOD is never negative, has a minimum value of 10 and a maximum value of 400, what if the value just happens to fall within that band but is not the setting we are actually after?

Actually, thinking this through further (thanks for challenging my thought process BTW - this is helpful!) I could just do boundary checks on all of the current memory addresses accessed and if any one of them fails disable the tool. ie. it is highly unlikely that all memory locations could pass their boundary tests if the memory map had changed markedly with a sim update, so this might just work. I'll see what I can come up with. Thanks!

just installed 0.3.7 , works fine "pc mode & FG  + MSFS - 1.36.2.0

Thank you very much for your effort!

Same for me with 0.3.7  PC Mode and FG active MSFS 1.36.20

 

I have a question.  I watched  a YT video and this guy said to change the OLOD values and put them in the opposite direction (higher on the ground and lower as we climb).  While it makes some sense, i am sure there is a catch, since noone else has mentioned it.  What is your opinion about this?

it made sense to me too ,i  went ahead and put the OLOD the opposite way around , just testing now