John Dowson

Lua scripts are not started until you have an aircraft loaded and ready to fly. The log you pasted shows that FSUIPC was not even connected to MSFS, and ends after 11 seconds. It will NOT show up there - that is a scan of HID joystick type devices ONLY. When the script is running, it will map the buttons of your device to virtual buttons, which you should see when activated in the button assignments panel.

Not really - but the title says 'anymore' - does this mean that it was previously recognised? If so, what has changed? Can you also please attach your FSUIPC7.log and FSUIPC7.ini files and I will take a look. So you previously had working assignments in FSUIPC7? Are your axes/buttons on the throttle seen by FSUIPC7? i.e. can you see them in the assignments windows when moved/pressed? If so, I would suspect that there has been change in the registry which means that the name or GUIDs of your device have changed and the device has been recognised as a new device. Your files would help determine if this is the issue or not and if so it is easily corrected. Otherwise, please download the HidScanner tool, available from the Download Links -> Useful Additional Programs section of this forum. Run this and send me the output (together with your .ini and .log files). Also worth checking the power management settings both on the device and on your USB Hubs - make sure power management is disabled. P.S. I moved your post to the correct support forum for FSUIPC7

See my last post - I suggested that you try this, and I don't think this will make any difference. FSUIPC allows you to control the aircraft, it does not affect the aircraft model. You need to determine what could be the cause of this loss of power. Please do, but I don't think this will make a difference.... John

But the initial report from the OP looks to have been caused by flaps being accidentally deployed, slowing the aircraft. If the flaps are up and the speed brake stowed, then I have no idea what could be causing a power reduction. However, I cannot see how this cannot be anything that FSUIPC is doing, as it only controls the aircraft model through the assignments you have made. You can test/check this by pausing the sim when you are configured and climbing, exit FSUIPC7, then un-pause the sim. The aircraft should continue climbing at the same rate. I can only assume that this must somehow be due to the aircraft set-up/configuration. I am no expert in the 737, so maybe better to ask about this on the PMDG forums. Your log file shows nothing unusual. John

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