John Dowson

There has been a few posts on the MobiGlight WASM module recently, most recently here: Looks very interesting. I'm going to look into this next week to understand this better and see what I can do in FSUIPC7. I'll let you know - please be patient. John

I've heard this mentioned a few times now, most recently here: Thanks for the link. I will look into this shortly to see what I can do. John

Hi Norman, Looks like a Linda issue, so you should post in the Linda forums: https://www.avsim.com/forums/forum/429-linda-support/ John

I'm not sure of your issue.... You can use mouse macros however you wish, but its usual to assign them to a button or switch. You can also activate them via a key press ot from a lua script if you so wish. As for the control of the QW787, I think you are probably better off asking over on their forums. I don;t have this aircraft, and so not sure what they expose i.e. lvars) to control. Maybe try here: http://qwsim.flight1.net/forums/lvar_topic12252.html John

No. But you log is very strange: This shows that closed and re-connected a few times (connected after 8s, disconnected at 11sm connected at 93s then disconnected again at 134s, reconnecting again at 2096seconds...MSFS closed 26s later), but was closed for the majority of your session! FSUIPC7 will change the focus to to MSFS only to send a key press. Do you have key press assignments to buttons on repeat by any chance? Could you enable logging for events and buttons and produce a log file when you have your issue. Attach that, together with your FSUIPC7.ini file and I'll take a look. John

Not without further information. Could you activate event logging and produce a log file showing your problem (complete please - don't start a new log file!). Also increase or decrease using the mouse afterwards, to see hat that logs. Attach that log file, together with your .ini file and I'll take a look. John

First, please update to v7.0.4. Only the latest version is supported. Not! FSUIPC7 will try to assign (by default) ALT-F as a hot-key to open the FSUIPC7 main window. You can change or disable this - please see the user guide for details. Other than that, FSUIPC7 will request key input events for (almost) all keys, but requests them unmasked and so should not affect any other SimConnect clients, let alone other windows applications! And FSUIPC7 still works as expected? Is there any difference in the FSUIPC7 logs when starting your app before or after FSUIPC7? John

You need to know the event ids and assign them as custom events. There is an 'add-on custom events' facility (see p36 of Advanced User Guide), but the event names you mention don't contain a period as mentioned in the documentation. I haven't used that facility up to now, maybe @Pete Dowson can clarify.

@David Brewster Thanks for these detailed instructions. The scripts are already available in the User Contributions sub-forum, but without detailed usage instructions. I have moved your post to the FAQ sub-forum, and will link to this in the script posts. John

Is this after the latest Asobo update? I've not looked at this yet, but I'll take a look shortly... John

What has changed? Can you try with the vanilla A320Neo to see if it works there, and if so you need to report to FBW. I don't have much time today but I can check tomorrow. John

Yes, but I'll be releasing a new version soon with this fixed. I was hoping to release later today but it will more likely be tomorrow.

Have you verified the script is running? Did you add it to the [Auto] section of your FSUIPC ini file? Please attach your FSUIPC7.ini and FSUIPC7.log files and I'll take a look. John

First, you posted in the FAQ section where it explicitly says NOT for support requests. I have moved your post for you this time, but please take care to post in the correct forum for any future support requests. There are so many posts on this topic now. There are dedicated lua scripts for the Honeycomb Alpha and Bravo, please see If using the Bravo, to control the LEDs you can also use this: John

First, you are saying you are using offset 0x66D0, but your script is actually using 0x66E0 - just FYI. But the main problem is that you have wrapped the calls in a function - what is calling the function? If you are assigning the script to a button press, then you don't need the function, i.e. just ipc.macro("RJ85LNAVPress: press") ipc.writeSW(0x66E0,1) Otherwise, you could add an event.button() call to call the button on a button press - this would be more efficient as the script would not have to be recompiled each time it was executed. You are also setting this value as a signed word (SW). Thats fine, but if it is only holding 0/1, you could use an unsigned byte. John

This is a very general question that depends on many things (e.g. your devices!) that I can't really answer - its up to you! I suggest you check the Aerosoft forums, as there are many posts there on how to use/configure the Airbuses with FSUIPC... If you have any specific questions then I can look into it, but you really need to do the initial work yourself - I don't own or use those add-on aircraft. John

Hi Cristian, I suspect that that is controlled internally by the gauge, so would need access to lvars to control, which aren't available in FSUIPC7 yet. Is there any way to control this via MSFS assignments? If not, I'm afraid that this won't be possible via FSUIPC7 at the moment. John

Note that these scripts are no longer needed with FSUIPC6/7 as FSUIPC recognises up to 128 buttons natively (without the need for a lua plugin) since around May/June 2021 (FSuIPC6 version 7.1.0 and FSUIPC6 version 6.1.0). To assign to the buttons on the Honeycomb Bravo and Alpha controls, you can use the attached lua scripts. They need to be placed in your FSUIPC installation folder, and an entry added under the [Auto] section of your FSUIPC ini file to start the lua (or luas) automatically. These have kindly been adapted from the HidDemo.lua by @spokes2112: hidAlphaButtons.luahidBravoButtons.lua ALPHA buttons greater than 32 will be on joystick #64 with 32 additional buttons provided. (0x3340) BRAVO buttons greater than 32 will be on joystick #65 with 32 additional buttons provided. (0x3344) If you require further details, please see this FAQ entry here: John

It should be possible to adapt your script for MSFS. There are issues with the SimConnect_Text function in the MSFS SDK, so the lua functions that use these will also have issues. You can use (or adapt) this user contribution to request user keyboard input in MSFS: John

Can you please attach your screenshot, or, better still, just describe your issue. I cannot access that link. Presumably you pressed the Register button, no? If not, please re-install and do that. If you did press the Register button, and it says that your registration wasn't valid, then please ignore and try and start FSUIPC7 to see if it runs. If it runs ok, then let me know your order number and date of purchase and I will check here. If it doesn't run, then its almost certainly due to your VC redistributables either being corrupt or not installed. If that's the case, then you need to uninstall and re-install the VC redistributables. There have been MANY posts on this issue already (and also mentioned in the included README.txt, although it doesn't say that this causes a registration failure, but it has been known to do this in a small number of cases). If you have any difficulties, search this forum for similar issues where you will find further details. John

I'm not sure what you mean by 'offset tutorials'. It really depends upon what you want to do. The offset area is just a memory area that holds data from the FS that can be read, and also allows certain areas to be written to to update the FS. There is comprehensive documentation included in your windows documents FSUIPC7 folder. Please also see the User Contributions and FAQ section of this forum, which can give you an idea of the sort of things that people are doing with FSUIPC. John

I've not heard/read of this bug, and I have never found a need to do that, so I guess not.

As you know what causes this issue, you just need to eliminate that. i.e this: Why is it doing this? Where is this assigned? Maybe you can attach your FSUIPC7.ini file, and and Fsuipc7.log file generated with event logging activated and showing your issue. Also check that you have an empty profile assigned in MSFS, or at least that you don't have assignments in both FSUipc and MSFS for the same buttons/axes. John

Ok, then thats the exact issue in the thread (link) I posted, distinct from this issue.

Seems there is something funny happening, as your Bodnar cards have the same product and vendor ids, but different serial numbers. When both are connected, both GUIDs are attached to one card: However, they seem to be acquired ok with the correct GUIDs So assignments should have gone to the correct device. You seem to have yoke assignments to both your E (yoke) and C (2nd TQ6) devices): eg That also has a throttle assignment to your E device (yoke) on axis Z.... So, it seems that the assignments to the two bodnar devices are being confused somehow. I'm not sure whats happening, or how you got into this situation. I'll take a look and discuss with Pete, but this will take a while (i.e. next week sometime). You could try the following (make a backup copy of your ini first): manually edit your FSUIPC4.ini, and change any assignments that you know are for your yoke (i.e. that have the letter 'C') to a letter 'E'. And also check your assignments to the 'E' device, and change those to 'C' if they're for the 2nd TQ6. Then repeat your tests. It would be interesting to know if the corrected devices and axes are recognised with those changes. John