John Dowson

The log file you attached shows that FSUIPC7 was not able to acquire a simconnect connection to MSFS. Not sure why this is, but can you please change the DetectToConnectDelayAuto ini parameter (in the [General] section of your FSUIPC7.ini file) to the following and try again: DetectToConnectDelayAuto=120 Please reboot your PC first. You also seem to have a preset that exceeds the maximum defined length: This is in the events.txt file but is NOT an MF event. Did you add this? You should not modify the events.txt file (as any modifications will be lost when you update), but use the myevents.txt file instead. Please see the documentation (Advanced User guide, WASM section). John P.S. Please STOP posting images. They are useless, especially as you keep posting images of things you don't see.,., I ALWAYS prefer to see your files and not screenshots. Only post images when asked for.

A lot of posts, and of images showing that the lvars have been loaded. But you say they are not...please show me/attach your FSUIPC7.log file. The current WASM version included in FSUIPC7 version 7.4.16 is 1.0.5. If you are using FSUIPC client apps built with an earlier version, you will get version incompatibility warnings, but they should work just the same as the API has not changed. John

I don't know this AP - which aircraft is it in? How do you do this (synch the HSI heading bug) on the AP (in the VC)? HEADING_BYG_SET is an event, or FS Control, not a simvar. You can assign to this, but you need to provide the value/parameter. If no control (hvar, lvar, preset, input event) is available and you want to do this, you would need to write a simple lua script to get the bearing and then set it. The script would read the HSI BEARING from offset 0x2FA8 and then send the HEADING_BUG_SET event/control: bearing = ipc.readUW(0x2FA8) ipc.control(66042, bearing); However, offset 0x2FA8 should hold the HSI BEARING simvar, but this is documented as untested with comment 'Doesn’t seem to work. Feedback?'. So, I would first monitor this offset (using FSUIPC's offset monitoring facilities) to verify that it is indeed holding the correct value.

That looks ok. Maybe the preset isn't working. I can test it here a bit later. Which aircraft have you tried with? Have you tried any other of the camera presets?

For view controls, you can try the available FS controls for switching views: NEXT_VIEW PREV_VIEW NEXT_SUB_VIEW PREV_SUB_VIEW However, if you want to assign a key or button to jump straight to a specific view, you gave two options: - try the available presets (see https://hubhop.mobiflight.com/presets/ and search for Camera). These are the generic camera entries available in the MF evemts.txt file: - try the camera offsets: 0x026D - Camera State 0x026E - Camera Substate 0x026F / 0x0270 - Camera View Type and Index Best to log these first to see what values they hold for the views you want to access via a key or button press. You can then either assign to update these offsets to the relevant values, or create a preset to do this. Also please see other support requests on controlling views. Start with this one, which also contains links to several other similar topics: That should be enough to get you started. If you require further assistance, let me know.

By 'no startups', do you also mean FSUIPC7 or just the programs that FSUIPC7 starts? When you say 'manually started;, do you mean FSUIPC7, or the programs that FSUIPC7 starts, or both? Did you should down FSUIPC7 and all other programs before doing this, or just FSUIPC7? Was this when using RunIf instead of Run? I think your problem lies with these additional programs being started, and not with FSUIPC7. It seems that two of your programs are trying to access the same port, or one program that is being ran twice. I suggest you check your ProSim / SIOC configutation. I also asked Pete about this - this is his reply: John

License now available for download in the first post in this topic.

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.