8 hours ago, Farlis said:

Hmm... after the update the UI is no longer displayed. The program is running as always but when I click on the Tray Icon and it goes to the Taskbar the window remains hidden.

Same here

Just test this Tray Icon or Taskbar. Had to remove and re-install the app and tick "App Closes to System Tray" as I preferred when clicking close... to close the app. But let's do it for the test.

When I click _ Minimize it goes to the taskbar.

When I click X Close it goes to the Tray Icon (because I choose "App closes to System Tray" during the installation).

When I click the app icon in the Tray Icon, the UI appears.

Isn't it what is expected ?

Edited June 13, 2025Jun 13 by vbazillio

Just for the fun of it. Here's my default Windows download folder 😉

I normally download stuff from my browsers in another folder 😉

5 hours ago, LGKR said:

Same here

Can you tell me what the following two lines are set to in %appdata%\MSFS_AutoFPS\MSFS_AutoFPS.config ?

  <add key="windowTop" value="239" />
  <add key="windowLeft" value="344" />

Thanks.

 

5 hours ago, vbazillio said:

Just test this Tray Icon or Taskbar. Had to remove and re-install the app and tick "App Closes to System Tray" as I preferred when clicking close... to close the app. But let's do it for the test.

When I click _ Minimize it goes to the taskbar.

When I click X Close it goes to the Tray Icon (because I choose "App closes to System Tray" during the installation).

When I click the app icon in the Tray Icon, the UI appears.

Isn't it what is expected ?

Yes, that is exactly how it is supposed to work.

BTW, you didn't have to uninstall and reinstall to try this. Just run the installer and select App Closes to System Tray and click update and it will change over to residing in the system tray without losing any of your settings. 

I've just checked out the coding I did for resetting the window position and while it does work within 10 seconds, that 10 seconds is from when the config file was last updated, which is when you very first start, NOT close, the app, until when the app starts again which IMO is too tight a timeline for the user to achieve this.

I will change it in the next version so that this time window will be from when you close, not open, the app which should be achievable within 10 seconds but I might increase this to 15 seconds to not make it a race. I don't want to make this time window too long as I don't want users inadvertently resetting their window positions, so 15 seconds should be a good compromise.

In the interim, for anyone experiencing the app window not appearing on screen, you can either enjoy the challenge and do the 10 second race from app open to app opening again or just delete the file %appdata%\MSFS_AutoFPS\MSFS_AutoFPS.config, which will automatically be recreated on next app run and will give you a clean install of the app's common configuration (that includes window position) without losing your profiles.

 

 

Edited June 13, 2025Jun 13 by Reset XPDR

9 hours ago, vbazillio said:

Just for the fun of it. Here's my default Windows download folder 😉

I normally download stuff from my browsers in another folder 😉

So I like to make a few test versions. 😂

Trying to get my head around the expert options, but can't seem to make it work how I would like it. Wasn't able to find a tutorial showing all the options in depth either.

These are my settings. With this, it works pretty good overall, but the TLOD adjustment is not always consistent. Sometimes it locks.

What I want to achieve: TLOD can go down to 50 when my FPS tanks below target, but should get up fast to whatever it can support. That could be 400 as well as long as I'm on target FPS. 

In game I have TLOD 200 and OLOD 150.

Any suggestions?

 

10 hours ago, Reset XPDR said:

Can you tell me what the following two lines are set to in %appdata%\MSFS_AutoFPS\MSFS_AutoFPS.config ?

  <add key="windowTop" value="239" />
  <add key="windowLeft" value="344" />

Thanks.

 

It seems you have already figured out what the error was, but anyways, the two lines read as follows, on my system;

WindowTop value = -32000

WindowLeft value = -32000

So I am guessing the window is far out there somewhere

1 hour ago, LGKR said:

It seems you have already figured out what the error was, but anyways, the two lines read as follows, on my system;

WindowTop value = -32000

WindowLeft value = -32000

So I am guessing the window is far out there somewhere

I haven't actually found the error, I have just found a way to work around it. The code for window position is pretty simple - the app works out the window has moved by comparing the top left coordinates the app has stored with the top left coordinates Windows is reporting. If they are different, it should mean you have moved the window, so it stores those changed top left coordinates for restoration when the app next starts. 

I didn't expect the values to be that extreme and I'm not sure how they even were set to that, unless you have 20 4K screens stacked in a rectangle 😄. I will put some reasonability checks in the next update, which will reset them to default if way out of bounds like this. FYI, if you set those 2 values to 50 you will get your window back.

Edit: Copilot to the rescue. It says:

Quote

Windows reports (-32000, -32000) for a window's top-left coordinates when the window is minimized. This is a system behavior rather than an actual screen position. When a window is minimized, Windows moves it off-screen to prevent interference with active windows, and this extreme negative coordinate is used as an indicator.

I was not aware of this and I am a bit surprised it is surfacing now because the code has been this way for a very long time so I should have received multiple reports of this issue and should even have experienced it myself.

In any case, it is a simple fix to ignore saving coordinates like this, so I will put the fix in the next release, probably sooner rather than later.

Thanks for getting back to me with this info as I wouldn't have found it otherwise.

Edit 2:

Found the issue! It happens when you last had the app sent to the system tray when it exited. The next time it starts the auto update notification pops up, which activates the underlaying window code that saves the window position when changed, but the window actually exists in the abyss of the system tray so those black hole coordinates get saved. When the updated app runs after the auto update, the window is still off in the never never land.

Now that I know what causes it and I can 100% reproduce it, I can fix it properly.

Edited June 14, 2025Jun 14 by Reset XPDR

5 hours ago, Fumina said:

Any suggestions?

I don't normally give suggestions but you've strayed quite far from default and it pains me. You'd be best of using the default settings for the IFR profile that come with a clean install of the app. If you are using an FPS cap, change the automation mode to FPS cap and match the target FPS to that cap. If no FPS cap is in use, stay with FPS sensitivity mode, tick TLOD Min+ and change TLOD Max to 400. That's all you really need to do to get what you have stated you desire.

Edited June 14, 2025Jun 14 by Reset XPDR

1 hour ago, Reset XPDR said:

I haven't actually found the error, I have just found a way to work around it. The code for window position is pretty simple - the app works out the window has moved by comparing the top left coordinates the app has stored with the top left coordinates Windows is reporting. If they are different, it should mean you have moved the window, so it stores those changed top left coordinates for restoration when the app next starts. 

I didn't expect the values to be that extreme and I'm not sure how they even were set to that, unless you have 20 4K screens stacked in a rectangle 😄. I will put some reasonability checks in the next update, which will reset them to default if way out of bounds like this. FYI, if you set those 2 values to 50 you will get your window back.

Edit: Copilot to the rescue. It says:

I was not aware of this and I am a bit surprised it is surfacing now because the code has been this way for a very long time so I should have received multiple reports of this issue and should even have experienced it myself.

In any case, it is a simple fix to ignore saving coordinates like this, so I will put the fix in the next release, probably sooner rather than later.

Thanks for getting back to me with this info as I wouldn't have found it otherwise.

I deleted the config as you suggested, and all loaded just fine on next startup. Thanks for all your efforts!

6 minutes ago, LGKR said:

I deleted the config as you suggested, and all loaded just fine on next startup. Thanks for all your efforts!

I've updated my response to you above with what I have found with this. In short, I have found the actual slimy little bug and will issue a fix in the next few days.

Edited June 14, 2025Jun 14 by Reset XPDR

Hey, is it right that AutoFPS does not recognize the newest LSFG Version?

8 hours ago, mobiel said:

Hey, is it right that AutoFPS does not recognize the newest LSFG Version?

The new LSFG version 3.2 is being detected fine for me, including the correct multiplier:

What specific issue are you having?