Problems with A000 and Honeycomb bravo knob to multiple simulated knobs

[CrazyKidJack]

Because I know that you always complain when people do not *thoroughly* read the documentation and forums... I spent *days* reading through every documentation file provided with the program, every FAQ forum topic, and tried probably a dozen different searches on the forum to look for my answer; I don't guarantee the answer is not somewhere... but I could not find it with diligent effort. I also know you prefer to help people that have a solid technical understanding, so I wanted to let you know I have over a decade in software development, a Bachelor's in Comp Sci, and am OSCP certified.

My relevant hardware: Honeycomb Bravo Throttle Quadrant (henceforth called "HC")
My relevant software: MSFS 2020v1.15.10.0 / FSUIPC7v7.0.9 / HidDemo.lua (set up properly to work and map controls to joystick 64 & 65)
Notes: I am not using a debugger... just the in-built logging features of FSUIPC7

What I want to achieve overall: Using the "decr/incr" knob on the HC to interact with any knob in the simulator.

My approach: Use key/button programming in FSUIPC to set "flags" telling FSUIPC which control the knob should alter in the sim

What I have done so far: I have successfully used keyboard keys to set most flags. The "flags" I'm using are really the button flags for joystick 15. Joystick 15 has no actual device assigned to it. So far I have assigned flags for "selectors" 1, 2, 3, and 4, nav radio, comm radio, barometer, and transponder.

What I'm trying to do now: The C172 that comes with MSFS 2020 has a G1000 autopilot (AP) system. When you set the "course" for the vor indicators on the G1000, you can't see what you are selected without also switching the active indicator (the one that is default is GPS indicator). What I want to do is have the "active indicator" switched to the one I am currently setting the course for. In other words, if the nav, and selector 2 flags are set, and I start turning the knob on the HC, I want it to switch the "active indicator" to VOR2 and start increasing the selected course. As an intermediate testing step, I tried to create a new flag (vor) such that when I set the vor flag and press the "1" or "2" key, it just switches the "active indicator" to vor 1 or 2 respectively. My first attempt was to use the same joystick 15 button flags as the others... but that posed a problem...

To do this, I need to add a condition to a key bind but only offset conditions are available for [Keys]. According to the offsetStatus-v0.17.ods document 03C0 is where the button states are stored for joysticks 0-15. However, although it is not 100% clear from this post 

 

it seems that FSUIPC only updates those offsets if there is an actual device assigned to the joystick whose offset I'm trying to read. So even though I have the following line for my VOR flag:

113=86,8,1003,3849 ;set flag 9 (VOR)  -{V: Press=: Joy 15 Button 9 }-

the actual status that the button was pressed is not saved at offset x03FC+9bits. Therefore, my [Keys] condition:

14=D03FC&200 49,8,66502,1 ;vor flag&setting flag 1  -{1: Press=AP_NAV_SELECT_SET }-

did not fire (x03FC&x200 == 0 --> FALSE)

 

So I pivoted, the next thing I tried was to set the flag using a bit in one of the "free for general use" offsets... To be honest, I probably should have done this from the start. So I changed the line to the following because offsetStatus-v0.17.ods says A000 is free for general use and has a lot of bits available so I knew I wouldn't run out (not that I have *that many* flags to set):

113=86,8,x0700A000,x00000200 ; set flag 9 (VOR)   -{V: Press=offset dword setbits, offset A000 }-

I also changed my [Keys] condition to:

14=DA000&200 49,8,66502,1 ;vor flag&setting flag 1  -{1: Press=AP_NAV_SELECT_SET }-

 

Unfortunately this didn't work either. So I switch to the other block of "free for general use" offsets.

113=86,8,x070066C0,x00000200 ; set flag 9 (VOR)   -{V: Press=offset dword setbits, offset 66C0 }-

and

14=D66C0 49,8,66502,1 ;vor flag&setting flag 1  -{1: Press=AP_NAV_SELECT_SET }-

At least I am getting the offset logs to show changed in the offset 66C0 now... but that control doesn't seem to actually be changing anything in the simulator.

Wrap-up/questions:
#1 Is A000 working? If so, what did I do wrong? To be clear, when I was trying to use A000 nothing was showing up in the offset logs *and* the condition kept return a value of 0 leading to FALSE

#2 Perhaps I am using the wrong control to set the "active indicator" on the G1000 so that I can see what I'm doing while selecting a course... and perhaps that is listed somewhere in the documentation... but from reading this forum I also know that there may or may be some issues when trying to interact with the G1000... so instead of going through the forums for another several days trying to decipher whether or not that is actually the case and figuring out which control I should be using if it isn't the case... can you please just tell me if there is a control or series of controls to do what I'm looking for?

Thanks in advance, sorry for the long post.

FSUIPC7.ini

Edited May 6, 2021 by CrazyKidJack

[CrazyKidJack]

By the way... I am aware there is a beta version available that natively supports 128 buttons or something. I thought about trying to use that... but figured that if the only difference is the support of 128 buttons... using a beta could possibly make things more difficult for me to troubleshoot. I figured I'd get my stuff working in the stable version, and then try it out in the beta without the need for the HidDemo.lua script.

With that said, if you think the beta will actually add functionality that will help me with my goal here, please let me know.

[CrazyKidJack]

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

[CrazyKidJack]

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

[John Dowson]

4 hours ago, CrazyKidJack said:

To do this, I need to add a condition to a key bind but only offset conditions are available for [Keys]. According to the offsetStatus-v0.17.ods document 03C0 is where the button states are stored for joysticks 0-15.

Yes, but that is for reading. If you check the FSUIPC Offset status document (and column L of the spreadsheet), you will see these offsets are read only and cannot be written to (No in last column):

03C0	64	The current state of the buttons on actively scanned joysticks (local ones, 0 to 15). Each of the 16 DWORDS contain the 32-bit state of the joystick 0-15, in order. Button 0 is the least significant bit (bit 0) in each DWORD.	Ok-Intl	No

So if you want to do that, user a free user offset.
Note also that those offsets are only populated for a joystick if/when there is at least one assignment to that joystick,

4 hours ago, CrazyKidJack said:

#1 Is A000 working?

If you mean the G1000, it has/was reported as mostly not working using standard events/controls, although some things may be working now via lvars/hvars. For full functionality, you should look at the Working Title mod for the G1000 (see https://msfsaddons.com/2020/12/06/the-working-title-g1000-mod-greatly-improves-the-glass-cockpit-in-flight-simulator/)

3 hours ago, CrazyKidJack said:

With that said, if you think the beta will actually add functionality that will help me with my goal here, please let me know.

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.

1 hour ago, CrazyKidJack said:

#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... 🤦‍♂️

You can use the mobiflight events if you like. The events may work in the stock G1000, but still probably better when using the WT mod.

Note also that all MF events are based upon activating hvars or setting lvars, which you can do now directly in FSUIPC7 with the FSUIPC WASM module installed. You can install both WASMs (MF + FSUIPC WASMs) if you like and try both methods to see which works for you.

1 hour ago, CrazyKidJack said:

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?

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.

Update: No OBS at the moment in the WT G1000, and so some people prefer the stock one. See this thread: https://forums.flightsimulator.com/t/release-working-title-g1000-v0-3-updated-to-v0-3-5-on-14-apr/288944/626

[John Dowson]

Sorry, I wasn't going to, but I would also like to comment on this:

7 hours ago, CrazyKidJack said:

Because I know that you always complain when people do not *thoroughly* read the documentation and forums... I

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

7 hours ago, CrazyKidJack said:

 I also know you prefer to help people that have a solid technical understanding, so I wanted to let you know I have over a decade in software development, a Bachelor's in Comp Sci, and am OSCP certified.

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.

John

[John Dowson]

8 hours ago, CrazyKidJack said:

Wrap-up/questions:
#1 Is A000 working? If so, what did I do wrong? To be clear, when I was trying to use A000 nothing was showing up in the offset logs *and* the condition kept return a value of 0 leading to FALSE

Sorry, was confused by this in my previous response (with another support request...). Yes. that offset should be working. I'll check your ini....
Could you also supply a log file please, with only buttons & keys + Events logged. 
 

[John Dowson]

Your offset conditions are not correct:

14=DA000&200 49,8,66502,1 ;vor flag&setting flag 1  -{1: Press=AP_NAV_SELECT_SET }-

You need to add the condition. To check the bit is set, use:
    14=DA000&200!0 49,8,66502,1 

i.e. check the flag is set:
 

Quote

<condition> is one of:
    =value for equality
    !value for inequality
    <value for less than
    >value for greater than
and the “value” here is decimal unless preceded by an x (or X) in which case it is hexadecimal like the offset and mask. FSUIPC will output hexadecimal where a mask is used, otherwise decimal. All values are treated as unsigned.
 

The optional mask facility is useful for testing specific bits, as in the case of the light switches in offset 0D0C or the
radio reception details in offset 3300. For example, the offset condition:
W3300&0040!0
is TRUE when the currently tuned NAV1 is for an ILS.
 

And here:

     14=D66C0 49,8,66502,1 ;vor flag&setting flag 1     -{1: Press=AP_NAV_SELECT_SET }-
As documented, the format is:
  

Quote

The format of the condition is:
    <size><offset><mask><condition>

You have the '<size><offset>', but not the '<mask><condition>'

 

Edited May 6, 2021 by John Dowson
Further info added

[CrazyKidJack]

4 hours ago, John Dowson said:

Yes, but that is for reading. If you check the FSUIPC Offset status document (and column L of the spreadsheet), you will see these offsets are read only and cannot be written to (No in last column):

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:

4 hours ago, John Dowson said:

Note also that those offsets are only populated for a joystick if/when there is at least one assignment to that joystick,

Again in my initial questions I said:

8 hours ago, CrazyKidJack said:

it seems that FSUIPC only updates those offsets if there is an actual device assigned to the joystick whose offset I'm trying to read

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.

 

[CrazyKidJack]

In regards to offset A000 and your comment 

37 minutes ago, John Dowson said:

Sorry, was confused by this in my previous response (with another support request...). Yes. that offset should be working. I'll check your ini....
Could you also supply a log file please, with only buttons & keys + Events logged.

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)

[CrazyKidJack]

5 hours ago, John Dowson said:

8 hours ago, CrazyKidJack said:

With that said, if you think the beta will actually add functionality that will help me with my goal here, please let me know.

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.

5 hours ago, John Dowson said:

Note also that all MF events are based upon activating hvars or setting lvars, which you can do now directly in FSUIPC7 with the FSUIPC WASM module installed. You can install both WASMs (MF + FSUIPC WASMs) if you like and try both methods to see which works for you.

6 hours ago, CrazyKidJack said:

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?

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

[CrazyKidJack]

35 minutes ago, John Dowson said:

Your offset conditions are not correct:

14=DA000&200 49,8,66502,1 ;vor flag&setting flag 1  -{1: Press=AP_NAV_SELECT_SET }-

You need to add the condition. To check the bit is set, use:
    14=DA000&200!0 49,8,66502,1 

i.e. check the flag is set:
 

Quote

<condition> is one of:
    =value for equality
    !value for inequality
    <value for less than
    >value for greater than
and the “value” here is decimal unless preceded by an x (or X) in which case it is hexadecimal like the offset and mask. FSUIPC will output hexadecimal where a mask is used, otherwise decimal. All values are treated as unsigned.
 

The optional mask facility is useful for testing specific bits, as in the case of the light switches in offset 0D0C or the
radio reception details in offset 3300. For example, the offset condition:
W3300&0040!0
is TRUE when the currently tuned NAV1 is for an ILS.
 

Expand  

And here:

     14=D66C0 49,8,66502,1 ;vor flag&setting flag 1     -{1: Press=AP_NAV_SELECT_SET }-
As documented, the format is:
  

Quote

The format of the condition is:
    <size><offset><mask><condition>

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)

[John Dowson]

24 minutes ago, CrazyKidJack said:

5 hours ago, John Dowson said:

Yes, but that is for reading. If you check the FSUIPC Offset status document (and column L of the spreadsheet), you will see these offsets are read only and cannot be written to (No in last column):

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:

5 hours ago, John Dowson said:

Note also that those offsets are only populated for a joystick if/when there is at least one assignment to that joystick,

Again in my initial questions I said:

9 hours ago, CrazyKidJack said:

it seems that FSUIPC only updates those offsets if there is an actual device assigned to the joystick whose offset I'm trying to read

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.

Offset area 03C0 is what FSUIPC maintains for button presses. You can/should  NOT wtite to it, by any means, either directly. You cannot set a button flag on a joystick tat doesn't exist. Please just forget this offset for your issue.

10 minutes ago, CrazyKidJack said:

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)

You don't need the mobiflight wasm if using FSUIUPC, but you can use the mobiflight events instead of the fsuipc facilities if you prefer. You image shows that the FSUIPC WASM module was not installed. Looking at yout log file, it shows this:

Quote

...
Determing Community folder for MS Store install
**** Cannot determine location of UserCfg.opt: Cannot install WASM module ****
...
Updating EXE.XML for MS Store install
**** Cannot determine location of EXE.xml: FSUIPC7 will not start automatically with MSFS ****
 

Do you have an MS Store install or a Steam install? Do you know the location of your MSFS UserCfg.opt file?

[CrazyKidJack]

1 hour ago, John Dowson said:

Sorry, I wasn't going to, but I would also like to comment on this:

8 hours ago, CrazyKidJack said:

Because I know that you always complain when people do not *thoroughly* read the documentation and forums... I

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

8 hours ago, CrazyKidJack said:

 I also know you prefer to help people that have a solid technical understanding, so I wanted to let you know I have over a decade in software development, a Bachelor's in Comp Sci, and am OSCP certified.

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.

[John Dowson]

10 minutes ago, CrazyKidJack said:

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

Yes, It can be omitted, sorry. Please generate a short log as advised.
 

 

31 minutes ago, CrazyKidJack said:

Though be advised that it will be very long if you want me to log events.

It shouldn't be. Turn off other logging, especially IPC Reads/Writes that will make the log huge. Also add offset logging for the offset you are using, 0x66C0, as U32 in hex.
Note you can also use the DontLogThese ini parameter (both in [General] and profile sections) to prevent the spurios logging of many events in various aircraft.

[CrazyKidJack]

13 minutes ago, John Dowson said:

Offset area 03C0 is what FSUIPC maintains for button presses. You can/should  NOT wtite to it, by any means, either directly. You cannot set a button flag on a joystick tat doesn't exist. Please just forget this offset for your issue.

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.

[CrazyKidJack]

18 minutes ago, John Dowson said:

You don't need the mobiflight wasm if using FSUIUPC, but you can use the mobiflight events instead of the fsuipc facilities if you prefer. You image shows that the FSUIPC WASM module was not installed. Looking at yout log file, it shows this:

Quote

...
Determing Community folder for MS Store install
**** Cannot determine location of UserCfg.opt: Cannot install WASM module ****
...
Updating EXE.XML for MS Store install
**** Cannot determine location of EXE.xml: FSUIPC7 will not start automatically with MSFS ****
 

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

[CrazyKidJack]

7 minutes ago, John Dowson said:

Note you can also use the DontLogThese ini parameter (both in [General] and profile sections) to prevent the spurios logging of many events in various aircraft.

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

[John Dowson]

3 minutes ago, CrazyKidJack said:

#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

You do not (and should not) install as admin.

The problem, for your installation, looks to be that your APPDATA environment variable is not set correctly and the installer cannot find your UserCfg.opt file location. Can you check what this is set to? Should be 'C:\Users\jackp\AppData\Roaming'.
 

[CrazyKidJack]

1 minute ago, John Dowson said:

The problem, for your installation, looks to be that your APPDATA environment variable is not set correctly and the installer cannot find your UserCfg.opt file location. Can you check what this is set to? Should be 'C:\Users\jackp\AppData\Roaming'.

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

[John Dowson]

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?

[CrazyKidJack]

1 minute ago, John Dowson said:

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?

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

[John Dowson]

4 minutes ago, CrazyKidJack said:

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

Well, not according to the installer.

1 minute ago, CrazyKidJack said:

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

You should not modify the batch file. Remove that and add the folder C:\Users\jackp\AppData\Roaming\Microsoft Flight Simulator : EXE.xml

If you already have aan EXE.xml file there starting something else, just extract the "<Launch.Addon>....</Launch.Addon>" section that starts FSUIPC7 and add that.

[CrazyKidJack]

14 minutes ago, John Dowson said:

Well, not according to the installer.

It is set correctly. See the screenshot below:

 

Thanks for the EXE.xml file. I copied it in

 

[John Dowson]

14 minutes ago, CrazyKidJack said:

It is set correctly. See the screenshot below:

 

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"

Looks to be a space between your t and a (e.g 'AppDat a' as opposed to 'AppData', but maybe thats just your image/font/my eyes...
Other than that. I have no idea why its not determining the correct location. It works for everyone else...very strange....