John Dowson

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.

Your best bet for this is the MobiFlight spreadsheet - see https://docs.google.com/spreadsheets/d/1jTXlcHaJWx0B7TB63Pmma7bKwpxsxXJO6EJ3ECt7zpc/edit#gid=11806850

You have defined the offset to hold SD, a signed double-word of 4 bytes, so you should write it as 4 bytes. But, the size/type of the offset should match that of the lvar, which is a flag (ie. 1 or 0), so define it as UB, an unsigned byte. And write either 0 or 1 to it for off/on.

No, that for this - it does say to use the key code following (or after may be better) the letter 'K'.

Excel can read/write ODS files. I don't have an Excel license, and I generally prefer to use/support Open Software rather than payware. And I'm a unix/linux/ultrix/maxOS guy really - only been developing in Windows for 3 years now, since I rook over FSUIPC dev & support from Pete. Note that this is a temporary document, to be used as a supplement to the Offset Status pdf. I am planning on merging them to generate a new document when I get time, hopefully this month.... No, I said it was contained in the zip archive you downloaded, i.e. in the FSUIPC7.zip or Install_FSUIPC7.zip, depending upon where you downloaded it from. Sorry about the confusion!

No problem - I should have found that User Contribution post earlier to have saved us both some time!

I attached the spreadsheet not an archive! Its a .ods file - an Open Document Spreadsheet. You can open it with OpenOffice (Calc) or Excel.

I attached it in my previous comment! The spreadsheet is included in the zip file, it is not installed into your FSUIPC7 documents folder.

Sorry, I don't understand... Look at that spreadsheet on lines 1545 (0x66C0) and 1589 (0xA000), both documented as 'Free for general use'. I've attached it, in-case you are looking at the wrong file. John offsetStatus-v0.25.ods

I think they work for some aircraft in FSUIPC4 but not all. You will need to define the module as: Module="PMDG_MD11.DLL" This post may help - in fact, this already includes mouse macros for the lights in the MD11, so you may want to use this: John

I meant FSUIPC Mouse-macros, i.e. macros that emulate mouse actions in the UI - see P40 of the Advanced User manual. If you cannot find any events/controls that work, and writing to the lvars doesn't work, then try mouse macros. Do the logging first, as it is also not guaranteed that mouse macros will work in FSUIPC4 as it depends on how the a/c is implemented. Or are you saying that they don't work for the MD11?

If the value changes but the lights are not activating, I suspect that they are read-only (or non-active) lvars. Do the standard light controls not work (or the light offsets)? Have you tried logging Evenbts and operating the lights from the UI, to see what, if any, events are logged? If any are logged, you can use/assign to those. Many PMDG aircraft also come with there own SDK which include custom controls for such things, but I don't know if this is available for the MD11 - please check. If not, you could try using Mouse Macros. May also be worth checking on the PMDG forums as well. Btw, which FS and version of FSUIPC are you using?

It is giving you the error: *** LUA Error: C:\Users\Stu\Documents\Prepar3D v5 Add-ons\FSUIPC6\autorecord.lua:16: 'end' expected (to close 'function' at line 3) near '<eof>' This is a problem in the script that Pete posted: else if agl < 450 and aglhigh then should be elseif agl < 450 and aglhigh then With the space, it expects another 'end'. I will correct.

Did you try logging the lvars to see if the values changed? Maybe also worth logging buttons & keys to see what is happening. Which aircraft are you using? It is also possible that the lvars are read-only, and you need to use another method to control.

Ah, sorry - they are assigned to different buttons - 22 and 23. Try using two macro files (as really an lvar should only appear once in a macro file). Use the set control in both, but with a parameter of 1 to turn on, and 0 to turn off. I'm not sure of the behaviour if using the same lvar multiple times, even if they have separate actions. Alternatively, try logging the lvar values once you toggle or set - do they change?

So now you have it set to both toggle the three lights (assignments 6,7,8), and then set them all to off (using the set control with a parameter of 0 on assignments 9,10,11). Try removing the last 3 assignments (the set ones) and just use the toggle controls.

Maybe try running FSUIPC? You should see something in your log - here's mine: John

If writing as SD (signed Double), you need to read as a FLT32. Alternatively, skip the size: 13=A32NX_HYD_BRAKE_ALTN_ACC_PRESS=0x66D5 and read as a FLT64. S32 is a signed 4 byte value and will be an int, SIF32 is a 16bit/2byte integer + the fractional part in 16bits/2bytes. (see P13 and P43 of Advanced User Guide)