Problems with A000 and Honeycomb bravo knob to multiple simulated knobs

[CrazyKidJack]

26 minutes ago, John Dowson said:

Looks to be a space between your t and a (e.g 'AppDat a' as opposed to 'AppData', but maybe thats just your image/my eyes...

Yah, I checked again just now. That space isn't real (but good eye for pointing that out!). For some reason that just how cmd is displaying it when I type it in.

 

 

26 minutes ago, John Dowson said:

Other than that. I have no idea why its not determining the correct location. It works for everyone else...very strange....

I'm still thinking it's because FSUIPC is looking for things in the Admin user folders but all of my stuff is not there...
For example, I think FSUIPC installed the documentation in the Admin user folders. I'm not 100% if it does anything else in the Admin user folder or if so, *what* it does... but I think this is probably the root of the problem. I think the majority of users don't have a separate Admin account. So while their account is not called "Admin" it does have Admin privilieges and so the FSUIPC installer doesn't have a problem and just uses their user's folders/files. However, on my system (and I'm sure some other people's and probably yours... though I think we are in the minority) my user account is not called "Admin" and does not have Admin privileges. So when FSUIPC (and many other programs) install themselves, they ask for Admin privileges via Windows UAC. The problem comes when the installer uses the "Effective user" of the installer process instead of the "actual user". When it asks for admin privilege via UAC, the effective user changes to "Admin" even though I'm really installing it on MY account (jackp). But since the installer process is using the "effective user" to figure out things like where the %appdata% folder is... it always resolves to the Admin user's folders/files... when really it should be using the "actual user" information to resolve that correctly.

 

I'll do some trouble shooting later to confirm... but this happens for *many* programs that don't have a large user base. Programs from large development firms (like direct from Microsoft, or Steam, etc) don't have this problem and have figured out how to use the "actual user" instead of the "effective one" but most "smaller" applications have this problem.

 

 

26 minutes ago, John Dowson said:

Then I have no idea why this test is failing:

IfFileExists "$APPDATA\Microsoft Flight Simulator\UserCfg.opt" steamUserCfg
    nsArray::Set LogMessagesArray "Determing Community folder for MS Store install"
...
    steamUserCfg:
      nsArray::Set LogMessagesArray "Determing Community folder for Steam install"

Where are those lines of code? I do not see them in the MSFS.bat file that gets installed when the "Desktop Shortcut" option is selected in the FSUIPC installer

[CrazyKidJack]

1 hour ago, John Dowson said:

Anyway, here's the WASM. Just extract into your Community folder and it will be recognised by FSUIPC:
fsuipc-lvar-module.zip

The other issue you will have though is that FSUIPC will not autostart with MSFS as it cannot find the location of your EXE.xml. Did you not notice this? Is it a problem?

I almost didn't realize the detail in this comment.

#1 Thanks for the module zip. I have extracted it as you said and the new Add-on menu item shows up now (yay!)

#2 I didn't notice it wasn't auto-starting because I was using the "Desktop shortcut" batch file that your installer gives and I modified (as mentioned before). But with the EXE.xml file you gave me, it is now starting with MSFS 2020 no problem and with no need for the batch file! Thank you! 🙂

[John Dowson]

36 minutes ago, CrazyKidJack said:

I'm still thinking it's because FSUIPC is looking for things in the Admin user folders but all of my stuff is not there...
For example, I think FSUIPC installed the documentation in the Admin user folders. I'm not 100% if it does anything else in the Admin user folder or if so, *what* it does... but I think this is probably the root of the problem. I'll do some trouble shooting later.

FSUIPC installs nothing in the Admin folder, unless you are running as admin. However, yout installation log does indicate that it is installing in the admin folder:
 

Quote

 

Documents folder location: C:\Users\Admin\data\Documents\FSUIPC7

 

Not sure why thiis is either. Did you install the first time as admin? Once installed, it will use the previous location in the registry the next time you install. Try running the uninstaller manually (from the FSUIPC7 installation folder or the Windows App management panel) and re-install again, to see if it picks up your correct Documents folder.
And show me the new InstallFSUIPC7.log file please. Your Documents folder is taken from the registry for a fresh install, using the HKCU Personal key under "SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders"

Due to these errors, there may be some other empty folders that have been created that you may want to move:
   Create folder: \fsuipc-lvar-module
   Create folder: \fsuipc-lvar-module
although those may have failed....Thats an issue in the installer which I will correct - it shouldn't try and install the WASM if the Community folder can't be determined.

 

[John Dowson]

31 minutes ago, CrazyKidJack said:

Where are those lines of code? I do not see them in the MSFS.bat file that gets installed when the "Desktop Shortcut" option is selected in the FSUIPC installer

Thats code from the installer to determine the location of your UserCfg.opt file.Thats whats failing for you during installation, and so thinks you have an MS Store install.

[CrazyKidJack]

3 minutes ago, John Dowson said:

Not sure why thiis is either. Did you install the first time as admin?

No but see the edit to my previous comment. Specifically this part:

 

34 minutes ago, CrazyKidJack said:

However, on my system (and I'm sure some other people's and probably yours... though I think we are in the minority) my user account is not called "Admin" and does not have Admin privileges. So when FSUIPC (and many other programs) install themselves, they ask for Admin privileges via Windows UAC. The problem comes when the installer uses the "Effective user" of the installer process instead of the "actual user". When it asks for admin privilege via UAC, the effective user changes to "Admin" even though I'm really installing it on MY account (jackp). But since the installer process is using the "effective user" to figure out things like where the %appdata% folder is... it always resolves to the Admin user's folders/files... when really it should be using the "actual user" information to resolve that correctly.

So I didn't install as admin... but the installer process *thought* it was running as admin because it requested privileged access via UAC

[CrazyKidJack]

In my last post, I reference specifically that the %appdata% folder that the FSUIPC installer is using is wrong because it's using the "effective user" of the process to determine the location. I just want to make clear that 

6 minutes ago, John Dowson said:

Documents folder location: C:\Users\Admin\data\Documents\FSUIPC7

is also almost certainly caused by the same problem

[CrazyKidJack]

6 minutes ago, John Dowson said:

Try running the uninstaller manually (from the FSUIPC7 installation folder or the Windows App management panel) and re-install again, to see if it picks up your correct Documents folder.
And show me the new InstallFSUIPC7.log file please. Your Documents folder is taken from the registry for a fresh install, using the HKCU Personal key under "SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders"

I can try uninstalling/reinstalling like you are saying... but I'm fairly certain I will get the same behavior for the reason I specified above (the installer is using the "Effective user" to determine folder/file locations)
 

7 minutes ago, John Dowson said:

Due to these errors, there may be some other empty folders that have been created that you may want to move:
   Create folder: \fsuipc-lvar-module
   Create folder: \fsuipc-lvar-module
although those may have failed....

It looks like these failed because I can't find them

[John Dowson]

5 minutes ago, CrazyKidJack said:

n my last post, I reference specifically that the %appdata% folder that the FSUIPC installer is using is wrong because it's using the "effective user" of the process to determine the location. I just want to make clear that 

11 minutes ago, John Dowson said:

Documents folder location: C:\Users\Admin\data\Documents\FSUIPC7

is also almost certainly caused by the same problem

But it doesn't do this for any other user - the installer is the same for all other users and I've not come across this before.....
...and the installer no longer requests admin privileges anyway...

[CrazyKidJack]

Just now, John Dowson said:

But it doesn't do this for any other user - the installer is the same for all other users and I've not come across this before.....

Like I said... I think most people give their personal accounts privileged access (this is actually the default in Windows) and so they wouldn't run into this problem.

For those that *don't* have privileged personal user accounts on their computer, they may have simply never reported it because users that have the knowledge to know to *disable* privileged access on their accounts are typically more technical and so
#1 probably deal with this often from other applications as well (as I have)
#2 because they deal with it often, probably know how to fix it in most cases (manually copy/paste config files from the Admin user to their actual user)

[CrazyKidJack]

7 minutes ago, John Dowson said:

But it doesn't do this for any other user - the installer is the same for all other users and I've not come across this before.....

I would be happy to hop on a video call with you to show you what I'm doing and how my accounts are set up so you can understand the problem.
You can almost certainly replicate it yourself if you create an account on your modern Windows computer *without* privileged access, and fresh-install FSUIPC.

What should happen is you get a Windows UAC prompt asking you to type in the password for one of the privileged accounts on the machine. Whichever privileged account you select and type the password for, all of the data that FSUIPC installs will install under that user. So when you try to run FSUIPC as the non-privileged user (or even a *different* privileged one), things will not work as expected.

[John Dowson]

3 minutes ago, CrazyKidJack said:

Like I said... I think most people give their personal accounts privileged access (this is actually the default in Windows) and so they wouldn't run into this problem.

Yes I know, but not one person with this issue in many years sounds suspicious...
And, as I said, the installer doesn't/shouldn't request admin privileges anyway - from the installer:
 

Quote

; Request admin privileges
;RequestExecutionLevel admin

i.e. commented out.

I will look at this at some point to clarify, when i have more time.

1 minute ago, CrazyKidJack said:

I would be happy to hop on a video call with you to show you what I'm doing and how my accounts are set up so you can understand the problem.

That is not necessary. I understand what you think the problem is and may be, but am confused as to why it is doing this.

3 minutes ago, CrazyKidJack said:

What should happen is you get a Windows UAC prompt asking you to type in the password for one of the privileged accounts on the machine.

But you shouldn't get this. As I said, it is not installed as a privileged user. You should not have to enter any password. As i said, I will look into it, but not now. It will be low priority I'm afraid, so when I have time. Once I've looked into it, I will post and updated installer for you to try.

[John Dowson]

This is interesting:
 

Quote

On Vista and later, UAC will run every application (including installers*) with restricted rights - even when the user is an Admin with full rights. Elevation can give applications the full rights. For "Admin" users UAC elevation will only need a click on Yes and the app will still run under the current user's account. For "Restricted" (non-admin) users UAC elevation will ask the user the enter the login credentials of an Admin account and the app will then run under that account. In the latter case the meaning of the user-specific $PROFILE** (and everything that lies in that folder) will change, because the application is running under a different user. At the same time $PROGRAMFILES[32/64] is not user-specific. It's a system-wide folder that will be identical, no matter what account the application is running under...

So yes, you are correct.

I think the simplest solution in your situation would be for you to temporarily give your user account admin privileges (uninstall first). Then re-install, then remove the admin rights.
I have put this on my list to look into, but this will take quite a while as it is low priority.

[CrazyKidJack]

12 minutes ago, John Dowson said:

But you shouldn't get this. As I said, it is not installed as a privileged user. You should not have to enter any password. As i said, I will look into it, but not now. It will be low priority I'm afraid, so when I have time. Once I've looked into it, I will post and updated installer for you to try.

This sounds great thanks

[CrazyKidJack]

5 minutes ago, John Dowson said:

So yes, you are correct.

I think the simplest solution in your situation would be for you to temporarily give your user account admin privileges (uninstall first). Then re-install, then remove the admin rights.
I have put this on my list to look into, but this will take quite a while as it is low priority.

Yes by my understanding, this could work. Might be more elegant if there was a way to determine the "actual user" instead of the "effective user" in the installation process. If not, then maybe just allowing the user to select to which folders they want things installed?

In my personal development, I try to avoid the user-specific folders as much as possible for this very reason. I pretty much only put things in user-specific folders during runtime of the application, and only if the user requested it (like having different settings for each user on the computer). So during installation my apps will basically install everything into "Program Files/myProg" or "Program Files (x86)/myProg" depending on whether it's 32 or 64-bit compiled, and then at run-time I'll save user-configs in user-specific folders... but everything done at install-time happens in "Program Files". And even at run-time, I will often give the users the option to save config files "for every user" (which really just means in the installation directory instead of the user-specific folder.

 

I don't know if my approach is the "proper" way to do it... but I find that I avoid a lot of problems by handling it that way.

I have also considered taking your approach, but using the "Shared" folder system instead of the user-specific ones... I have not actually done this before but I've considered it

[John Dowson]

15 minutes ago, CrazyKidJack said:

Might be more elegant if there was a way to determine the "actual user" instead of the "effective user" in the installation process.

Well, yes, that would be ideal, but I'm not sure its possible. The problem is that its Windows that elevates the installer to Admin, and so by the time it hits the installer code there is only the Admin user, and no way to determine the 'actual' user. Windows tries to determine how you do these things - see the answer to the same question posted here: https://stackoverflow.com/questions/48844435/get-logged-in-username-in-nsis-installer-when-running-as-another-user-admin
 

15 minutes ago, CrazyKidJack said:

If not, then maybe just allowing the user to select to which folders they want things installed?

That may be ok for Documents, but other locations (e.g. UserCfp.opt file) are mandated by the version of MSFS you have, and most users would not be able to determine this, it needs to be done by the installer. As I have said, this is the first time I have heard of this problem in 3 years or so, so I'm not going to spend more time looking into this.
For now, you will have to live with giving your user account temporary admin privileges, as advised, and I'll also recommend this in the Installation manual for any other users who have the same issue.

[CrazyKidJack]

Sounds good thanks.

The log about using offset A000 is still incoming later just to remind you

[John Dowson]

2 minutes ago, CrazyKidJack said:

The log about using offset A000 is still incoming later just to remind you

Ok, I'll take a look tomorrow now. Finishing for the day....

[CrazyKidJack]

@John Dowson Attached are two logs. One shows the "V" key trying to set bit 9 at offset A000... but the condition on A000 on key "1" fails. Also, not that there is no log of offset A000 changing... even though I do have that offset logging turned on.

The other log shows the "V" key setting bit 9 at offset 66C0 and the condition succeeding on key "1".

A000.log FSUIPC7_66C0.log

[John Dowson]

Yes, there was read protection added to offset A000 for some reason. I have removed this in the attached version:, v7.1.0g: FSUIPC7.exe

[CrazyKidJack]

6 hours ago, John Dowson said:

I have removed this in the attached version:, v7.1.0g: FSUIPC7.exe

Thanks! I'll test it out later today 🙂