John Dowson

The post I referenced just shows you how to calculate the control number and parameter to use the custom controls for PMDG aircraft. Once you have determine what control and parameter to use, you can either assign this to the button switch (FSUIPC registered only) or write this to offset 0x3110. FSUIPC only recognises HID joystick type devices for direct assignment, but other non-joystick type devices can be used via lua. Both of these facilities are for the registered version only. I cannot advise if FSUIPC would recognise your hardware. Many users/home cockpit builders use MobiFlight in conjunction with FSUIPC (unregistered) to control via FSUIPC offsets, so you could possibly look into that. John

Hi Max, I asked Pete about this, as he also uses the Prosim 738 this is his reply: John

All PMDG specific offsets are read-only. To control PMDG aircraft, you need to use the PMDG custom controls. You can use these in the free version by using the general control offset at 0x3110. See the following first part of the following topic on how to control PMDG aircraft using the custom controls - the latter part of the topic describes how to assign the controls to buttons/switches/keys, but you can also write the control number to offset 0x3110: John

Is it FSUIPC7 that is crashing, or MSFS? If MSFS crashes, FSUIPC7 will exit. Please check your FSUIPC7.log file (you can post it here) to determine if it is exiting or crashing. Also, check the windows event viewer, there should be crash events there - if they are for MSFS you need to report to Asobo/MSFS. If there are crash events for FSUIPC7, then post them here. Note there is also an issue with FSUIPC7 when running on Windows 11, where it thinks MSFS has exited and so closes, but MSFS is still running. If this is your issue, check the README.txt (in the FSUIPC7 zip file you downloaded) which will tell you how to resolve this particular issue. John

That is why you should attach your scripts... I'm not going to laugh, i'm not even going to look... I haven't got time to look at such a lengthy lua script. I am trying to help you recognise key presses/releases, nor debug such a lengthy script... You keep saying that you are having issues with keypresses or releases not being recognised, so why don't you just try a simple script to test this, as I keep asking. Try running the following lua script and tell me what you see logged when you press the k, l and m keys: function keyUpDown(keycode, shifts, downup) if downup == 1 then ipc.log(keycode .. "Key Down") elseif downup == 0 then ipc.log(keycode .. "Key Up") end end k = 0x4B -- k key l = 0x4C -- l key m = 0x4D -- m key event.key(k,0,1,"keyUpDown") event.key(l,0,2,"keyUpDown") event.key(m,0,3,"keyUpDown") When you run that and then press: - the k key, you should see the key down logged - the l key, you should see the key up logged - the m key, you should see both the key down and the key up logged If that is working for you then your issues is with your script. Try lua debug logging to see what is going on.

Sorry - I made a change to allow keyboard input to be recognised from the FSUIPC main window (mainly for use on a client PC) and this has also disabled the main windows scrolling ability. I will correct this in the next release. For the time being, look in the log (you can use Log -> Open Console) as lvars/hvars should also be listed there. John

That is what Button & Key logging does. No. The function is event.key, not event.keypress, and why are you using # for parameters and an empty string for the function name? Also, the downup paremeter you are using is '2', which is for releases only. Please see the documentation, and always attach your lua files so that I can see EXACTLY what they are doing, rather than posting extracts. Why don't you just try a simple test like the one I provided? Just replace k with the keycode of the key you want to use (or define and set it before it is used. Why are you doing this anyway? You can assign to key presses and releases in the FSUIPC UI. You only need to use lua if you want to do something not possible with standard assignments. Also, if using lua, make sure the lua script is running. For event based luas, you would usually start them from an [Auto] pr [Auto.ccc] profile section, but for development purposes toy may want to assign a button or key to start/kill the lua script. John

Do you mean MSFS profiles? MFS should start with the previous profile you used for each controller. If its not doing that, I don't know why and can't really advise - maybe ask on the Asobo/MSFS forums. John

If it registers correctly on the first computer, then it should also register on the 2nd computer. If it fails, it may be due to the VC++ redistributabes being out-of-date or not installed. First, uninstall any of the 2015, 2017 or 2019 VC++ redistributables from the Windows App management panel, and then re-installed the latest combined redistributable packages from here: https://docs.microsoft.com/en-US/cpp/windows/latest-supported-vc-redist?view=msvc-170. Best to install both x64 and x86 packages. And please give your posts an appropriate title.

I think you may be using an older version of FSUIPC6, the latest is v6.1.8, although the offset status document is valid for 6.1.6 and later. I remember I did recently document a few offsets as free in one version, but on reflection I decided that they were best kept as reserved for the time being until I look further into why they are reserved. Most of these were allocated to 3rd party apps many years ago (before my time!), but some reserved areas are also used internally.

Please note that these scripts are no longer required with FSUIPC6 and FSUIPC7 as they both now support devices with up to 128 buttons. These scripts are still needed if using FSUIC4 or FSUIPC5. John

Ok, was just about to reply... Still, several things you should know: - this post is quite old and shouldn't be followed! You do not need the lua scripts for the Alpha and Bravo anymore, not since FSUIPC v7.1.0 released in May 2021. Up to 128 buttons are now recognised natively, so you should remove those lua scripts and assign to the physical button numbers - you are using an old version of FSUIPC. The latest (and only supported) version is v7.3.2 - please update - do not activate so much logging! Only activate logging needed for your issue, which would have been Events and Buttons & Keys. You very rarely need to activate logging for IPC reads/writes especially... - the best resource to use, especially for beginners, is the MobiFlight HubHob resource (https://hubhop.mobiflight.com/). As you are using the Asobo C172, if you search that preset list you would see the following presets for Landing lights: C_172_LIGHTS_LANDING_ON C_172_LIGHTS_LANDING_OFF. You can assign to these in FSUIPC7 using Preset: C 172 Lights Landing On and Preset: C 172 Lights Landing Off. John

You need the paid version as you need the assignment functionality. Please try with the trial license (available in a topic at the top of this sub-forum) before you purchase. John

That offset area is also reserved, for the sound playing interface. You should use offsets starting from 0x66C0 (64 bytes), 0x7C40 (704 bytes) or 0xA000 (512 bytes). John

Ok, then that complicates things quite a bit as ProSim aircraft use their own implementation for a lot of things and lot of the standard P3D controls/simvars don't work, although I would have thought that the standard controls/simvars for spoilers would be implemented. Also, the version of ProSim would be useful as I've heard things have changed quite a bit in the more recent releases (but that may be for the 737...)... Then why are you sending me logs? What am I supposed to do with that? What I am suggesting you to try is to monitor the spoiler offsets (0BCC and 0BD0, and maybe 0BD4 and 0BD8). Turn other logging off for now. Then see how the data in those offsets change when you arm, and then when you touch-down. If these offsets are working, then you should see 0BCC change from 0 (off) to 1 (arm) and offset 0BD0 set to 4800 when you arm, and on touch-down you should then see offset 0BD0 gradually increase from 4800 to 16383. Try that - no need to post logs, just tell me what you see. If those offsets change as expected, then you should be able to use those. If not, maybe ProSim doesn't use these....I don't use ProSim so I cannot check that here. John

That is a continuation log - I said I need to see the full log. If its too big to upload, zip it. And there is no point in posting log files if I don't know what I am looking for...please at least provide some sort of description of what you did, and some indication of what you think is wrong if possible. And I still don't even know which aircraft you are using or which version of FSUIPC6 - a full log file would tell me this... John

Offsets 0x0BCC and 0x0BD0 are both 4 bytes, so you need to select U32 for the logging on both of these offsets. Also, you need to select an option for where to log - check the 'Normal log file' check-box to get them logged to the log file (and console). And please do not post screenshots of your logging console. If you want me to look at your log, attach it - and don't post continuation logs when posting for support, I always need to see the full log.

For logging, use the Logging tab (isn't that obvious?) - offset logging is on the right-hand side. Please see the FSIOPC User guide. What do you mean? Isn't the meaning obvious and as documented? 0x0366 will contain 0 when in the air and 1 when the aircraft is on the ground (slew mode excluded), just as documented. Offset 0x0BD0.... Why are you quoting the documentation? Try monitoring offset 0x0BD0 and 0x0BCC.

But that is the on-ground flag, nothing to do with spoilers really (although of course the spoilers should be deployed if armed when you touch down). Yes - the size of the data held in the offset, in bytes. John

I can't really help you with this, but according to @Pete Dowson's comment above: so maybe check with either SimAvionics or FDS for the appropriate driver? Or try SimAvionics support. John

What further information do you need that is not in the offset documentation: 0366 2 Aircraft on ground flag (0=airborne, 1=on ground). Not updated in Slew mode. 0BCC 4 Spoilers arm (0=off, 1=arm for auto deployment) 0BD0 4 Spoilers control, 0 off, 4800 arm, then 5620 (7%) to 16383 (100% fully deployed). The 4800 value is set by arming. Values from 0 to somewhere close to, but below, 4800 do nothing. The percentage extension is the proportion of the distance in the range 4800 to 16383, even though values 4800 to 5619 cannot be used—7% seems to be the minimum ? Also see offsets 0BD4 and 0BD8 for the individual spoiler positions (read-only), and offset 3412 for the spoiler input axis value. Try logging those offsets (using FSUIPC's logging facilities) to see how they change when you arm and/or manually activate the spoilers manually. John

Ah! Glad you found that - and thanks for reporting back. John

Maybe worth a try. Reserved means that that the offset is being used for other purposes, maybe allocated for certain internal functions or allocated for specific add-ons. In general, you shouldn't use them. I will update the offset document at some point to specify if the offset area is used for a specific add-on, and then that area can be used if not using that add-on (I have already done this for the FSUIPC7 version og this document). Regards. John

First, you posted in the FAQ section, where it explicitly states NOT for support requests. I have moved your post to the main support forum. It is always helpful if you state what FS, version of FSUIPC and aircraft you are using. Did you check the offset status document? If you had, you will see offset 0x0BC4 and 0x0BC6 for left/right brake positions. But you shouldn't need to use offsets - assugning to the left/right brake controls should be sufficient. If both left brake and right brake are working separately, I can't see how they are not working when pressed together. Try activating axis logging, with the console window open, and see what is being sent when you press your brakes. If you are still applying thrust, the brakes aren't going to bring you to a halt... If you need any further assistance, please provide more information and your FSUIPC .log and .ini files. John

How are you executing the script? If doing this on a button or key-press. then it will be compiled each time before it is ran which also takes time. Lua scripts based in events should be started from the [Auto] section, or a profile specific [Auto.xxx] section. Also, a 1ms timer seems far too fast - do you really want to do this 1000 times a second? Try using a reasonable number (e.g. 100 for 10 times a second) and you will probably get better performance. You can also try activating debugging for lua scripts which would give you the timestamps for each line executed, which would tell you what is taking the time. I expect it will be reading the lvars, as this is delegated to the the panels.dll in P3D. You are also using offsets reserved for other use - PMDG (0x6200 - 0x62FF) and Traffic Board (0x6300 - 0x63FF). You should be ok if you don't use those, but better to use the offsets assigned as free for general use if you can. John