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

Excellent recommendation, I will do that when I generate the log for you

Do you have an MS Store install or a Steam install? Do you know the location of your MSFS UserCfg.opt file? #1 I have the steam version. It is NOT installed as Admin which I think is the root of the problem. #2 My UserCfg.opt file is located at "C:\Users\jackp\AppData\Roaming\Microsoft Flight Simulator" which the is correct and default location. Again, I did not install MSFS 2020 as Admin and I do not run FSUIPC as Admin

Again, I am NOT writing to those offsets. But setting button flags on a no-existent joystick worked great if I wasn't trying to use an offset condition. See the following lines: [Keys] 16=50,8,1003,3842 ;set flag 2 -{2: Press=: Joy 15 Button 2 }- 110=88,8,1003,3848 ;set flag 8 (Xpndr) -{X: Press=: Joy 15 Button 8 }- [Buttons] 95=CP(F+15,8)(F+15,2)64,12,C65652,0 ;xpndr flag, flag 2, incr -{XPNDR_100_INC}- In these examples, I'm setting the button flags for joystick 15 buttons 2 and 8 and reading those flags using button conditions (there is no devices assigned to joystick 15 in the [JoyNames] section. It only doesn't work with offset conditions.

I think that is far too strong. We provide documentation to hopefully reduce the time spent on support, which takes away from development, bug-fixing, and other activities that are more productive and useful (and also more interesting) than repeating things said many times and also documented. We don't expect a *thorough* reading (who has time for that with all the software/hardware you need to install these days!), but a quick look to know what's available and a review of the user' manual is always a good idea. Then, use then as needed to help you, depending on your knowledge of flight sims and maybe earlier versions of FSUIPC. And if you have an issue or need more specific information, you should consult the Advanced guide or the specific guides for using lua, PMDG aircraft or offset use. If you can't find anything there, then try a quick search of the forums, and maybe look in the FAQ section, or User Contributions if something extra thats not provided. All we ask is that you try to help yourself first, using the provided resources, before asking. The answer may be deep in the documentation somewhere and not easily found - it is far from perfect I'm afraid....! I have no preference whatsoever on the technical understanding level of the people who post for help. Many people who post here have a far better and deeper understanding of aircraft and aircraft subsytems than I do (or probably ever will), and there are far better lua programmers/experts on here as well. I would certainly never judge a persons technical understanding on what they post, as they are often posting to learn anyway, regardless of ability or previous experience, and am not interested in any qualifications, technical or not, of any poster. I wasn't trying to "come at you". I just noticed through reading the forum on my own as a user and paying customer of your product, that there were several posts with what I understood to be passive aggression toward people who, in your opinion, 1) Were having trouble understanding your responses due to a lack of technical proficiency and/or 2) Had not spent "enough" time reading through the documentation. Since I noticed this, I felt uncomfortable using the forum which is why I waited so many days to reach out in the first place. And then when I did finally post here, I wanted to quickly and decisively put your concerns to rest. I don't expect you to care about my credentials, I just didn't want you to feel that I wasn't qualified to understand or use your product. Additionally, while I spent a lot of time reading the docs... I think it should be noted that the documentation itself is quite technical (if you don't have a technical background) and I could understand how, presented with literally hundreds of pages of documentation, a tech-novice would give up quite quickly and look for a "simple stupid" answer from a human on the forum instead of trying to decipher the documentation.

And here: 14=D66C0 49,8,66502,1 ;vor flag&setting flag 1 -{1: Press=AP_NAV_SELECT_SET }- As documented, the format is: You have the '<size><offset>', but not the '<mask><condition>' According to the documentation (and indeed also the automatic re-writing of the .ini file when FSUIPC is started) I think you may be mistake (though you obviously know more about it than me so please correct me if I'm wrong. Here's a screen shot from the documentation talking about how the mask and condition are optional. https://prnt.sc/12kyqf3 The documentation says that the condition will default to "!0" if it is omitted... this is the exact behavior I want... in fact, if I actually type out "!0" FSUIPC re-writes the .ini file on startup and REMOVES my handwritten condition Additionally, the mask would be important if I were writing to any other offset in the DWord, but I'm not. Now... I did try to use the mask... but as I was running into problems I tried to remove as much as possible from the condition for troubleshooting... since then I got the 66C0 offset working (as I stated) and because it was working, I added the mask back in (though I still can't add the condition because FSUIPC will just over-write it anyways)

Yes, you should use that. Not just for the 128 buttons, but also for the lvar/functionality. It is pretty much complete - I just need to update the documentation (and add a minor fix to event.button for buttons > 32) and will release this officially soon, hopefully at the weekend. You should have a WASM entry under the Add-ons menu, where you first need to activate the WASM functionality (you do this once). Did you select to install the WASM during installation? If so and its not there, please show me your InstallFSUIPC7.log file. Also check your MSFS community folder. FSUIPC7 only adds the Add-ons ->WASM entry if it can see the FSUIPC WASM folder fsuipc-lvar-module in your MSFS Community folder. I did select "to install the WASM" during installation of FSUIPC. I also installed MobiFlight Connector, enabled beta updates, updated, and moved the "mobiflight-event-module" folder into the Packages>Community folder of MSFS 2020 as seen in this screenshot: https://prnt.sc/12ky7du (I would have just attached the image file instead of giving you a link that you might not trust, but it the forum said it was too big) Despite installing both of these, I don't have the "WASM entry under the Add-ons menu". I have attached the InstallFSUIPC7.log here... Now that I am looking through the file myself, it seems that FSUIPC assumes it should install things in the Admin user folders... Now that I think about it... I think I did have to rectify that situation when I originally installed FSUIPC (remember that I just installed the beta version last night... so perhaps my problem regarding the WASM Add-on menu is simply because I haven't moved the files to the appropriate non-Admin user folders... though it would be a nice feature add if FSUIPC didn't assume everyone wanted to run everything as Admin 😕 This is a common problem I see with a lot of applications that the more security conscious of us have to deal with... I will try to move those files/folders to the appropriate non-Admin user directories and see what happens InstallFSUIPC7.log

In regards to offset A000 and your comment I will get you the log file asap. Though be advised that it will be very long if you want me to log events. The HC send continuous input for many of it's buttons so any of those buttons that are mapped to a control constantly register events. I found that opening the log file in a text-editor with regex based searching (like Notepad++) can easily filter out the lines of the log that you don't want though... Log file coming ASAP (though I'm working so probably a few hours)

Perhaps I should have been more clear. I'm not trying to set the value of the 03C0 offsets directly. If you look closelier at the .ini line I used, I'm not setting that offset directly, I'm simply pressing the associated button (actually... I'm using the control to set that buttons flag... 1003). By my understanding that should change the offset to reflect that the button was pushed except for this: Again in my initial questions I said: I couldn't tell exactly from this post whether or not "when there is at least one assignment to that joystick" means "when there is an actual device in the [JoyNames] section mapped to joystick number matching the offset I'm trying to read... OR if it means "when there is an entry in the [Buttons] section that uses that joystick as the trigger". Since I wasn't sure and I can't force a particular device to be assigned to joystick number 15 (or at least, I don't know how to force that assignment) I tried to add an entry in the [Buttons] section for with joystick 15, button 9 as a trigger with the "no-op" control and it still didn't work. Because of this, I assumed that you must've meant "when there is a [JoyNames] assignment" as opposed to a "[Buttons] entry". Perhaps you could verify that I'm correct about this.

Another update: #1 I installed the latest beta of FSUIPC (v7.1.0f), the mobiflight stuff, and created a .evt file for the G1000 events from mobiflight. The events show up as possible selections. Great! However, I also discovered through the event logs how to change the CDI in the G1000 to whichever indicator I want using non-mobiflight events... 🤦‍♂️ #2 Nevertheless, according to this post once that is all installed, I should have a new entry in the "Add-ons" menu in FSUIPC for LVar accesss... but I don't see it. What am I missing? #3 Regardless of any of that... the A000 offset is still an issue and I'm wondering why it wasn't working for me still

Update, even though I'm tried of reading through the forums... I did keep reading... and found something about "mobiflight wasm module". So I'm google-ing that right now... hopefully it is straight forward