John Dowson

Please show me your log and ini files. Changing Run to RunIf should noy effect the start-up, just not start the programs if already running. So you only get the COM errors when ProSim is set to use FSUIPC? I am not that familiar with ProSim, but I think SimConnect is the recommended setting these days. Pete uses ProSim - I will ask him to take a look... But earlier you also said 'Using Simconnect in Prosim does the same.' - so what else has changed? Exactly the same as Run. The only difference is that RunIf programs are not ran if they appear to be already running. So changing from Run to RunIf should have no effect if the programs are not already running. So if no programs were started, then either they were running already or there is an error somewhere (hence the need to see your files).

Ok, but strange - I don't know what could have caused this. There are two auto-start components included in the installer, via the EXE.xml file (the default) and via using the MSFS.bat file. You should first try with the default method. When using this, FSUIPC7 should be auto-started however you start MSFS. If you use the MSFs.bat method of auto-start, you must use the MSFS desktop icon installed by the FSUIPC7 installer to start both MSFS and FSUIPC7. Please see the following FAQ entry for all auto-start issues. Usually, if the EXE.xml auto-start method isn't working, its because another add-on has corrupted the EXE.xml file. John

You shouldn't need to do that - please show me your FSUIPC7.log file showing this issue, preferably with the offset for the FMS power logged. What was the issue? There has been no change to the auto-start functionality for quite a while - the last change was switching the default auto-start method back to using the EXE.xml in version 7.4.13. You can try that, The EXE.xml file will be recreated by the FSUIPC7 installer. Maybe check it first as it may have entries for other programs. Please see the FAQ entry on auto-start for all issues: John

If they are displayed as 32-39, then they are POV buttons. You cannot currently use these for button conditionals. I could maybe allow this, but it has always been like this, so probably for a good reason. I could look into changing this, but probably better if you could use other buttons. Seems strange to use the POV for button conditionals... But why do you need to distinguish? If they have separate profiles, which they should, then it is the profile that distinguishes them. If you have a lot of profiles or want to distinguish them easily, switch to using profiles-in-separate-files, by setting: UseProfiles=Files in the [General] section of your FSUIPC7.ini. This will then create a separate Profiles folder under your FSUIPC7 installation folder, and each profile will be written to a separate file. The main FSUIPC7.ini file will still contain the [Profile.xxx] sections. John

Probably not...but buttons 32-39 that are not POV buttons should register as 132-139. So, as I said, try 132 - or see what the button you are trying to use is registered as in the button assignments panel.

Ah... there is no such button number as 32. Well, there is, but button numbers 32-39 are POV buttons and have a special meaning. For other buttons > 31, you need to add 100, so try button number 132. The easy way to check way the button number is is to see what is registered in the button assignment UI panel when you press the button - use that number. John

Ah, its ok - I can see the issue now. Looks like compound button conditions have not been updated to use button numbers > 31. I will look into this and hopefully provide you with a new version to test, most probably tomorrow now. John

That is very strange...can you please show me/attach your FSUIPC7.ini file. Why are your index numbers starting at 1001? This shouldn't cause issues, but you should start from 1 or 0 really. I can add that line to my button assignments and I don't get an error, so something else must be going on.... John

I have checked this in several default aircraft and also the PMDG 737 & 777, and the FBW A320 and cannot reproduce. It therefore looks to be either specific to the Fenix or your system. Let me know if this applies to any other aircraft or is specific to the Fenix.

This certainly shouldn't happen and haven't seen this ... but I will check this here. Can you please check with another aircraft to see if this is specific to the Fenix. I don't have this aircraft so cannot test with that here. John

What fix? This FAQ entry explains how auto-start is implemented. Then read this article and check your files.... To start FSUIPC7 manually, you should start the FSUIPC7.exe, not the batch file. Please read this article - it explains how auto-start works, and what files are changed and how they should look. And there are two auto-start methods - the EXE.xml and via the MSFS.bat. It is better to use the EXE.xml method (the default method), but if you cannot get that working then try the alterative method. John

I have checked the details in that order and they validate just fine here. I have PM'ed you a key file - please try this. Re-run the installer and see if it validates. Also, try running FSUIPC7 and see if it is licensed/registered. John

If you are running MSFS with admin privileges, are all your other programs also set to be ran with admin privileges? Is the log file attached from the first start, when it failed, or the second start? And how come FSUIPC didn't start the programs - did you disable this in the ini file? No, you shouldn't have to do that. And I don't see how FSUIPC can be doing anything as all it is doing is starting programs. Could it be that some of these programs are already running when you start FSUIPC7 and then two copies are running? You could change the Run commands to use RunIf, which will prevent the programs from starting if they are already running, Other than that, I cannot understand why the MCP would die. Do you still get the the com error in the ProSim log when this happens?

I don't understand why you are having difficulties. Assigning your Bravo X/Y axis with Send direct to FSUIPC Calibration and using the Throttle1/Throttle2 controls should work (and also calibrate on page 3 of the calibration tab - you probably need to reverse as well). If that doesn't work, please show me / attach your FSUIPC7.ini file. I have noticed that when the throttles are in the idle position, the engine hud shows around 23%, which I guess is idle.

Yes, sorry - I should have spotted that!

Can you also please attach your UH1.ini profile file please? Are your axes calibration not profile specific (the profile-specific checkbox is not checked)? How do the in/out values move when you move the axis? Does this apply to all aircraft, just helicopters or just specific helicopters? You also have a lot of joystick/controller scans in your log file - do you know what is causing these?

Just assign to those presets via the UI key assignment panel. Check the Select for Preset checkbox and then the Find Preset.. button and navigate to the preset you need from the MobiFlight root. You can also search for available presets first using the MobiFlight HubHop site: https://hubhop.mobiflight.com/presets/

First check if the calculator code is being sent and applied in the FSUIPC WASM module (presumably you have that installed - if not, you need to install that). To do this, set Debug level logging (via the FSUIPC_WASM.ini file) and check the FSUIPC_WASM.log file to see if the command/code is logged. Probably. Hvars are only known (i,e, loaded and provided) by name if they are given in an aircraft-specific *.hvar file. However, they don't need to be known if using them via calculator code.

Licenses sent.

Are you using complex aircraft, many add-ons and/or add-on scenery? Could you also please attach your FSUIPC_WASM.log file if you get a WASM crash (preferably with Debug level logging enabled via the FSUIPC_WASM.ini file) An issue has been identified when scanning for lvars that can cause a crash, but this looks to be an issue in MSFS, not FSUIPC. There is a long discussion/investigation on this issue here: To reduce the chance of this crash, try setting the WASM ini parameter: LvarScanFrequency=0 and also maybe increase the LvarScanDelay parameter to 8 or 10 seconds: LvarScanDelay=8

Do you mean you updated the VC++ redistributables? Can you let me know your order number and I will check your details here. Do NOT post your key details!

Yes - see the ini parameter OpenOnStart:

Can you please explain what you mean - is your throttle recognized? Can you show me / attach your FSUIPC7.log, FSUIPC7.ini and FSUIPC7.JoyScan.csv files. John

👍😎

Also I see you are running FSUIPC with elevated privileges: Make sure you are also running MSFS and all other programs with elevated privileges, otherwise they won't connect. Always better to run with standard privileges unless you have a good reason not to. John