John Dowson

You also need to start the lua. You do this by adding it to the [Auto] section (which you can add if not already there), i.e. John

Better to explain your issue - is it that you have reduced speed while climbing? The OPs problem is that he had flaps deployed - have you checked the position of your flaps and spoilers when you perceive this lack of power? Your throttle calibration in your B737PMDG profile also looks strange: This looks like you have calibrated with a reverse zone but are not using a reverse zone. Better to calibrate with no reverse zone. I also need to see your FSUIPC7.log file showing your issue. Set logging for Buttons & Switches and Events for the first test, Also, please update to 7.4.2, the latest and only supported version of FSUIPC7. John

FSUIPC will only recognise buttons on HID joystick type devices. If this is a non-joystick type HID device, then you have to use the lua com library instead. There are various methods of doing this, but the easiest to start with would be to use the provided HidDemo.lua script, available in the Example Lua plugins.zip file which will be installed in your FSUIPC documents folder. This script converts HID button presses to virtual button presses, to which you can then assign in the Buttons & Switches assignment panel. You will need to edit the script to give the correct vendor and product ids for your device, and have the script auto-started from your FSUIPC ini file. John

It doesn't - it is reporting dev/com threads still running, and this is before the terminate message for that script, so probably not closed yet. I wouldn't worry about this until it fails, i.e. does not stop the script. Then send me the logs.

i have looked into this further and have found some strange interactions between FSUIPC7 and Spad.Next w.r.t sending key presses, but not exactly as you describe. How have you assigned in Spad.Next? Are you sending to the active window or to the FS? The latter is preferable. Not 100% sure what the issue is yet (it looks like Spad.Next is sending the key presses/releases to FSUIPC7 instead of MSFS), but I will look into this further and contact Spad.Next to see if anything can be done about this.

Not necessarily...best to just look at the scripts and see if they are opening any com ports, and if so close them in a terminate function. However, that log extract shows everything closing/being killed ok. Why would i need this? Just check the script and add some lines to close the coms in a terminate event. Looks like it may already have such a function, as 'LUA.11: HidSwitch ends.......' is reported....

Then it looks like that aircraft is not using (or respecting) that simvar. Instead of using the aileron simvar offset, you could try sending the AXIS_AILERONS_SET control/event instead. To use this, you need to write the value/parameter to offset 0x3114 as a 4-byte int, then write the control number, which is 65763 for AXIS_AILERONS_SET, to 0x3110 as a 4-byte int. You can also write all 8 bytes in one go if you prefer.

Those errors are reported soon after 'Requesting Input Events...' is logged. This is just a timing issue as the input events that are activated/initialised are received from the aircraft before the actual input event list is beinf received. You can safely ignore these. I will look into removing the logging of this messafe if the input event list has not been received. This should not prevent anything working though... Please do not 'log luas separately' - remove this logging option, and send me a full FSUIPC7.log file showing this issue.

Also, what aircraft are you using? Your full log file would tell me this....if using an add-on, maybe try with another (default) aircraft to see if you get the same issue.

I have checked this now and all luas are terminated correctly here: If your lua scripts are using the com library (or is using any other open handles), then it is a good idea to close these in an event.terminate function, as this can prevent scripts from being terminated. Otherwise, please show me your FSUIPC7.log and FSUIPC7.ini files when you experience this issue

You attached a continuation log again... This is what I see when I assign a button to change/set this offset: i.e. the button press correctly updates the simvar AILERON POSITION and the yoke moves to the position set. This is also happening on your system but something is then sending an AXIS_AILERONS_SET control/event with a parameter of 0 directly afterwards. We need to find out what is sending this. Can you repeat the last test please, when updating the offset assigned to a key, but this time also activate logging for Buttons & Keys and Events, and show me the full log file, NOT a continuation log, and also attach your FSUIPC6.ini file. Please also remove the offset monitoring for offset 2EF8. If the log file is large, you can zip/compress it.

I did remove what I thought was some unnecessary code recently with regards to lua script starting/terminating...maybe I removed too much... I will check this and get back to you. But you say only sometimes....does this mean that they are usually stopped/killed, but occasionally not? Do you see anything in your logs that indicate that it failed to terminate a lua script?

Try with each argument in double quotes, and also around the program if the path contains spaces. i.e. Run6=Kill,C:\FS\peroLoadsheet2Hoppie\peroLoadsheet2Hoppie.exe "/p3d" Run7=Kill,"C:\Program Files\Virtual Audio Cable\audiorepeater.exe" "/Input: VAC Line 3 GSX (Virtual Audio C" "/Output: VAC Line 2 (Virtual Audio Cable" "/Autostart" You may also need to escape the back-slash, i.e. Run6=Kill,C:\FS\peroLoadsheet2Hoppie\peroLoadsheet2Hoppie.exe "//p3d" Run7=Kill,"C:\Program Files\Virtual Audio Cable\audiorepeater.exe" "//Input: VAC Line 3 GSX (Virtual Audio C" "//Output: VAC Line 2 (Virtual Audio Cable" "//Autostart" Try the first and if that doesn't work, try the second. As your audiorepeater.exe is under "Program Files", you may need to run as admin to start this. Best to re-install this in a non-windows protected folder. But see how it goes.... John P,S, Check your arguments are correct...no closing bracket after ' (Virtual Audio C' or '(Virtual Audio Cable', and why the difference?

The post above above by @ark1320 shows how to do this... They go in the FSUIPC7 installation folder, or you can place them in a subfolder and set the LuaPath ini parameter to define the location (see documentation for details). Be aware that many generic controls (and thus offsets) don't work with many MSFS aircraft, especially add-ons, which implement their own systems, and you may have to change to using presets or lvars or input events, etc, instead of writing to offsets to trigger generic controls or simvar updates. But you just need to try these things to see if they work and then adjust accordingly for the aircraft that you are using. John

Can you please show me/attach an FSUIPC4.log file showing your issue, with logging for both Buttons & Keys and Events activated. John

Before you but, please try the trial version, which provides full access to all FSUIPC7 functionality. The trial key/license is available to download from aa topic at the top of this forum, here: Check out the presets available from MobiFlight - all these are available directly in FSUIPC7: https://hubhop.mobiflight.com/presets/ If there are no presets available, for what you want to achieve, in may be possible to define your own, or use input events, lvars, hvars or other means. I can help with this if you need further instruction, but only for the aircraft I own, i.e. the FBW but not the Fenix. But you can also always ask about presets on the MobiFlight Discord channel for MSFS2020. Also, please consult the documentation provided for FSUIPC7 before asking for further support, and check these forums for similar questions/issues. John

Maybe also try assigning a button or key press to the control Offset Word Set with offset 0BB6 and parameter 12000 - does that work? If so, then there is something wrong with your code...please try this as well.

Pleas only attach full logs, not continuation logs. You can zip/compress them if too large to attach directly. Also, please select to sending the monitoring of offset 0BB6 to the FSUIPC log file - this is missing and would help .... Having said that, this is what the log extract you attached shows: So something is setting the value back to 0 soon after you write to the offset. No idea what is doing this, but a full log file with that offset being monitored (and written to the log file) would help....

Not sure why you are attaching files....as I said, you are just back to the previous situation where it is working but with no name for your yoke. I have nothing further to add to this that i have not already said:

First, please exit FSUIPC7 before attaching logs. Your log just shows that FSUIPC7 received key presses (from MSFS) and did nothing with them as you have no assignments. As these key presses were received from MSFS (and they are not masked), I don't see how FSUIPC can be intercepting these keys or preventing actions assigned elsewhere. It is also strange that initially only keyup's were received, and then only keydown's over a minute later.... Can you therefore please check things at your end, and also try with default aircraft.

Those offsets hold the value of the simulator A-type variables: 0x3160 - ATC TYPE 0x313C - ATC ID 0x3148 - ATC AIRLINE If they are being reset to be empty strings, it is because FSUIPC7 is receiving this update from MSFS. This is probably because there is no ATC for the aircraft once the power is off.... There is nothing I can do about this - FSUIPC7 just shows the data as received from the FS. If the ACARS system still needs this information, it should make a copy and use that. You can even copy those offsets to other offsets, and if you only copy when non-empty then you will always have the last available values. John

Can you show me/attach a log file please with that offset being monitored and IPC writes logging activated as well as Axis controls. Also attach your ini file. Then something is setting it to 0 - the logging should confirm this... What keyboard assignment? No.

What does this mean? What is the 'desktop screen'? Not sure I fully understand this either. If it is still in the task bar, then you did not close/exit FSX. It is not possible to have two copies running. Well, there is something wrong somewhere...I have already advised to re-install FSX.... John

If you change a lua script, just run it to pick up the changes. if it is already running, when you run it again the currently running script will be killed. For ini file changes, it depends on what is changed. Some parameters are only read at start-up, others when needed. When changing assignments, you should always do this either with FSUIPC7 not running, or with the relevant assignment panel open, and click to reload the changes after saved. Just disable logging for Lua Plugins - ipc.log statements will still be logged. No. Lua scripts are compiled by FSUIPC7 just before being ran, and they are onky ran when FSUIPC7 is connected to MSFS and you have an aircraft ready to fly (i.e. not in the main menus). Of course, you can use standard lua outside of FSUIPC7, but you will not be able to use the additional lua functions provided by FSUIPC. John

You are using a very old version of FSUIPC7 - 7.0.2 from November 2020. The latest version is 7.4.2 - please update. FSUPC will receive all keystrokes (from MSFS via SimConnect), but it will not do anything (as you are using an unregistered version) except log them, if activated.