John Dowson

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

First, you posted in the Announcements sub-forum where it explicitly states 'NOT for support requests'. I have moved your post for you, but please take care to post in the correct forum for support. You mouse macro will currently be sending a 'left single click' (mouse flag/code 3).You can try editing the macro and using a combination of mouse flags, such as 'left button and drag' (9) followed by a 'left release' (13), or maybe add a 'Leave' (16) after the 'Left single click'. Try different combinations to see if anything works. See the Advanced User guide for details on mulriple actions in one macro control and for the mouse flag codes If not, you may have to look into lvars (which I think the A330 provides). As I don't have the A330, you may get more help from A330 users if you post on the Aerosoft forums. As above, you need to play around with the mouse codes and use multi-action macros. There is also a delay control that you can use if you need to have a delay between mouse events (FSUIPC6/7 only I think).

If your EXE.xml file is correct and in the right location, I do not know why this isn't being processed by MSFS. Especially as this previously worked for you in v7.0.4 and there has been no change in this area between the versions.

Do you mean to ask if there is a control/event to control the TERR ON ND switch? For which aircraft? A320 I presume, but it really helps if you can give more information when requesting support.... And do you mean an MSFS control or a MobiFlight one? All MSFS controls are listed in the controls document that you will find in your FSUIPC documents folder. For MobiFlight events, you need to ask MobiFlight, or download the latest release and take a look at their events file. For the A320, there is the lvar BTN_TERRONND_ACTIVE Of course, you can't use that directly using FSUIPC7 at the moment. Lvar support is still a few weeks away, although I hope to be releasing the FSUIPC WASM module for beta testing in the next few days.

Your EXE.xml is now correct. I don't know what created Rick's EXE.xml, but it wasn't FSUIPC. As well as being incomplete (but that may be a paste problem), it should have the CommandLine option (-auto) and needs the <NewConsole> entry. His document Type is also incorrect, as Simconnect rather than Launch. That may also be valid though, I'm not sure.

Yes, that is where it should be. But I had a report in the earlier beta releases where the UserCfg.opt was in the LocalState so I added this as a fallback if it couldn't be found in LocalCache. I can probably remove this now. Ok, understood. I have also had reports of the EXE.xml not working and it turned out to be due to a malformed EXE.xml, with the Type being 'SimConnect' rather than 'Launch', so there is another installer out there that is also writing dodgy EXE.xml files. The FSUIPC installer will create the file (in the correct format) if it doesn't exist, and just add the FSUIPC entry if it does - it will not check the existing content. Yes, thanks.

Thats very interesting! That i the location for Steam installs, it won't work with MS Store installs. But in 8 you say it was working in the LocalState folder - was this with the EXE.xml also in the LocalCache folder then? No - by default, the installer should create the EXE.xml file in the LocalCache folder, but ONLY if that folder also contains a UserCfg.opt file. If not, then it checks the LocalCache folder for the UserCfg.opt file, and if its there instead it will use that. Yes, I think this is the problem. You should report this to the developers of that software. Any updates to the EXE.xml should preserve existing contents. Thanks for the report. John