John Dowson

Do you have FSUIPC auto-started? If so, try exiting FSUIPC7 and restarting it once your aircraft is loaded. This seems to make the key reception a lot more reliable. It looks like there may be performance issues in the latest update, and having FSUIPC7 started by the sim means that the processor time allowed for FSUIPC7 is restricted by the sim. Starting this manually seems to fix this. I will investigate further tomorrow. John

Your log shows that you were trying to control things before everything was ready: You need to wait until everything is connected and ready, so can you please try again and wait a little longer - it looks like its taking just under 2 minutes to load the PMDG 737 and get everything ready. If that is not the issue, please activate logging for Buttons & Keys and Events, and show me a log file where your key presses are not working, i.e. load the aircraft, wait until everything is loaded, then press a few assigned keys, then exit before attaching your FSUIPC7.log and FSUIPC7.ini files. This seems to work ok here... I have just fired-up MSFS and there was yet another update. I have noticed that key assignments seem to be a bit hit and miss - they work sometimes but the reception of keys seems to get stalled sometimes. No idea what they have done, but it looks to be an issue on MSFS's side. I will look into this further tomorrow. I also now see a continual spinning circle in the bottom right of MSFS, so it looks to be continually bust for some reason...

See John

As I said, those presets are designed for a press/release to disconnect, and then another press/release to connect. If you want a press to disconnect, and a release to re-connect, then you have to define your own presets to do this. Ret adding the following to your myevents.txt file (create this if no present) and assign to these: John

Are you assigning to a button or a switch? i.e. are you sending a press/release each time, or sending a press to disconnect and a release to re-connect? I ask as looking at those preset definitions, they look like they are defined for a momentary button that sends a press followed by a release, as the press toggles an lvar then sets an lvar for animation: (L:S_FC_CAPT_TILLER_PEDAL_DISCONNECT) ! (>L:S_FC_CAPT_TILLER_PEDAL_DISCONNECT) 1 (>L:S_FC_CAPT_TILLER_PEDAL_DISCONNECT_Anim) and the release just triggers an lvar for animation: (L:S_FC_CAPT_TILLER_PEDAL_DISCONNECT) 0 == if{ 0 (>L:S_FC_CAPT_TILLER_PEDAL_DISCONNECT_Anim) } (L:S_FC_CAPT_TILLER_PEDAL_DISCONNECT) 1 == if{ 2 (>L:S_FC_CAPT_TILLER_PEDAL_DISCONNECT_Anim) } So, the way these work is that a press/release will disconnect, then another press/release will reconnect. If using a switch, then you should define new presets that toggle the lvar and do the animation for both a press and release. This same issue was recently reported on other Fenix A320 presets and I showed how to define new presets for use on switches - see here: You have also assigned with 'Control to repeat while held', which is not needed and can cause issues - remove this. These presets also do not take a parameter - remove those (i.e. use 0) to avoid any confusion (but the parameter is not used, so you can leave as long as you understand this). John

When the installer cannot determine the location of your MSFS UserCfg.opt file, it cannot install - the WASM, as it does not know the location of your Community folder - the auto-start component, as it does not know the location of your MSFS EXE.xml file When this happens, both of those components are deselected and grayed-out. Neither of these components will prevent 3rd party apps connecting to FSUIPC, but as the auto-start component is not installed, you will have to start FSUIPC manually. You can either try to fix the issue that is causing this, or toy can install each component manually. To install the WASM, unzip the file SDK\FSUIPC-WASM.zip. Then unzip fsuipc-lvar-module.zip, then move/copy the fsuipc-lvar-module folder to your MSFS Community folder. To install the auto-start component, you will manually have to edit your EXE.xml file - see There was an issue in versions before 7.4.6 (latest version) that could sometimes prevent 3rd party programs from connecting to FSUIPC7, depending how/when FSUIPC7 was started. You probably had this problem. Updating to 7.4.6 should solve these occasional connection issues.

That is not the 'old fashioned mode' - it is still valid and the recommended way to assign an axes for most aircraft axes controls. However, you cannot use this method for aircraft that use the the newer *_EX1 controls, and some advanced add-ons don't play well with FSUIPC calibration when configured this way (e.g. flaps in the PMDG 737). Anyway, glad its all now working. Cheers, John

That offset holds a 2-byte integer, not a FLT64, and the description of this offset is: Engine 1 EGT, 16384 = 860 C. [Note that for Props this value is not actually correct. You will get the correct value from 3B70. The value here has been derived by FSUIPC to be compatible with FS2004, FS2002 et cetera] As you are not using a Prop aircraft, that offset should hold the correct value, but maybe also try offset 0x3B70: General engine 1 EGT in degrees Rankine, as a double (FLOAT64). Convert to Fahrenheit by Rankine – 459.67. FS default gauges show Centigrade. As that is in Rankins, first convert to Fahrenheit and then to Celsius. John

'@' is the input value from your axis - this should be between -16384 and + 16383, if not you need to adjust the preset. Then, from left to tight 16384 + will add 16384 to the axis value, giving a range of 0 - 32768 32768 / will then divide by 32768, giving a value between 0 and 1 3 * will then multiply by 3, giving a value between 0 and 3 2 + will then add 2, giving a value between 2 and 5 2 max 5 min will ensure the value is between 2 and 5. You can assign to any FS axes control, including Throttle1 Axis Set Ex1, by checking Send to FS as normal axis. It is a good idea to also make your calibration profile specific and remove/reset any throttle calibration when assigning this way, to remove any possibility that your standard/general calibration profile interferes. If that axis control works, you should certainly use that rather than lvars or presets.

Ok - I can see this is a weather add-on for FSX that uses FSUIPC4. That shouldn't be a problem...

Once installed, the FSUIPC main window is accessible from the Add-ons window of FSX - do you see it there? If not, please show me/attach your FSUIPC4 Install.log file (located in your FSUIPC4 installation folder, which will be the Modules folder under your FSX folder) . You can compress/zip it if too large to attach directly. What are 'fsxwx' and 'SFXWX '? FSUIPC4 is for FSX only.... John

Upload limits are very low fir new users, but increase after a few posts. Both both your InstallDSUIPC7.log and FSYUPC7.log files should be small anyway, and they compress/zip to a very small size which allows upload. So you are using an MS store installed version? Where is your MSFS UserCfg.opt file located - is it in any of those locations mentioned, if not, where is it? But this doesn't make any sense! First, as you say you could not install the FSUIPC WASM module, there is no location to move these files to - where did you place them? And hvar files are in no way related to connection issues.

Always better to attach files rather than pasting their contents. Are you using an MS Store purchased version of MSFS or did you purchase/install from Steam? The installer is detecting an MS Store installation - is this correct? Is your UserCfg.opt file present in one of the following locations: C:\Users\Byersaa\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\UserCfg.opt C:\Users\Byersaa\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalState\UserCfg.opt ? Can you please show me a screenshot of this, as I asked... Did you try the latest beta, as advised? Does Pilot's Life connect with that version? If not, please show me/attach your FSUIPC7.log file. 7.3.6 has been released so please update to this version, and after installing please attach your InstallFSUIPC7.log file. John

Maybe the preset BS TBM850 Flaps 850 is what you are looking for. You can assign a button to this by checking Select for preset, click the Find Preset... button and navigate to Black Square -> TBM850 -> Controls and select that preset.

When installing, you can opt not to install this file by unchecking it from the Extras section

I don't see how that can be possible...only the first option should be greyed-out (i.e. not possible to deselect), which is FSUIPC7. Can you show me a screenshot of this please. You also wrote the following in another post, which I have deleted: Can you please show me/attach your FSUIPC7Install.log file. Are you using an MSFS store version or Steam? For connection issues, please first try the latest beta, available from If you still have issues with that version, please attach your FSUIPC7.log file. John

Not exactly sure on what you are saying. but please understand the difference between the events.txt file and the myevents.txt file...every time you update, the events.txt file will be updated/installed to the version included in the installer. Please read the Advanced User guide for details. John

No. Lua global variables are only visible to lua scripts started by FSUIPC. I don't know anything about Air Manager, only FSUIPC.

I have no idea, as I am not familiar with this aircraft. However, there are many presets already defined for this aircraft - have you looked for these: https://hubhop.mobiflight.com/presets/ All MF presets are available for assignment. If the function you are trying to assign is not there, then you need to go through the standard procedure to determine how to assign to this - i,e, logging and testing, and maybe inspecting.... John

On the MF HubHop site there are 3 pot. controls - two for lights (flood and instrument) and one for rudder trim: Take a look at these - and also the comments (w.r.t calibration and animation). You can define your own presets based on these for your axis values. Take a look and try to define your own presets based on these (i.e. change to use the values that your axis is sending). Please try, if you have problems let me know and I can provide a preset/calc code for standard axes values (-16834 to + 16833). John

Presets are calculator code in RPN format - there is not much information on using calc. code, but see https://docs.flightsimulator.com/flighting/html/Additional_Information/Reverse_Polish_Notation.htm Also see the documentation on presets in the FSUIPC7 Advanced User guide, in the WASM section (page 48). This is the calc. code for the throttle preset FNX320 THROTTLE LEFT LEVER SET: @ 1023 / 3 * 2 + 2 max 5 min (>L:A_FC_THROTTLE_LEFT_INPUT) So, define your own preset based on this - add the following to your myevents.txt file (create this if it doesn't exist): //FenixSim/A320/Controls MY_FNX320_THROTTLE_LEFT_LEVER_SET#@ 16384 + 32768 / 3 * 2 + 2 max 5 min (>L:A_FC_THROTTLE_LEFT_INPUT) MY_FNX320_THROTTLE_RIGHT_LEVER_SET#@ 16384 + 32768 / 3 * 2 + 2 max 5 min (>L:A_FC_THROTTLE_RIGHT_INPUT) and then assign your throttle axis to those 2 presets. This should then control the throttle between 2 = IDLE, 3 = CLB, 4 = FLX, 5 = TO

Looks better, but I need to see the FSUIPC5.log, not the FSUIPC5 Install.log. Please try with the following ini file - just run FSUIPC5/P3D then exit then show me the 3 files again - this time with the correct .log file. FSUIPC5.ini You can also check if the buttons on your devices are recognised, but don't assign anything just yet. If you have a problem with a device, please let me know which one - saying 'The correct card is the one with 11EE in the serial number' is not enough, as 5 of your 7 devices have that! John

First, you are using an old and unsupported version of FSUIPC7 (7.4.2). Please update to the latest released version (7.4.5) or the latest beta, available here: Why are you adding lvars I_OH_PNEUMATIC_ENG1_ANTI_ICE_L and I_OH_PNEUMATIC_WING_ANTI_ICE_L to offsets and monitoring those if the presets you are using are using the lvar L:S_OH_PNEUMATIC_ENG1_ANTI_ICE? Monitor the lvars that you are using to determine what is happening... You are also monitoring offset 0x3110 as U8, so are getting rubbish. This offset is 8 bytes, or, to be more precise, is 2x 4-byte integers. Monitor 0x3110 as U32, and 0x3114 as either U32 or S32. But you don't need these offsets logged if you add logging for Events. Do you understand what those presets are doing? The first one is toggling the lvar S_OH_PNEUMATIC_ENG1_ANTI_ICE (between 0 and 1), and the second is controlling the switch animation based upon the value of that lvar, using the lvar L:S_OH_PNEUMATIC_ENG1_ANTI_ICE_Anim. So it looks like those presets are designed for a momentary button, that sends a press and release, and each time you press/release it toggles the function and switch. If you are using an actual switch, you will not want to use those. For a switch, try: FNX320_Icing_Engine_1_Button_On# 1 (>L:S_OH_PNEUMATIC_ENG1_ANTI_ICE) 2 (>L:S_OH_PNEUMATIC_ENG1_ANTI_ICE_Anim) FNX320_Icing_Engine_1_Button_Off# 0 (>L:S_OH_PNEUMATIC_ENG1_ANTI_ICE) 0 (>L:S_OH_PNEUMATIC_ENG1_ANTI_ICE_Anim)

Not by itself, but you can read offset 0x3308 to determine the FS, and maybe 0x3124 to determine the version (if needed). You can use an ipcReady.lua script (or any auto-started lua script) to read those offsets I mentioned to determine the FS and version, and then start your programs using ext.run (or ext.runif) depending on the FS and version. Probably also a good idea to have an event.terminate function and stop the programs using ext.close when the lua is terminated.

Set logging for Buttons & Keys and Events. You cannot log lvar values directly, but you have two options: 1. Add the lvars to offsets, and use the offset monitoring facilities to log the lvar value changes 2. Manually list the lvars (and values) using the Add-ons->WASM->List Lvars option before and after you press the assigned button. This will log all lvars and their values both to the FSUIPC7.log file and the FSUIPC7 main window. Many MSFS aircraft, especially add-ons, continually emit certain events, and these events are different for each aircraft. These are not an issue and won't prevent any other events from getting executed, but they are just noise in the log file. You can prevent such events from being logged using the DontLogThese ini parameter, best used in your [Profile.xxx] section (as they are aircraft and so profile specific). Also, please turn off logging options not needed (e.g. IPC Read/Writes), as these will just fill the log with info not relevant to your issue. Please also attach your FSUIPC7.ini file when attaching FSUIPC7.log file - I need to see them both to understand what is happening. John