John Dowson

Ok, that is interesting as it implies that this issue only (and always) happens when FSUIPC7 is auto-started by the sim - and only for you as far as I can tell... There will be, but all timings start once the FS is detected, and it works ok for you when you start FSUIPC7 manually before the FS. And all threads are started ok, it is just that simconnect does not seem to be sending/forwarding key presses/releases. As one last test, could you find your EXE.xml file (location will be logged in your InstallFSUIPC7.exe file), find the FSUIPC7 entry and remove this: or maybe change to this: i.e. remove the '-auto' flag. This will change some timings, John Later: someone else has now reported the same issue:

Sorry but I don't know what could cause this issue as I am not using SU15 at the moment. Is there a PMDG update available for SU15? Could you add the following to the [General] section of your FSUIPC7.ini file: TestOptions=x400 and generate a short log file (load the PMDG737, sit on the runway with engines running for a minute or so, then exit) and show me/attach that please. I am still on 3.0.87 of the PMDG737 - I will update to the latest version (3.0.91) and check with this. John

This is very strange! The problem seems to be that FSUIPC7 is just not receiving key presses (via SimConnect) when initially ran, but is after a restart. And it is also very strange that this only seems to be happening for you - its fine here and I have had no other reports on this (I would expect a lot of support requests if key assignments weren't working!)). Could you do two more tests please: 1. Start FSUIPC7 before you start MSFS. You will get a pop-up box that says FSUI{C7 is already running - just acknowledge that. Do you receive key presses then (once an aircraft is loaded)? 2. Rename your ini file (temporarily) so that a new default one is created. When you start MSFS and FSUIPC7 is started, activate logging for Buttons & Keys and open the logging console (Log -> Open Console). Load and aircraft and then press some keys - are these key presses then received and logged by FSUIPC7? Once this is done, exit FSUIPC7, delete the newly created FSUIPC7.ini and restore the original one. Thanks, John

Ah, ok... Looking at the lua again, if using a momentary button you should really assign to LuaToggle, not LuaSet. If using a switch or sticky button, then assign to LuaSet on press and LuaClear on release, with all assignments using a parameter of 2.

Do the default MSFS key assignments work?

You could try reading the documentation.... When FSUIPC7 starts, you should see a splash screen - do you see that? If so, it is running and sitting in your system tray, not the task bar. You can open it from the system tray or use the key combination Alt+F to show the main window. Once it is open, you can iconize it to the task bar if you so wish, or just close the window and it will sit in the system tray until you exit MSFS. If you do not see the splash screen either when MSFS auto-starts FSUIPC7 or when you start it manually, please show me/attach your InstallFSUIPC7.log file. John

Yes, via the PFC driver. This has the assignments to standard FS controls built-in, via macros, which should work pretty much out of the box for aircraft in FSX and P3D, but things have changed a lot in MSFS2020. Many functions may work in some aircraft, but certainly not in all, and not in many add-on aircraft. You will have to provide your own macros to control some aircraft. See the documentation provided with the PFC driver for details. You can try that but it won't show you anything as FSUIPC is not controlling your button assignments, as i said. You may see the PFC buttons but I am not sure - they probably go to the PFC log file. Why would you crash? If you are flying on AP, you aren't using the controls and so exiting FSUIPC should not be a problem, and then you can see if the RSG500 functions any differently without FSUIPC running. Open the FSUIPC main window (Alt+F), then File->Exit. Do that and then try your 500 to see if it works, then you can restart FSUIPC7 and try again, and see if there is a difference. As I said, I expect not as FSUIPC cannot see this device so I cannot see how it can be interfering. John

Also, the Asobo 172 classic is fitted with a Garmin GNS 530 & a GNS 430, not a GTN500. Or is the aircraft model updated to include a GTN500 in the VC? If not, how can you expect this to be fully functional in an aircraft that does not support it?

The button presses are not being logged - what is being logged is the events that these presses are generating in the FS. You can also log the button presses by activating logging for Buttons & Keys. However, this won't log anything as your devices are not being controlled by FSUIPC, so it will not see any button presses. But FSUIPC is not seeing or doing anything at all with the RealSimGear GTN500, and I cannot see how it can be interfering at all....And I still don't know how/where you have assigned the buttons on this device. Well, you could just exit FSUIPC7... have you tried exiting FSUIPC7 mid-flight and checking if that changes the way the 500 works? I suspect not...I think you need to go back to RealSimGear support for this issue, sorry. The only issue I see in your log files is this: i.e. two devices with the same id and guid. However, as you have no assignments to this/these devices in FSUIPC (at the moment), this is not causing any issues. I cannot help with devices not assigned in FSUIPC, and I cannot see how FSUIPC can be interfering with devices assigned elsewhere that FSUIPC cannot even see. John

Could it be that something else (i.e. not MSFS) has the (keyboard) focus, so that when you press the keys they are not being seen by MSFS and so not being sent to FSUIPC? Can you test for this - when you find that your key assignments are not working, click on the MSFS main window to give it the focus and try again. I don't understand why this would be different once FSUIPC7 is restarted though...

The prev log shows that no key presses were detected. Ok. So it seems that the issue is nothing to do with lua, but that FSUIPC7 is not picking up key presses when FSUIPC7 is initially (auto?) started, but is when restarted. Very strange... Presumably none of your key assignments work when FSUIPC7 is initially started, no? Can you check this please. Is FSUIPC7 being auto-started by MSFS, or are you initially starting it manually, and if so when (i.e. what state is MSFS in when you start FSUIPC7)? I can't seem to reproduce this here...I will keep investigating....

Your profile lua is not being started. When using profiles-in-separate files, the [Auto] section for the profile goes in the profile ini file, not in the main ini file. Remove this from your FSUIPC6.ini file: and add this to your AsoftA3xx.ini file: And this assignment in your AsoftA3xx.ini file is wrong as it will just restart the lua script: Change this (via the UI) to use LuaSet and not Lua. This will then set the flag 2 in the already running lua script to call AB_EXT_ExtPwr_toggle when you press the button.

You are using a very old (15/11/2022) and unsupported version of FSUIPC, 7.3.15. Please update to the latest and only supported version, 7.4.8. But your log shows that FSUIPC cannot even see these devices, so I cannot see how it can be doing anything... Yes, as they show nothing - but maybe just for Events for the moment. And please turn off all other logging. Also try with the logging console window open (Log -> Open Console) - do you see any events logged when you press the buttons on the GTN500? Is there a difference in what you see in the 172 compared to the KingAir? Not necessarily - depends what commands/controls the device is sending. Where is this controlled. i.e. how have you set up this device to send the correct controls for each button and for each aircraft? Do those planes actually have a GTN500 installed in the VC? I am confused now, as you also say ' if i do NOT run FSUIPC the RealSimGear AP works fine in MSFS 2020'... So which is it? Please also attach your FSUIPC7.ini and PFChid64.log files, as well as your FSUIPC7.log file.

Ok, but I am surprised this works because here: value is a string and you are treating it as a number. Maybe it is implicitly converted, but would be better to just use strings, i.e. miles1 = string.sub(value, 2, 4) No problem, John

You can also turn off logging for Lua Plugins, and add the following to the top of lua that isn't working properly: require "ipcDebug" (the ipcDebug.lua needs to be in your lua folder - it is available in the example plugins zip file) This will then activate the lua plugin logging for just that script, and it may then be easier to see what is happening in the logs...

You can also pass the offset as a user parameter, so the script would be something like this: function checkOverhead(varname, value, offset) --Check lights overhead ipc.writeUB(offset, value) end event.lvar("L:O16_001_BUT", 100, "checkOverhead", 0x4251) event.lvar("L:O16_001_LT2", 100, "checkOverhead", 0x4252) event.lvar("L:O16_002_BUT", 100, "checkOverhead", 0x4253) event.lvar("L:O16_002_LT2", 100, "checkOverhead", 0x4254) event.lvar("L:O16_003_BUT", 100, "checkOverhead", 0x4255) event.lvar("L:O16_003_LT2", 100, "checkOverhead", 0x4256) event.lvar("L:O16_004_BUT", 100, "checkOverhead", 0x4257) John

But which is the lua script that is not working? Can you attach this script please. You are starting 11 luas with auto-start (6 general and 5 profile-specific), and one twice - you are starting the lua script Nav1FreqInit in both your general section and your profile section. If you remove the scripts that are working and just run the one that isn't, does that then work or not?

I need to see your ini file for your AsoftA3xx profile, but it looks like you have assigned a button to start the lua script. As the script is already running, this will just kill the script and run it again. Looking at te script, it looks like you need to assign to set a flag in the script, so you need to assign to LuaSet (not Lua) for the script, and with a parameter of either 1 (for AB_EXT_ExtPwrGPU_toggle) or 2 (for AB_EXT_ExtPwr_toggle). John

How/where have you done this? The only assignment I can see for the TWCS throttle is this one: If that is the assignment you are using, then maybe its the calibration thats causing the issue. You can try removing the calibration and assigning with 'Send to FS as normal axis' instead. I need to see the FSUIPC4.log file (not the installation log). Activate logging for axes controls and move your throttle through its full range and back again, then exit and show me/attach the log file. John

How are you setting the frequency? Have you tried writing the frequency to offset 05C4? Does the aircraft support 8.33KHz spacing? You can check this in offset 0B47. I have no idea what this is.... If its the IOCmodules that are setting the frequency, you need to see how it is doing this as the problem probably lies there... John

What do you mean? If you click Yes to trust, does FSX run with FSUIPC or not? What did you do?

When you go back to the world map, the lua script should be killed. I am not sure what you mean by 'looses connection'. Can you please show me/attach your FSUIPC7.log file showing this issue, and also attach your FSUIPC7.ini file and the lua script and I will take a look. John

Take a look at the available presets (https://hubhop.mobiflight.com/presets/) - maybe try FNX320_FCU_ALTITUDE_KNOB_INC FNX320_FCU_ALTITUDE_KNOB_DEC You can assign to presets by checking Select for Preset. There are also presets to set the altitude scale. Many of he standard FS controls do not work in MSFS, especially for complex add-ons, and you have to use lvars/hvars/Input Events or presets instead. John

This doesn't make much sense as value is a string, and you cannot use the numeric comparison of '<=' on string values - this will NOT be doing what you think. What you can do is check if the 4th character is a period or not, e.g. function Distance1(offset,value) if (string.byte(value, 4) == 46) then -- is 4th character a period (46)? miles1 = string.sub(value, 1, 3) else miles1 = value end prevswitch = -1 -- updates Distance end event.offset(0x0C29,"STR",4,"Distance1") -- DME1 Distance John

I am not sure why its taking so long - I will take a look to see why, but I doubt very much there is anything that can be done to speed this up - its probably related to the gauges/panels dlls that are used to get the lvar values. You could try switching to using the event.lvar function instead, and only write the lvar value when it has changed. You can use the same handling function for all lvars, which will be passed the lvar name as well as the value, so you can have a conditional statement on the lvar name to determine the offset and then set the value. John