John Dowson

Sure. I'll generate one for you and post it here, but probably tomorrow or Monday now (as the time-limited key generation is still only working on my win7 system which is currently not available...). John

Please post your Installation log file (InstallFSUIPC7.log), which should be in your installation folder. The Installation guide, included in the zip AND in your FSUIPC documents folder, explains where things are installed and how the installer works. Documents are installed under your Windows Documents folder in a sub-folder called FSUIPC7. If it cannot install there for any reason (usually permissions), it should fall-back to install in a subfolder of your FSUIPC7 installation folder. But, its the install log which will tell me what is installed where, so please show me that.

Maybe remove it for now and test without. The logging shows that the presses aren't being registered for some reason. As well as testing without your vjoy devices, you could also uncomment the logging of the discards change: to Also, the 'button = false' line is in the wrong place really - should be: So please test with that and without vjoy and report back. I haven't used vjoy for quite a while now so I'll take a look and see if thats interfering (which it most probably is as its also using the virtual button offsets....). John

No, you don't need to change that as the Alpha and Bravo are different devices (have different Product Id). That is only used if you have two devices that are the same, i.e. same vendor and product ids. I'm not sure what you issue is. Someone else recently reported the same problem but with the Alpha. The strange thing is that the logging is showing the same entry each time: 46219 LUA.2: BRAVO Buttons= 8E040000 2AAA However, the script should only log when this has changed: Could you add the following line to your bravo script please (in bold below): Also, add offset logging for 3344 as type U32 in hex (from the FSUIPC7 log menu). Then generate another FSUIPC7.log file and show me that. I see you are also using two vjoy devices. They may also be using the same offset range (Alpha uses 4 bytes from 0x3340, Bravo 4 bytes from0x3344). Thanks, John

Sorry, was getting confused and was referring to FSUIPC7. There is no exe for FSUIPC6. I have PM'ed you a key file. Please place that in your FSUIPC6 installation folder.

I have had a few reports of the installer not creating the key file. Usually its a permissions issue and installing in a different folder solves the issue, although you can also create the key file manually. It is recommended to install FSUIPC6 outside of your P3D add-ons folder if possible, and just use that location for your add-on.xml file.

enter '3340'. Please see the User guide

Yes, sorry - you did say this in your original support request. I have checked your registration details here and they are good. Can you run FSUIPC7 by double-clicking the FSUIPC7.exe window? Or do you get an error? If so, it is probably due to your VC++ redistributables being corrupt. You need to uninstall any of the VC++ redistributables from 2015, 2017 & 2018, then re-install the combined package (both x64 an x86) from https://support.microsoft.com/en-in/help/2977003/the-latest-supported-visual-c-downloads

Ok. Then I think that the wnd window maybe getting the focus back (and so keyboard input events) when it is being updated. No keyboard support has been added to the wnd window, so any keyboard input relies on basic windows functionality. Keyboard input certainly isn't forwarded to the FS, but I'm not sure (without investigating) if the input would fall back to FSUIPC, but probably not (due to your issue). I'm sorry, but this is something that I will need to look into. I'm very bust at the moment, but this is now on my list to investigate. I will get back to you once I have had time to look at this in more detail. Hopefully later next week. John

Please read the Installation and Registration document that is included in the zip. It will rell you where things are installed. All the FSUIPC7 documentation is installed in a FSUIPC7 folder under your windows Documents folder. Find them, and at leat take a look at the User Guide. Transponder mode (or state) is in offset 0x0B46 and has been reported as working for both read and write, with values 0 = Off, 1 = Standby, 2 = Test, 3 = On, 4 = Alt, 5 = Ground (see the additional offsets document spreadsheet for details) To use this, assign to the 'Offset Byte Set' control with the appropriate value you want to use, or the cycle incr/decr controls with the appropriate parameters (depending on how you want to operate). See the Advanced User guide for further details. John PS there was/is also a README.txt in the zip you downloaded - did you not see that?

Thats because you are logging lua plugins separately (one of your Log options), so its logged in a separate file - which you also included! Do you mean that the text in the wnd window is flashing? Strange....or do you mean the usual windows flashing that occurs when there is new input? Did you try, as I have asked, giving the window focus back to the FS or FSUIPC before activating the button? If not, please do so and let me know the result. But also, looking at your ini, you don't have any assignments at all in FSUIPC. So are your assignments in MSFS? If so, MSFS MUST have the focus to receive these. So, as I have said, please try giving the focus back to MSFS BEFORE you issue a command, to see if that works. The 'keyboardFocus=Yes' will not affect assignments in MSFS - you need to assign in FSUIPC for that to take affect. It seems to me that your problem is that you have assigned in MSFS, which means that MSFS must have the focus to receive the keyboard input, and when you start the lua script it creates a new window which, by default, accepts the keyboard input but does not handle it. But I need you to do the tests previously mentioned to confirm this. I could. maybe, look into either changing input focus back to the previous window once a wnd call creates a window, or look into forwarding keyboard events from the wnd window back to MSFS or FSUIPC so they get handled. But, first, I need to understand if this is what the actual issue is, so please follow my instructions and report back. John

No, that is not possible. Please see the Advanced User guide for the format of the button assignments.

There are many known issues with the G1000 - check out the Asobo forums. Those offsets just hold the values for the associated sim variables whose values FSUIPC7 receives from the sim via SimConnect. I'm not sure what you can try - maybe someone else who uses the G1000 can help. I know there are various G1000 mods out there that improve on the stock functionality, but I don't know if they correct issues such as this.

Some add-on aircraft (eg. FSLabs A320) re-purpose the ROTOR BRAKE control with parameters that look like custom control numbers, instead of using custom controls directly, but I don't think this applies to the PMDG aircraft. There is a guide for using custom controls with PMDG aircraft here: https://www.myhomecockpit.de/index.php/en/?view=article&id=56

First, if you don't have a Honeycomb Bravo, you can remove that lua script and the entry in your FSUIPC7.ini under [Auto] that starts that script. You don't need it. Can you activate offset logging in FSUIPC for 0x3340 as U32 in hex. Load you aircraft and produce another log file where you have activated those buttons. Also please make sure that you exit FSUIPC7 before you attach the log, so its closed and I can see the full log.

Did you then click the Register button? Of so, you would have seen a pop-up message telling you if your registration was successful or not. What did you see?

As I said, you can check if this is the issue by giving focus back to the main FS window or FSUIPC after the wnd window has been created. Did you try this? After testing as mentioned above (and in my first post) to confirm this is the issue, you can try adding that to your [Buttons] section (and any profile [Buttons.xxxx] sections) to see if that resolves your issue.

Looks ok to me on an initial look - I don't think that it could be blocking commands. But what do you mean by this - what sort of commands are they? As the wnd library creates a separate window, if your commands are key presses, they will go to the window you create in the script if it has the focus. Could that be the issue? Check by giving focus back to the main FS window. Do you have ' KeyboardFocus=Yes' set in your [Buttons] section? I've finished for the evening now - I'll take a look in more detail tomorrow. John

No, that wouldn't as according to the Advanced User guide: so should be: 217=B66D0!3 P258,23,Cx010066D0,x04 217=B66D0!3 P258,23,Cx010066D0,x04 217=B66D0!3 P258,23,Cx010066D0,x04

You are using an unlicensed/unregistered version of FSUIPC. The lua infrastructure is only available for registered versions.

But FSUIPC7 already comes with a batch file - MSFS.bat. As already discussed, if the EXE.xml doesn't work you can re-enable the old code there to start FSUIPC7 AND MSFS. You can also edit to add other programs if you wish. Of course, you can create your own, as shown in that video, if you prefer. However, it would be better to launch via the EXE.xml if possible.

But why? Its working for you with Lua KillAll. And if others have this issue, they can also try your work-around. It looks like one of those scripts is preventing shutdown and not being killed when you kill your ipcReady.lua or when FSUIPC terminates, but is being killed by Lua KillAll. which is strange. I have made a note of this and will look into it at some point, when I have time. But, as there is a work-around, it is not urgent and so may take a while. It could be a problem in FSUIPC, but it also could be a problem with one of the scripts. You could do some further tests to help narrow it down. Try with just starting one script in your ipsReady.lua to see if that works, then add them one at a time to see if you can find a culprit script. Then, to confirm it is that script, try with all scripts apart from that one (to confirm it works), then try with just that one, to confirm it has stopped working. Then post the script. There may be more than one culprit script, but this would help to determine if it is an issue with particular scripts or not.

FSUIPC7 does not detect the print screen button. If it did, what would you assign it to? The 'Print Screen' hot-key is a windows function, nothing to do with FSUIPC or MSFS. Later: sorry, you want to assign a button to the print-screen key.... I'm not sure if this would work, but you could try first assigning the button to any other key, and then edit your FSUIPC7.ini file and change the key code to the print-screen key code (44) - see the Advanced User manual for the key assignment definitions. Then reload the ini.

Thats interesting! Is this a general way to set lvars using MobiFlight events? Or does the hvar (in this case H:A320_Neo_MFD_BTN_TERRONND_1) also have to exist? I'm not sure on the relationship between lvars and hvars... Also, do you have a list of available hvars, for the A320 or any other aircraft?

For the Airbus, if you can't get it working with the mouse macros, try lvars. See https://forum.aerosoft.com/index.php?/topic/159679-airbus-lvars/ John