John Dowson

Those switches are outside the 32 button limit (0-31) supported by FSUIPC4. To use these, you need to use lua. Please see Hard-programmed how? If you've disabled controllers in FSX it can't be in FSX. If assigned in FSUIPC, you can clear them. However, note that if you have multiple assignments to those switches, they cannot be cleared by using the UI. You need to edit the FSUIPC4.ini file directly to remove the assignments. John

Try changing your[JoyNames] section to the following: Also, please update to the latest FSUIPC6 version, v6.1.4.

No, they are normal and can be ignored. They are messages from the WASM interface (WAPI) produced when trying to close down the connection to the FS gracefully by clearing the simconnect client data areas (CDAs), but the FS (and simconnect connection) is already closed/killed.

Yes, that would have been the issue. However, I'm surprised that there were no FLAPS_INCR or FLAPS_DECR controls logged as well, coming from FSUIPC, which is why I asked for the additional logging. However, if its now working then there is no need, but still strange... John

Yes - you can just rename your FSUIPC5.ini to FSUIPC6.ini (and move to the new installation folder, if changed). However, I don't think you need to upgrade your FSUIPC installation if not intending to update to P3Dv5. There are some new features in FSUIPC6, but the only change to the AS interface in FSUIPC6 is related to P3Dv5.

As I said: Buttons 21 and 22, as your images show - but the ini is a lot more readable for me, not sure why you posted those images.

You need to create the profile for the aircraft BEFORE you create the LvarOffsets section for that profile. Please see the User Guide for information on profiles. Not sure what this means. If its 0, you toggle it and it changes to 1. You toggle it again, and it changes back to 0. What affect this has on the aircraft is up to the aircraft model, which is outside the scope of FSUIPC.

Your log shows FLAPS_UP and FLAPS_DOWN controls being sent, and not FLAPS_INCR and FLAPS_DECR, which explains the issue - parially. Can you check your assignments in MSFS for the buttons you are using for the flaps in the T-45C, as these controls are not coming from FSUIPC. Also, your flaps in/dec are assigned to different buttons in different profiles. Can you please generate a new log for me, the same as before but also activate logging for Buttons & Keys. For the T-45C, your flaps are assigned to your Warthog Throttle.

Please enable logging for Events, produce a short log file where you just start MSFS, load your a/c then operate the flaps (inc + dec), then close down and show me yout FSUIPC7.log and FSUIPC7.ini files.

If you are assigning the axis in FSUIPC7, then yes, you need to remove/delete the axis bindings in MSFS. In fact, if assigning in FSUIPC7, we recommend initially starting with an empty controller profile in MSFS. To do this, simply create a new profile for you controller in MSFS, which will be empty by default. Note however, unlike in P3D, it is fine to mix and match assignments between MSFS and FSUIPC7, so you can keep the MSFS default profile if you like, but make sure to unbind anything you decide to assign in FSUIPC7, otherwise you can get dual and conflicting assignments.

Ah...if using 8 bytes, then the offset needs to be aligned on an 8-byte boundary, e.g. last digit must be 0 or 8. Similarly, if its 4 bytes, ir must be aligned on a 4-byte boundary, eg last digit 0, 4, 8, or C, and similarly for 2 bytes (last digit 0,2,4,6,8,A,C,E). I will add this to the Advanced User guide. Try the following: Then monitor 0x66D0 as a FLT64. John

What has changed, if anything? They should be recognised as buttons. What controller are you using? Have you installed any specific drivers or software for the controller? If so, try uninstalling and let Windows install the default drivers. Also, please show me your FSUIPC7.log, FSUIPC7.ini and FSUIPC.JoyScan.csv files. Also, note that the PAN VIEW axis control for the hat no longer works in FSUIPC7/MSFS. To assign a POV hat switch in FSUIPC7, you need to assign to the key control bindings assigned in MSFS. John

Thanks @forstmeier! Later: but difficult to download. You say via email request, but the links you provide do not offer any assistance - you are just presented with a sign-in dialog when you try to download. Due to this, I suspect there will be little interest, IMHO. Ok, didn't read the page carefully enough...now I see the email request...

Thanks @Paul Henty!

With a line number or something, yes, I could look into it. But I can't do anything with an access violation location in an app that I don't have. As the users that are getting this are developers, they should try with the debug-enabled versions of the WAPI/WAPID (and also your .net client dll) to see if they can get a stack trace, which would be more useful. I can provide the .pdb files if needed (or the WAPI/WAPID repos can be cloned to recompile to generate). I just don't think there is anything I can do at the moment with the info provided. John

Then you need to debug your application and get a stack trace to determine where the error is. You can use the debug versions of the WAPI and WAPID - both are open source and available in github. I cannot debug your application for you. Of course, if there were any issues in the WAPI/WAPID I would fix them, and if its an issue in Paul's client dll then he would look into that. But I do not support C# development - you are really in the wrong forum and should use Paul's .net client forum. If it turns out to be an issue in the WAPI (which I doubt as its been used quote heavily in FSUIPC now for quite a while) then I would take a look. But I can do nothing with an exception report from an app that I don't know. Yes. Trial license available from However, I really don't think its worth purchasing a license just for the lvars-to-offsets functionality. it would be vetter to resolve your issue.

This is normal in MSFS. Many aircraft continually emit such events, and they are different for each a/c. These are just noise really, you can ignore them by using the DontLogThese ini parameter - see P11 of the Advanced User manual. Best used in a profile section, so you can ignore different controls/events for different a/c.

Yes, for the lvars to offsets functionality is for registered versions only. Yes, but that is for the GoFlightClientApp.exe - I have no idea what that is, best to contact GF support for that. Just pass NULL (or 0), bit a random integer. The windows handle is only used to set windows timers. I am thinking of removing this parameter, but its not that big of an issue.

It should just work writing to offsets, if you have populated the offsets with the FSUIPC lvar-to-offsets functionality (registered versions of FSUIPC only). I don't know why it wasn't working for you this way. However, with the WASM I also provide an API (WAPI), which has been integrated into Paul's .net client library. You can also use the WAPI standalone, but if using the .net client dll already you may as well use the interface that that provides as its a proper c# interface, whereas the WAPI (dll) just provides an external C style interface. Anyway, glad you now have it working.

No, that's most probably where your documents are installed. Now you have found that, you can try reading some of it - you should at least read the Installation and Registration guide, which will explain where things are installed. You should also take a look at the User Guide. The installation folder is the folder you selected (or accepted) as the folder to install FSUIPC into. If you do nor know where this is, use the 'Open Folder' button in the FSUIPC Logging tab. The dll needs to go into that folder. John

I just suggested this as a test - it toggles between 0 and 1 (if just toggling the first bit), which would toggle the lvar value, and so also toggle the heading mode (if that worked, but you now say it only works off-> on, not on->off). If it works on->off but not off-on, and the lvar is actually changing value, then its an issue with the aircraft/lvar. If its not working at all from C#, there must be a problem in the code somewhere if the offset isn't being updated. But if you are writing a c# app, especially using Paul Henty's dll, I don't know why you want to use this functionality. Best just to update the lvar directly using the API. See For any support for c#, please use Paul's sub-forum: FSUIPC Client DLL for .NET John

Not really, but check that you have power management disabled on that device. Sounds like its not being recognised by FSUIPC as it isn't for windows. Check your FSUIPC7.log file to see if its recognised when you start FSUIPC7. Better yet, keep the log console open, and you should see when the device is detected, if it isn't detected at start-up. Do you have any saitek software or drivers installed for this device? If so, you could try removing them and let windows install a default driver. I don't know about the trim wheeel, but we recommend not to use saitek drivers or software for most of their kit.

I am slightly confused as you keep going on about c# - are you writing a program to do this or using FSUIPC assignments? This seems to contradict what you said earlier: ? To test its working, use UB, as suggested, in your LvarOffsets section and try setting/clearing the offset A000 using the Offset Byte ToggleBits control, as in the given example in the Advanced User Guide, P43.

Did you install the GoFlight driver, GFDev64.dll, into your FSUIPC6 folder? If not, please do that - its available from www.fsuipc.com.