John Dowson

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

That was the default installation path in earlier versions of the installer - this has now changed. However, when you re-install, the default location will be the previous installation location. Event though that location was the default, the Installation and Registration guide advices that you should change this. It is the folder where the add-on.xml file goes for auto-discovery by P3D. It is better to have the actual installation folder in a different location. But if its all working now, you can just leave things as they are.

Which FSUIPC6 folder - did you move the sound files to your new installation folder (C:\Users\Myname\Documents\Prepar3D v5 Add-ons\FSUIPC6)? If so, then your 3rd attempt would have worked if you had escaped the backslash, i.e. try sound.path("C:\\Users\\Myname\\Documents\\Prepar3D v5 Add-ons\\FSUIPC6") or simply sound.path(".\\") (i.e. the current folder) Then you can just use that path, i.e. sound.path("D:\\Program Files\\Lockheed Martin\\Prepar3D v5\\Sound")

@David BrewsterI've just noticed that you are manually adding the [LuaFiles] section on these instructions. You really shouldn't do this as this is an automatically generated section, which is written by FSUIPC on start-up when it scans your folder for lua files. Probably also why you were getting this section twice in some instances.

Yes, will do.

Thats fine, but as this seems to be an ongoing issue I'd like to know what is causing this and if there is anything I can do to get around this. Another user has reported an interesting observation with the EXE.xml (not starting programs more than one folder deep), but it doesn't apply in your situation - see Can you show me/attach your EXE.xml file again please. If that has the correct format and is in the correct location, I do not understand why MSFS isn't picking it up in your installation.

Thats very interesting...thanks for reporting. Very strange though, and something that should be reported to Asobo.