John Dowson

There is already a preset for the alt sync, XCub Ap Alt Push, whose preset code does some thing similar to that proposed for the heading: (A:INDICATED ALTITUDE, feet) (>K:AP_ALT_VAR_SET_ENGLISH)

Can you please activate logging for Buttons & Keys and show me / attach a FSUIPC7.log file from when the keys don't work and I will take a look. John

Sorry but I didn't have time to look into this today. I am now on holiday, back in Tuesday 6th (in 4-5 days), and will take a look then. Sorry for any inconvenience, John

Thanks @ark1320 - should have checked the MSFS documentation on this. Hopefully @Guido can try your preset using PLANE HEADING DEGREES MAGNETIC simvar. Any further issues, I will take a look next week (back on support on the 6th). John

I tried that preset in the PMDG 737 and it is working as expected here. Have you used any presets before, and if so were they working? Do you have the WASM installed and enabled? Could you please attach your FSUIPC7.log and FSUIPC7.ini files and I will take a look. Note that i am on holiday from this evening, back on support on Tuesday 6th. So unfortunately I will not be able to look into this further until later next week. Also ,ale sure that you are using the latest version of FSUIPC7, version 7.4.16. If you install that and accept the defaults, the WASM should be installed and enabled, but if not enabled you can enable from Add-ons->WASM->Enable. Try that and any issues attach those files and I will take a look next week. John

Probably a better solution rather than using the HSI BEARING simvar unless this is correct. If so, you could use the following preset: SYNC_HDG_BUG_TO_HSI_HDG#(A:HSI BEARING, degrees) (>K:HEADING_BUG_SET) Suggest @Guido tries both - add them to your myevents.txt file (create this if not present) and try them both. I will take a look later if I have time, but am rather busy and am on holiday from tomorrow until the 5th (inclusive), so it may be next week. John

Still a lot of reconnection attempts though. Looks like it takes a long time for your MSFS to start-up and get to the main menu... Try increasing the parameter, i.e. DetectToConnectDelayAuto=400 And when you get to the main menu in msfs, take a look at FSUIPC7 and wait until it connects before you do anything. This will then tune that parameter for the correct value for your system. John

Don't worry about it - its not an issue. I have checked further and it is an issue with this preset defined in MobiFlight. It will be ignored. John

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