33 minutes ago, Fiorentoni said:

I tried KJFK from iniBuilds with 100% AIG traffic (~ 250 aircraft over/at New York), I had 25 FPS with OLOD 10 and 18 FPS with OLOD 200. This might of course vary with hardware and other factors, so I'm not sure you can replicate it with your top notch system (I have a 3600X and a 1080ti for that matter...). And obviously it's not the case with less AI traffic (e.g. FSLTL injects MUCH less traffic by defalt), it's more a border case in that regard. Still I'll probably stick with the original tool for now because of that, because I fly with 100% AIG traffic all the time.

That's a pretty extreme case (250 aircraft in near vicinity!!) and an extreme OLOD range, which the new app was never intended to cover. As you say, you can always use the original tool and try and kill your computer that way 😄

Edited February 23, 20242 yr by Reset XPDR

Now that I've stopped dedicated testing and started actually flying again, I've got a few auto TLOD Min tweaking ideas I will float here as a sanity check:

- Allow cloud quality recovery if TLOD Min on Ground/Landing and FPS raises a good amount over FPS target eg. 10-20% because at the moment a cloud quality drop does not cancel until you are in the air.
- TLOD Min on Ground/Landing behaviour when descending below 2000 ft, consider only allowing TLOD reductions from then on as approach is considered locked in. Maybe a descent phase state variable, enabled but not set to trigger above 2000 ft and then triggered descending below 2000 ft.
- With TLOD Min on Ground/Landing consider automatically extending trigger altitude above 2000 ft when TLOD delta to get to TLOD Min is significant and also engage aforementioned descent TLOD lock so that TLOD works down in reasonably small increments.

Thank you for your work.

 

Daz

26 minutes ago, Reset XPDR said:

Allow cloud quality recovery if TLOD Min on Ground/Landing and FPS raises a good amount over FPS target eg. 10-20% because at the moment a cloud quality drop does not cancel until you are in the air.

I can't think of any negative effects doing this. 

26 minutes ago, Reset XPDR said:

TLOD Min on Ground/Landing behaviour when descending below 2000 ft, consider only allowing TLOD reductions from then on as approach is considered locked in. Maybe a descent phase state variable, enabled but not set to trigger above 2000 ft and then triggered descending below 2000 ft.

Would this mean that TLOD min will be locked below 2000ft and not change at all on the ground / approach / take-off? And then gradually increase above 2000 AGL?

26 minutes ago, Reset XPDR said:

With TLOD Min on Ground/Landing consider automatically extending trigger altitude above 2000 ft when TLOD delta to get to TLOD Min is significant and also engage aforementioned descent TLOD lock so that TLOD works down in reasonably small increments.

Not sure what you mean by this - isn't it the same as the sentence above?

8 hours ago, Reset XPDR said:

Further to discussion of the concept demonstration version of the MSFS2020_AutoFPS starting here, the app has now matured to a point to where I am happy to formally release it.

I have said this before and will say it again,

You Sir are a blessing to the community. Thank you for your non stop efforts to make a better experience for all of us. It is greatly appreciated.

Just booting up my rig now and will test your latest release 🙂

33 minutes ago, Cpt_Piett said:

Would this mean that TLOD min will be locked below 2000ft and not change at all on the ground / approach / take-off? And then gradually increase above 2000 AGL?

Not quite. Just to summarise, current functionality is as follows:

• TLOD will immediately change to TLOD minimum when your flight is loaded and will stay that way any time you are on the ground. Once you take off and start climbing, auto TLOD will kick in gradually on a sliding scale up to 1000 ft AGL, then normal range auto operation above that. On descent to landing, when you cross 2000 ft AGL, the app will progressively adjust your TLOD down so that as you cross 1000 ft AGL it will be at TLOD minimum and there it will stay locked all the way to the ground, taxi and shutdown at the gate. If you are level below 1000 ft AGL, then commence descending, TLOD will rapidly switch to TLOD minimum with no stepping as it thinks you are landing imminently.

What this doesn't say (because I thought it was already getting too wordy) is that if you are level and low during the approach phase, like in a traffic pattern, TLOD will normally hold where it is but if the terrain drops below you and AGL goes up this can trigger TLOD to start rising again because it thinks you are climbing. What I am proposing is that once you have crossed 2000 ft going up, the next time you cross 2000 ft on descent the app will lock out any such TLOD increases and will only ever hold or decrease towards TLOD Min as scheduled above, to avoid these up and down TLOD changes near the ground. It doesn't happen very often, but when it does it is quite noticeable.

33 minutes ago, Cpt_Piett said:

Not sure what you mean by this - isn't it the same as the sentence above?

They are my dev notes, so a little sloppy with wording sorry. No it isn't the same, rather it is an extension of it. I am essentially saying that if you have a high TLOD delta to get down to TLOD minimum and are descending quite quickly, the rate of TLOD change per second can go over the default 5 and potentially introduce stutters by doing so. The app has all this data so it could calculate what altitude it needs to start reducing TLOD, perhaps by an even lower rate than 5 per second, which could be more than the 2000 ft currently hard coded. This is a bit like the predictive code I built into the DynamicLOD app where it anticipates and leads an upcoming LOD table change. That's what I was trying to say. 

Anyway, it's late where I am so I'm off to bed now 🙂

 

Edited February 23, 20242 yr by Reset XPDR

9 hours ago, Cpt_Piett said:

I’d just like to take this opportunity to commend you for your tireless work in creating this app. I’ve participated in the demo stages and can wholeheartedly say that it’s an invaluable tool that has transformed my flight simming experience.

Now, how can we donate to contribute something in return for your contribution to the community?

here here! Even though FG seems to be turned off automatically right now, this app is providing me such an improved...and invaluable....experience to flight simming again.

20 minutes ago, Sonosusto said:

here here! Even though FG seems to be turned off automatically right now, this app is providing me such an improved...and invaluable....experience to flight simming again.

Is this something that is added to the community folder so it can easily be removed if it causes issues, or does it become part of MSFS?

Edited February 23, 20242 yr by Bobsk8

9 minutes ago, Bobsk8 said:

Is this something that is added to the community folder so it can easily be removed if it causes issues, or does it become part of MSFS?

It’s an app that runs externally.

13 minutes ago, Bobsk8 said:

Is this something that is added to the community folder so it can easily be removed if it causes issues, or does it become part of MSFS?

It's better than sliced bread.

How this would work regarding the FPS if your sim is using V-Sync and frames locked to 30?.

Edited February 23, 20242 yr by edpatino

15 minutes ago, edpatino said:

How this would work regarding the FPS is your sim is using V-Sync and frames locked to 30?.

It will work with locked fps, but it’s recommended to set target fps in the app 5% lower than locked fps. 

1 hour ago, edpatino said:

How this would work regarding the FPS if your sim is using V-Sync and frames locked to 30?.

Better use the DynamicLOD app in this case:

 

Edited February 23, 20242 yr by RALF9636

I see in the readme , it shows Uninstall , but I see nothing about uninstalling it if the users runs into a problem with it. That's kind of scary. I looked all over and can't find anyway to uninstall it. So once you install it, you are stuck with it??

Edited February 23, 20242 yr by Bobsk8

3 hours ago, Reset XPDR said:

Not quite. Just to summarise, current functionality is as follows:

• TLOD will immediately change to TLOD minimum when your flight is loaded and will stay that way any time you are on the ground. Once you take off and start climbing, auto TLOD will kick in gradually on a sliding scale up to 1000 ft AGL, then normal range auto operation above that. On descent to landing, when you cross 2000 ft AGL, the app will progressively adjust your TLOD down so that as you cross 1000 ft AGL it will be at TLOD minimum and there it will stay locked all the way to the ground, taxi and shutdown at the gate. If you are level below 1000 ft AGL, then commence descending, TLOD will rapidly switch to TLOD minimum with no stepping as it thinks you are landing imminently.

What this doesn't say (because I thought it was already getting too wordy) is that if you are level and low during the approach phase, like in a traffic pattern, TLOD will normally hold where it is but if the terrain drops below you and AGL goes up this can trigger TLOD to start rising again because it thinks you are climbing. What I am proposing is that once you have crossed 2000 ft going up, the next time you cross 2000 ft on descent the app will lock out any such TLOD increases and will only ever hold or decrease towards TLOD Min as scheduled above, to avoid these up and down TLOD changes near the ground. It doesn't happen very often, but when it does it is quite noticeable.

These rules sound like made for IFR flights in tubeliners. With GA aircraft on VFR flights (or aerobatic, helicopter, ornithopter, ..., you name it) you can't easily determine from the altitude profile if the pilot is going to land. So, there should be some dynamic behaviour for low'n slow flyers, if possible. Maybe, even a simple option "flying low" that activates another ruleset would be cool. Just my 2 cents, many thanks anyway for this great tool!

Edited February 23, 20242 yr by meerkat