John Dowson

I keep spending time analyzing and changing your files, and then you post new ones and I have to start again... Can you please do nothing until I have had time to post you some files to test.... What do you mean by this? There is no pointing attaching just an ini, I need to see all 3 files together. Anyway, I will ignore this file - I need to sort this out in a file with your assignments, if you want your assignments to work.... Please hold off on posting further until I report back....

FSUIPC is just receiving and storing the value of the associated simvar (GENERAL ENG EXHAUST GAS TEMPERATURE), after conversion. If this is not correct, then you need to raise this with PMDG support. I cannot really help with this, sorry. However, maybe this is not the same value that is displayed on the DU. There is also ENG EXHAUST GAS TEMPERATURE (see https://docs.flightsimulator.com/flighting/html/Programming_Tools/SimVars/Aircraft_SimVars/Aircraft_Engine_Variables.htm) - maybe this holds the correct value. I do not know the difference between these two simvars, and the documentation does not say much. You can add this to a spare/free FSUIPC7 offset and see if this matches. Also, you can add GENERAL ENG EXHAUST GAS TEMPERATURE again to a different offset, and also log this to see if the unadulterated/unconverted value matches. See the Advanced User guide on how to add simvars to free offsets.

What did you actually do with this? Looking at your ini, looks like all your GUIDs/Names don't match... I think I also need to update your FSUIPC7.ini....but to do this I need to know how you have assigned anything. It may be worth cleaning the registry of all devices, disconnecting everything and starting again....But if you are using assignments somehere, I need to know the ids or letters you are using for each device so I can update your ini file.....

But this is detected with id of 2 and joyletter B: Can you not see this device in the button/axes assignments dialog boxes? What do you see in the assignment panels when you press a button or move an axis on this device? Your log is quite strange in that it shows a lot of device scanning going on - what were you doing? Your files do show a conflict, but between your throttleTek 3 and Fulcrum One Yoke, with both being assigned the same id: and also between the throttleTek 3 and one of your T-Pendular-Rudder: To correct this, you should disconnect the throttleTek 3, remove the registry entries for this device, reboot and then reconnect it. To remove the registry entries, first run regedit and take a back-up of your registry, You can then run the attached script which should remove the entries for that device. Once you have rebooted and reconnected, start FSUIPC7 and exit, then show me your log, ini and JoyScan.csv files again. Your ini file also shows that you have no assignments (button, key or axis) to any device, and no lua scripts are started (except ipcReady). removeDevices.reg LATER: don't do this yet!! See below....

Ok. Yes, it was a bug. John

Use it to replace your current FSUIPC7.exe. That is because you have not copied it to the correct location,,,,

I'm not 100% sure on what you are trying to say, but this is your key assignment to the 'Y' key: 56=89,8,PFNX320_MainPanel_Standby_Attitude_Cage_Press,1,PFNX320_MainPanel_Standby_Attitude_Cage_Press,0 -{Y: Press=Preset Control, Release=Preset Control }- i.e. it is saving the press control for both the press and release. IIs this what you mean? I have corrected this in the attached version if you would like to try it. ok, then the attached should fix this. Please also note that for such key assignments, you should really also check the No repeats! checkbox. You can also put an N in the ini file to do this, e.g. 56=N89,8,PFNX320_MainPanel_Standby_Attitude_Cage_Press,1,PFNX320_MainPanel_Standby_Attitude_Cage_Release,0 -{Y: Press=Preset Control, Release=Preset Control }- Before attaching log/ini files, can you also pleasee always exit FSUIPC7 first - the log file you attached shows FSUIPC7 was still running when it was attached. Thanks, John FSUIPC7.exe P.S. Also, always Confirm key press assignments before clicking Ok, otherwise the parameters and no repeat flag will not be saved. Also, most of the available presets do not actual take parameters, so you can leave these boxes empty.

i am sorry but I do not understand what your issue has to do with FSUIPC. Can you please provide more details, and explain why you think this is related to FSUIPC. Are you using FSUIPC6 for both P3dV4 and P3Dv5? Are you using the same installation of FSUIPC6 for both, or are you using separate installations? Whare do you get that message, i.e. from which software?

So the issue is that the installer is not determining the correct path for your DLL.xml file? If so, please attach your FSUIPC4 Install.log file. Don't worry about those other message discrepancies - they are normal and are for historic reasons. Don't read anything into them, they are for me for analytic purposes. I can look into why the correct location of your DLL.xml file was not located, but FSUIPC4 and its installer has been closed for development/updates for many years now, and so I will not be making any changes. John

Yes, you can use (most) reserved offsets assigned to other programs if not using those....although maybe leave the ActiveSky ones that trigger file (radar image) generation, You can certainly use the PM ones, the PMDG ones, and probably most others, although I cannot confirm 100% without checking. John

No point if its working, but your logs show that you are still trying to control things before everything is ready: You should really wait longer before trying to do anything. I don't think so....but, as I said, I need to see your files (generated when you have the issue) to diagnose. I have been testing 7.4.6 most of the day here and cannot find any issues.... I always run in DevMode and do not see this. Do you still have the same issue? FSUIPC is not involved in this at all, unless you assign alt+enter also in FSUIPC... John

Strange... is the window not like this image (without the added text), or is it cropped: The 'Preparing the cabin...' text is superimposed on this. It really isn't a problem if the full text is not displayed. just ignore... Such issues have previously been reported and I have adjusted, and this is the first report on this for several years. It is not worth me changing this again on one report, as it may affect more users. John

Can you also check if you installed from within the zip file, rather than extracting first. This is known to cause strange issues. Any doubts, just re-install and make sure that you extract the files from the zip file before running the installer. You can also attach your InstallFSUIPC7.log file and I can take a look. Note that as a new user to this forum, you will have a very low limit for uploading files. If they won't attach directly due to their size, you can zip/compress them. Your upload limit will increase as you post more messages. John

Yes - after a restart, everything is working here, including key assignments. Yes, that is how the auto-start works. Ok, I will need to see your files to determine what the issue is. Some folks had connection issues with 7.4.5, hence the update. There weren't any changes that could affect key assignments though (apart from a minor correction where key assignments to presets selected from the Find Preset weren't being saved/stored correctly) so I am surprised at your issue.... John

Sorry, but what does this mean? Can you attach a screenshot please? So do you have this issue on only this profile? What about other profiles, or your general (none-profile) assignments - are these affected? Can you also please attach your FSUIPC7.log and fsuipc7.ini files. John

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...