John Dowson

Then please read again:

The SDK only provides functions to read/write to the offset area. You can get/set lvars using offset 0x0D70. Check the FSUIPC Offset Status document for details.

No. A standalone program cannot talk to the Panels.dll, which is running inside of P3D. You can only do this if your program is also a dll, running as a plugin to P3D. If your program is standalone, you should use the FSUIPC SDK and request the lvar via the provided offsets.

The FSUIPC SDK. There is no access to lvars from the P3D SDK. Otherwise, you can use the Panels.dll directly, as you do in the posted code fragment. This is what FSUIPC uses internally. You would need to run your program as a dll plugin to P3D to get access to the Panels.dll though.

If your software is written in C/C++ then you should look at the SDK, not lua, or Paul's DLL if using managed code / .net. Lua is just for FSUIPC plugins, as explained in the link that Pete posted.

@Matthew Twomey Could you try this build. This will accept the wild card '*' for the button number of the IgnoreThese parameter, and should also ignore the POV buttons 31-39 when specified. Its has also been rebuilt against the latest SimConnect version (0.6.0.0) released yesterday: FSUIPC7.exe

Buttons 31-39 are the POV compass points, and can be treated as axis or as a set of buttons. They should be ignored as buttons when specified though, so I'll look into this.

It is known that many of the events for AP systems, especially the G1000, are not currently working. I know there are some mods available for the G1000 (see https://forums.flightsimulator.com/t/update-g1000-improved-v2/262603/146), but I doubt these address the SDK side, although I haven't tried them yet. No, not necessarily. It could be that the events aren't hooked-up to the model yet.

I'll definitely consider this when I get around to writing the installer for FSUIPC7, but the control for this may come later, we'll see....

Are the buttons on your saitek gear recognised by FSUIPC? If so, you can use the controls provided as Thomas says. However, usually saitek gear are not standard HID devices and are not recognised by FSUIPC and you need additional software/drivers to use them. Not the saitek drivers/software though, as these cause issues. You should look into using either SPAD (free) or SPAD.next (payware).

You could try the SDK documentation where you will find a list of event ids (under variable lists) broken down by various categories (Aircraft engine, Aircraft Avionics, etc). However, be aware that many of these are not yet connected/working, so activating a function in the UI doesn't fire the event (i.e. nothing logged) and sending the event has no affect. In other cases, you can see the event when activated, but sending the event has no affect. This is a known issue and things should (hopefully) improve in this area in successive SimConnect /SDK updates. There are other posts in this forum on the Avionics Master. Try using Avionics Master Set, possibly in combination with an offset conditional check on offset 0x02E80 (if using same button/key as a toggle)..

Thanks Paul! I'll add this to the FSUIPC6 installer at some point as another optional 'extra'. It might also be worth adding functionality directly in FSUIPC to start/stop the http server (when installed), but that can come later. Btw, can you check the link address - I get a 'This site can’t be reached' message!

@Matthew Twomey Yes, I understand your issue. What I will do as a "quick fix" will be to allow you to specify a wild card for the IngoreThese ini parameter, e.g. [Buttons] IgnoreThese=A.* However, when this is read and later the ini file re-written, it will expand to reference buttons 0-31 (as you now have it). I will also add an 'Ignore Button' button to the buttons & switches assignments dialog that will function in a similar way to the 'Ignore Axis' button in the axis assignments dialog, which will ignore specific buttons as long as the assignments dialog remains open. I'll add this to my 'todo' list, so will take longer to implement as this is quite minor as there is already a work-around (and my 'todo' list is already pretty large!).

This is a known problem with the throttle axis (and maybe prop axis as well) and seems to apply to all aircraft. There are other FSUIPC support requests on this issue and I have reported to Asobo but have not received a response as of yet.

It can do, but also note that updating an offset can also result in a control being sent (Ok-SimE) rather than the simvar being directly updated (Ok-SimC). But really, as an end user, you don't need to know how its implemented. Just use the controls, but if you cannot find a suitable control then try the offsets. It is preferable to use a control/event if available. Yes, it would be nice but not that straightforward. For example, a control may work with one aircraft but not with another. And if a control doesn't work, there is not much we can do about it in FSUIPC - it needs to be reported and fixed in MSFS/by Asobo. Why would you need to send both? You could overload your control to send both (by editing the ini), but then you should add an offset condition (using 0x0609) to only send the required control depending upon the aircraft type. You can repeat each control or not for each of the assignments, depending upon what works. Alternatively, you can use profiles to send the correct control for that aircraft type. It depends on the script. If its using an event, it will run all the time (or until killed), waiting for the event and then calling the appropriate function when received. Some scripts may also run in an infinite loop, and others may simply run and terminate. Note that if they run and terminate, the next time they are called they will be recompiled and ran in a new thread, which adds quite a bit of overhead. Using event based scripts is more efficient. So, its a lot more efficient to have a lua script running (usually from the [Auto] section of the in) and waiting for a button or key press event, rather than assigning the button or key press event to activate the lua.

This seems to be a common misunderstanding. The offset status documents is for the read/write functionality offered by FSUIPC's offsets. The data in the offsets table is populated (mainly) from simulator variables (aka simvars), not controls or events. Where an offset is related to a simvar, this is shown in the offset status document in the third column (column G). Offsets (or simulator variables) can sometimes be updated directly on user request, and others are updated automatically by the model or on sim events (or controls). The read/write status of each offset is also given in the offset status document, together with its previous status in other FSUIPC versions (where it also indicates if the variable is updated by an event 'Ok-SimE' or by directly updating the simvar 'Ok-SimC'). Currently I have not provided a list of the available controls, which comprises of those provided by the SDK together with other controls added by FSUIPC. For the former list, you can use the 2016 list of FSX controls provided in previous versions (and attached to this comment). The FSUIPC added controls are defined in the Advanced User manual, section Additional “FS” Controls added by FSUIP.The 2016 List of FSX and P3D Controls.pdf You could try with Magneto Set, with a parameter of 1 on your button/key press, and a value of 0 on release. But I think that may also time out after a second or two. You could also try with repeat on. However, I think that this is probably how the starters are implemented, with it switching back from start automatically after a short period (or the engine is started).

Btw, is the CTD in MSFS? As FSUIPC7 is a separate process/exe, it shouldn't crash the sim. However, it has been reported that this can sometimes happen when loading a flight with FSUIPC7 (due to known issues with the SimConnect load/save functions) so this should be avoided.

To start with, could you attach your FSUIPC7.log (from after you have experienced the CTD) and also your FSUIPC7.ini file please, both files are located in your FSUIPC7 installation folder. Can you also check the windows event viewer, and see if there is a crash log available there. If so, please paste its contents as well.

@ankh21 Could you try the attached FSUIPC7 build. In this build, I have added a new Control 'Throttle Reverse Thrust Toggle', and a corresponding read/write offset for this at 0x0B4A (1 Byte). To use this new 'throttle reverser' function, you need to assign your throttle axis in FSUIPC to 'Send direct to FSUIPC calibration' and to the Throttle1/2/3/4 controls. Then calibrate with no reverse zone. If you then assign a button/switch/key to this new toggle control (or to toggle offset 0x0B4A), toggling this control will switch the axis between 0-full forward thrust and 0-full reverse thrust, but only when the aircraft is on the ground. FSUIPC7.exe

But your ini shows that you have no axes assignments in FSUIPC:

@katoema Sorry, but I don't understand. Do you have an issue? If so, what is it? I thought you were posting to help with the reverse throttle axis question....

? This was related to registering your WideFS license with FSUIPC7.

Have you tried using the IgnoreThese ini parameter? From the Advanced User Manual:

Btw, FSUIPC needs to run on the same machine as the flight simulator. If you are running client software on a pi to talk to FSUIPC, you would need to install WideClient on the pi to achieve this. And for WideClient to run on the pi, it would need to be running Windows 7 or later.

You can try it. The offset facilities are available in the free/unregistered version (although there is currently a free time-limited full license provided with FSUIPC7-Beta). As well as the offset status document mentioned by Thomas (latest version is 0.7 and is included in the downloadable zip), you can take a look at the documentation for FSUIPC5 or 6, and maybe also the SDK. Documentation here: FSUIPC6_Documentation, SDK here: FSUIPC SDK.