Same here. 

The tool will not be start

 

Frank

Edited September 9, 20241 yr by f.skywalker

I wonder how OLOD works, I don't use that option myself but I can't see it having any effect except on land, at what height does it start loading in higher details, or are the higher details loaded into the memory regardless of altitude? if that is the case I can se the benefit of using lower settings at higher altitude to save up VRAM, otherwise not.

But I still don't understand the benefit of using a high setting on land and a lower one at higher altitude when it is on land and on approach you will increase performance with a lower setting.

Edited September 9, 20241 yr by Ixoye

1 hour ago, John Fields said:

Hi,

I've downloaded v0.4.2.17-test10 and installed, but it doesn't execute...

Latest version (test9) works without issue.

Regards.

 

 

1 hour ago, f.skywalker said:

Same here. 

The tool will not be start

 

Frank

 

Oops, right you both are. I did actually experience the same when I double checked it before release so I rebuilt it, installed it and got it working on my own system then completely forgot to update the release on github.🤪My apologies for the mix up.

I have uploaded the correct version now, so please re-download and install as normal from the same link as before here.

Please confirm it works this time.

Duplicate

Edited September 9, 20241 yr by Reset XPDR
Duplicate

Duplicate

Edited September 9, 20241 yr by Reset XPDR
Duplicate

Duplicate

Edited September 9, 20241 yr by Reset XPDR
Duplicate

Duplicate

Edited September 9, 20241 yr by Reset XPDR
Duplicate

Duplicate

Edited September 9, 20241 yr by Reset XPDR
Duplicate

1 hour ago, Ixoye said:

I wonder how OLOD works, I don't use that option myself but I can't see it having any effect except on land, at what height does it start loading in higher details, or are the higher details loaded into the memory regardless of altitude? if that is the case I can se the benefit of using lower settings at higher altitude to save up VRAM, otherwise not.

But I still don't understand the benefit of using a high setting on land and a lower one at higher altitude when it is on land and on approach you will increase performance with a lower setting.

IMO OLOD adjustment was not really a necessary addition to this app because, as you say, decreasing it up high frees up resources you don't really need back anyway up there, but quite a few users wanted it in there so there you have it. Thankfully OLOD adjustment doesn't have anywhere near as much of effect on performance as TLOD does, so there is no need to even use it if you don't want to.

Thanks for the new installer (Test10)

 

Frank

11 hours ago, Reset XPDR said:

If LS is detected as running at the start of a flight, the FPS reading will be scaled up by the LS FG multiplier so you are seeing your actual LS FG FPS.

I'm not seeing the actual LS FG FPS, although the status line reads "LSFG 2x Mode". 

11 hours ago, Reset XPDR said:

TLOD Min Extra in Auto TLOD has been a long-term desire of mine to get working with the capped FPS I use for VR so that I get the most TLOD I can while maintaining that FPS cap

Do you recommend using locked FPS only with Auto TLOD mode?

Also (apologies for not checking the readme first), what's the difference between Auto TLOD and FPS sensitivity?

Edited September 9, 20241 yr by Cpt_Piett

47 minutes ago, Cpt_Piett said:

I'm not seeing the actual LS FG FPS, although the status line reads "LSFG 2x Mode". 

Do you by chance still happen to have FG enabled in MSFS and LSFG enabled, because running both FGs may be the cause? Do you have a screen shot of the app and MSFS with an FPS counter showing with this? If possible show one screenshot without LSFG enabled and one with it enabled, hitting the app reset button in between. Thanks.

8 minutes ago, Reset XPDR said:

Do you by chance still happen to have FG enabled in MSFS and LSFG enabled, because running both FGs may be the cause? Do you have a screen shot of the app and MSFS with an FPS counter showing with this? If possible show one screenshot without LSFG enabled and one with it enabled, hitting the app reset button in between. Thanks.

I did indeed have both FG and LSFG enabled. With native FG enabled, LS FG FPS is correctly showing in x2, x3 and x4 modes. 

35 minutes ago, Cpt_Piett said:

Do you recommend using locked FPS only with Auto TLOD mode?

Also (apologies for not checking the readme first), what's the difference between Auto TLOD and FPS sensitivity?

You can use FPS locked with FPS sensitivity and tolerance methods but it needs to be set 5% or so higher than your target FPS so that the logic has the headroom above target FPS to do its thing. This is how you were using AutoFPS before I asked to to raise/remove your FPS lock to test the new TLOD Min Extra functionality ie. you had an FPS lock of 63 and a target of 60 FPS and it all worked good.

Auto TLOD differs from the other two automation methods in that it was initially designed to ignore any target FPS and just work TLOD to an altitude schedule, very similar to how OLOD currently functions. This works well for those that would otherwise need to have a locked FPS that needed to be maintained at all times for either vsync (2D) or motion reprojection (VR) reasons, otherwise screen tearing (2D) or image wobbling (VR) occur. I am in the latter camp with my Quest 3 headset needing a constant 40 FPS to maintain motion reprojection at 80 Hz (MR is effectively FG for VR, but is predictive not reactive like FG).

In the past I had to set my TLOD altitude schedule manually so that I didn't every break this FPS lock, and that sometimes meant I was leaving extra TLOD on the table because I had to set it low enough to cover all scenarios, but sometimes I do actually have the performance headroom to go higher but the app couldn't tell because of the FPS lock. Now, with the new TLOD Min Extra on ground in Auto TLOD mode, it can do a similar thing to the other automation modes and seek additional TLOD that still does not break that FPS lock. In order for it to do that, it needs to know what your target (locked) FPS is (actually, this has made me think I may not need to ask the user for this, I could just detect it!). In difference to the other automation modes, this seeking process has to go just past where the FPS lock is lost, then back it down to where it was last still locked. As such, users of this automation method can now enjoy similar TLOD Min extra that the the other two modes currently offer.

My dream is to be able to get into the workings of MSFS performance metrics and find out what the CPU frame time is, because with this I could work out CPU headroom in all modes which, in concert with GPU headroom I can already work out, would allow the app to change TLOD in a predictive rather than reactive mode and that would improve the app experience significantly. I still haven't worked out how to do this, well not without a significant performance impact on the app in doing so, but I am sure it can be done so I will continue to research it. If anyone knows of a low performance impact way to do this in C# please let me know!