CrazyKidJack

Thanks! I'll test it out later today 🙂

@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

Sounds good thanks. The log about using offset A000 is still incoming later just to remind you

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

This sounds great thanks

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.

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)

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) It looks like these failed because I can't find them

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 is also almost certainly caused by the same problem

No but see the edit to my previous comment. Specifically this part: So I didn't install as admin... but the installer process *thought* it was running as admin because it requested privileged access via UAC

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! 🙂

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. 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. 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

It is set correctly. See the screenshot below: Thanks for the EXE.xml file. I copied it in

Yes I did notice that as a problem. I modified the batch file manually to fix it

My %appdata% variable is set correctly. In fact, that is how I access the Microsoft Flight Simulator folder every time because it takes too long to navigate to it from the top level