John Dowson

I cannot help with this - either try asking on the Asobo SimWorks Studios forum or ask on the MobiFlight discord forum about those KODIAK_100_IGNITION_SWITCH_* presets. John

You should familiarise yourself with that resource as it is the source of the presets in the events.txt file, and can contain additional information on how to use a preset (e.g. some presets require an update to an MSFS aircraft xml config file to work properly). You can also download the latest preset file as new presets are being added, as well as existing ones updated, all the time. Why? You need to register (which you should) to use those features. 'Add Preset' allows you to add your own preset to share with others in the Community (check not already available before doing this!), and the Export button allows you to export the events.txt file, which you can use to replace the one in your FSUIPC7 installation folder. Ok, that makes sense and shows that the lvars are working. You are using the presets KODIAK_100_IGNITION_SWITCH_ON (and _OFF, _TOGGLE). Your log shows that these are being triggered: If you look at the code for those presets, they use the TURBINE_IGNITION_SWITCH_SET1 event, not the lvar. The description of these presets also says 'Intended for latching switch.'. If presets don't work, then you need to ask about this on the MobiFlight Discord server - they manage the community-driven effort for these presets. But, if you know that the lvars work, as you have tested them, why don't you just use the presets that use the lvars (Starter Switch Off/Lo/Hi) instead? Or add the lvars to offsets and assign to the appropriate offset control instead, as you do with the C310? Note that you are using an old version of FSUIPC7, v7.3.6. Please update to the latest version, v7.3.7. Only the latest version is supported. There is also a beta version available in the Announcements forum - v7.3.8b. I will release this in the coming days (hopefully, pending info I am waiting to receive from PMDG). John

The WASM functionality is not available until you have an aircraft loaded and ready-to-fly, i.e. they are not available when in the MSFS main menu. You may also need to Enable the WASM functionality, but in the latest version this should be enabled by default. John

Is fs_com.exe also in your FSUIPC7 installation folder? If so, then maybe that is an FSUIPC c# client that requires that dll. Otherwise, I cannot see why that is needed. No. *.hvar files are only needed to make hvars known to FSUIPC. You can still use hvars (via calculator code or presets) without using such files. But these days presets are far easier to use as they are directly available for assignment. You should not need to download that file - it comes and is installed by the FSUIPC7 installer (although there is no problem downloading and using the latest one from MobiFlight). That preset is an example of a simple one that activates a hvar. Not quite... Your A320.hvar file should) just contain a list of hvars. To activate them via calculator code, you need to use the correct syntax, as the example you gave shows, i.e. (>H:<name>). But the FBW A320 has been around a while now and most (if not all) hvars should be available for use via presets, so there really shouldn't be a need to create your own, but you can of course do this if you want to. Some folks like to copy the presets for the aircraft that they use from the events.txt file to a myevemts.txt file and then delete the events.txt file. This will reduce the presets available to the aircraft that you fly, reducing the number of presets available in the drop-downs and making them easier to find. John

Then you are not searching/looking correctly: How are you doing this? This indicates that changing the lvar has the desired affect. But if thats the case, I don't know what your issue is as you have also said that this is not working, so I'm confused now... Of course not! $Param can only be used in preset definitions, when the value will be substituted with the parameter you enter when you assign. If using calculator code directly, you need to put in the value. So, try 0 (>L:SWS_ENGINE_Switch_Starter_ThreeState_1) or 1 (>L:SWS_ENGINE_Switch_Starter_ThreeState_1) or 2 (>L:SWS_ENGINE_Switch_Starter_ThreeState_1) But there is no need if you have already confirmed that changing the lvar has the desired affect. If you need further assistance, please attach a relevant FSUIPC7.log file (i.e. with Event logging and Button & Key logging activated, and also Debug level logging activated for the WAPI, and showing your issue) together with your latest FSUIPC7.ini file. Also, maybe try reading the section on the WASM module and how to use presets, in the Advanced User guide. John

I don't need to see your aircraft.cfg file. Your ini file shows that you have no assignments at all in FSUIPC. You have the FBW event file loaded, but are not using any events. These days there is no need to use the FBW custom events, as it is easier to use either lvars/hvars directly, or calculator code using the provided presets. Why? That is only needed if you are developing your own C# WAPI client. Presume this was added by FSUIPC, no? You should not manually edit this section. I have no idea what fs_com.exe is or does. Is that where your assignments are? If so, then you need support for this software for your issues. I can only help if you are assigning in FSUIPC, which your ini shows that you are not.... I suggest that you try using/assigning-to the provided presets for the FBW A320. Use the MF HubHob site (link in my previous message) to search for the preset you need for the function that you want to implement, and then assign to that. I don't recommend using the FBW event file these days - and if you do it probably needs updatung as I created this quite a while ago now and it is probably not complete (I will not be updating this file as it is basically redundant now). John

What do you mean by this? What are your assignments for this? Have you tried logging to see what is happening? Have you tried using the available presets for the FBW A320 (see https://hubhop.mobiflight.com/presets/)? For further issues, I would need to see your FSUIPC7.ini so that I can see your assignments, and a log file generated with Event logging activated, as well as logging for Buttons & Keys, and preferably with Debug level logging activated in the WAPI. Your log indicates that your hvar file is loaded ok, so that is not an issue. John

Looking at the MF HubHop site, I see 3 presets available for the Kodiak 100 starter switch: Starter Switch Off, Starter Switch Lo, Starter Switch Hi. These use the same lvar that your preset is using - L:SWS_ENGINE_Switch_Starter_ThreeState_1. There are a few other things you can check: - when you change the lvar value, does that stick (i.e. if you red/log the value afterwards, does it have thee value that you have set)? - when you change the state of the starter switch un the UI, does the lvar value change? Are any other events logged? - try setting the lvar using the WASM->Addons-<Execute Calculator Code menu option to set/change the lvar value. If that works, then there is a problem in your assignments. However, remember FSUIPC only provides the mechanism for you to assign such calculator code to controllers and have it sent to the FS for action. If the calculator code/preset doesn't work, I cannot really help with this. especially i do not own the aircraft. I cannot possible know how all functions work for all aircraft... If FSUIPC7 is functioning correctly, i.e. the code you assigned is being sent to the FS/aircraft (which logging would tell you), and the calculator code (or whatever you are using) is not working, then the best place to ask about this is either on the Kodiak discord server (https://discord.com/invite/Ns7GkWW) or on the MobiFlight Discord server. In this post over on avsim, one user indicated he could get most things working using lvars/calculator code except for the ignition switch, while another user indicates that he got everything working with the help of MobiFlight: https://www.avsim.com/forums/topic/614394-sws-kodiak-100-control-problems John

The MSFS PMDG 737 is quite different to the P3D version, especially in terms of control. You will have to review and redo all/most of your assignments as well as offsets that you may use. If you are also using the specific FSUIPC offset area for the PMDG 737 then many if these offsets have also changed, and the offset area is not available in the current FSUIPC7 release, although it is available in the latest FSUIPC7 beta which you can download from here: The custom controls have also changed, and now use the Rotor Brake control. Information available here: There are also many presets available for the PMDG 737 which may be easier to use than the custom/Rotor Brake controls/events. Note that in the latest beta, presets are available for assignment by checking the 'Select for preset' checkbox. You can view/search for available presets using the MobiFlight HubHop site (https://hubhop.mobiflight.com/presets/). John

Check that you have controllers disabled in P3D - if you don't, P3D has a tendency to automatically assign your controllers. If controllers are disabled, it may be due to aircraft - some complex aircraft don't play well with FSUIPC calibration due to priority levels of the events. If this is the case, assign using 'Send to FS as normal axis' rather than 'direct to FSUIPC Calibration' and don't calibrate (i.e. remove/delete the current calibration settings). With the latest version if ProSim, it may be better to assign directly in ProSim rather than in FSUIPC. BTW, you posted in the FAQ sub-forum where it explicitly states NOT for support requests. I have moved your post to the main support forum. John

Please see John

Please see John

Introduction The FSUIPC7 installer provides an Auto-Start FSUIPC7 with MSFS component that when selected should enable MSFS to automatically start FSUIPC7 when MSFS is started. However, many users have reported issues using this facility. This FAQ entry provides an overview of how this functionality is implemented, together with possible problems and solutions. As of FSUIPC7 version 7.4.12, two distinct auto-start mechanisms are provided: 1. Auto-start via the MSFS.bat file / Desktop MSFS link: the MSFS.bat file, usually called from the FSUIPC-installed MSFS Desktop link, is a simple batch file that starts MSFS, displays a splash screen while MSFS is loading (for 25 seconds), waits for 95 seconds, and then starts FSUIPC7. 2. Auto-start via the MSFS EXE.xml file. The installer adds an entry to the MSFS EXE.xml file and MSFS will start FSUIPC7 when ready. The MSFS EXE.xml file auto-start method is the preferred (and default) auto-start method. It is recommended to only use the MSFS.bat auto-start method if you have issues with the EXE.xml method that you cannot resolve. Note that the MSFS.bat method was the default auto-start method in FSUIPC7 version 7.4.12 only - all earlier and later versions use the MSFS EXE.xml method. If you have any issues with one auto-start method, simply re-run the installer and select the other auto-start method, and make sure only one auto-start method is selected. Note also that the MSFS.bat file auto-start may not work correctly in the following circumstances: 1. You have installed FSUIPC7 in a windows-protected folder, such as under Documents or Program Files. If you have installed FSUIPC7 in such a location, it is recommended to re-install into a non-windows-protected folder. 2. You are running FSUIPC7 with admin privileges. This should work, but you will have to grant permissions for this when FSUIPC7 is started, and the permissions confirmation box may not be visible (i.e. it may sit in your system tray and need to be opened). One downside of the MSFS.bat file method is that it does not take into account MSFS loading times, especially when the simulator is being updated. This can cause issues if the auto-tuning feature has been activated when MSFS is updating, or when it has longer loading times due to internet activity. This can cause the auto-start tuning parameters to be set to high, which can result in FSUIPC7 not connecting and not being available/active for some time after MSFS has reached the main menu, and even after you have an aircraft loaded and ready-to-fly. If this occurs, you should manually reduce the DetectToConnectDelayAuto ini parameter to a lower value and to force an auto-tune by setting StartUpTuningActive=Yes (see the Advanced User guide for details on auto-start tuning). EXE.xml Auto-start method: Background The auto-start facility provided by the FSUIPC7 installer uses a facility provided by MSFS2020 to start external applications by using a file called EXE.xml. This file is located in a location specific to your MSFS installation type, and will be the same folder that contains your MSFS UserCfg.opt file: for Steam installations, this file is located under %APPDATA%\Microsoft Flight Simulator\ and for MS Store (and DVD) installations under %LOCALAPPDATA%\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\ where %APPDATA% and %LOCALAPPDATA% are windows environment variables pointing to your user' AppData and AppData\Local folders respectively. Note that this file does not exist by default. It will be created by the FSUIPC7 installer if the file does not exist. If the file already exists, this implies that it has already been created, either by a previous run if the FSUIPC7 installer, or possibly by another MSFS client-application installer. When the FSUIPC7 installer has correctly created or updated this file, and when FSUIPC7 is the only application using this facility, your EXE.xml file should look something like this (your <Path> element will differ and contain the correct path to the FSUIPC7.exe): <?xml version="1.0" encoding="Windows-1252"?> <SimBase.Document Type="Launch" version="1,0"> <Descr>Launch</Descr> <Filename>EXE.xml</Filename> <Disabled>False</Disabled> <Launch.ManualLoad>False</Launch.ManualLoad> <Launch.Addon><Disabled>False</Disabled><ManualLoad>False</ManualLoad><Name>FSUIPC7</Name><Path>D:\FSUIPC7\FSUIPC7.exe</Path><CommandLine>-auto</CommandLine><NewConsole>False</NewConsole></Launch.Addon></SimBase.Document> Note that no line breaks are inserted in the <Launch.Addon> element. This is not an issue as white space is ignored in XML files, but for readability, I have manually added line breaks to this file as below: <?xml version="1.0" encoding="Windows-1252"?> <SimBase.Document Type="Launch" version="1,0"> <Descr>Launch</Descr> <Filename>EXE.xml</Filename> <Disabled>False</Disabled> <Launch.ManualLoad>False</Launch.ManualLoad> <Launch.Addon> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Name>FSUIPC7</Name> <Path>D:\FSUIPC7\FSUIPC7.exe</Path> <CommandLine>-auto</CommandLine> <NewConsole>False</NewConsole> </Launch.Addon> </SimBase.Document> If you have other MSFS applications that use the MSFS EXE.xml file to auto-start, you may find one or more other <Launch.Addon> elements, either before or after the FSUIPC7 entry, e.g. <?xml version="1.0" encoding="Windows-1252"?> <SimBase.Document Type="Launch" version="1,0"> <Descr>Launch</Descr> <Filename>EXE.xml</Filename> <Disabled>False</Disabled> <Launch.ManualLoad>False</Launch.ManualLoad> <Launch.Addon> ... </Launch.Addon> <Launch.Addon> <Disabled>False</Disabled> <ManualLoad>False</ManualLoad> <Name>FSUIPC7</Name> <Path>D:\FSUIPC7\FSUIPC7.exe</Path> <CommandLine>-auto</CommandLine> <NewConsole>False</NewConsole> </Launch.Addon> <Launch.Addon> ... </Launch.Addon> </SimBase.Document> EXE.xml Auto-start Method Problems and Solutions There are various issues that can cause FSUIPC7 to not auto-start with MSFS. The first thing to check is your installation log file - this is called InstallFSUIPC7.log and will be located in your FSUIPC7 installation folder, as well as a copy in the folder from where you ran the installer. Check this file for messages relating to the creation or the update of the EXE.xml file. The following message will be reported if your MSFS UserCfg.opt file could not be found (which determines the location of your EXE.xml file): "**** Cannot determine location of EXE.xml: FSUIPC7 will not start automatically with MSFS **** This can be due to one of the following reasons: You have not yet ran MSFS. This file is created the first time that you run MSFS. To resolve, run MSFS, exit and then re-run the FSUIPC7 installer. Your %APPDATA% or %LOCALAPPDATA% (depending on your installation type) environment variables are not set correctly. Check and set these environment variables (see google for further details). Anti-virus software is preventing the installer from seeing this file. To resolve, temporarily disable any anti-virus software when running the FSUIPC7 installer. Windows permissions are preventing this file from being accessed. Check the file and folder permissions on this file. Can you open the UserCfg.opt file in an editor? The installer has incorrectly determined the install type, i.e. it thinks you have a Steam installation when you have an MSFS installation, or vice-versa. This can happen if you have switched installation types, and is more common if you have switched from Steam to an MS Store installation. If this is the case, delete the file %APPDATA%\Microsoft Flight Simulator\UserCfg.opt and re-run the FSUIPC7 installer. If you have switched from MS Store to a Steam installation, then please check that the above file exists - remember you need to run MSFS at least once so that this file is created. If the location of the EXE.xml file can be determined, then the EXE.xml file should be either created or updated. If there are any issues with this process, one of the following error messages will be reported: Error loading EXE.xml file: <path-to-EXE.xml-file> **** Auto-start of FSUIPC7 with MSFS will not be enabled **** **** To resolve, remove or rename this file and re-install: <path-to-EXE.xml-file>**** Error re-loading EXE.xml file after removing FSUIPC7 entry: <path-to-EXE.xml-file> 'SimBase.Document' not found in EXE.xml file: <path-to-EXE.xml-file> These messages indicate that your current EXE.xml file is invalid or corrupt. This is usually due to another application installer writing an invalid EXE.xml file. To resolve, it is recommended to rename your existing EXE.xml file (e.g. to EXE.xml.invalid) and then re-run the FSUIPC7 installer. After completion, you can examine both your new/current EXE.xml file as well as the old one (that you renamed). You can then manually add (or copy) any other <Launch.Addon> sections from your old/invalid (renamed) EXE.xml to the new EXE.xml file created by the FSUIPC7 installer. Try adding these before the FSUIPC7 <Launch.Addon> section, but if you experience issues you can re-order (see 2 below). Please see above for the correct format of the EXE.xml file. If the EXE.xml file exists and is in the correct format and FSUIPC7 is still not auto-starting, then check the following: 1. Can you run FSUIPC7 manually? Try double-clicking the FSUIPC7.exe file (with or without MSFS running) in Windows Explorer. Does FSUIPC7 start, i.e. do you see the FSUIPC7 splash-screen displayed at start-up? If not, and if you get a windows error, then this is usually a sign that the correct VC++ redistributables are not installed - see the provided README.txt file on how to resolve this issue. 2. Check your FSUIPC7 installation folder, and make sure that you have not installed FSUIPC7 under a windows-protected folder, such as under Documents, Program Files or Program Files (x86). If you have, re-run the installer and select a non windows-protected folder for your installation. 3. Does your EXE.xml file contain multiple <Launch.Addon> sections? If so, try removing the other entries and see if it starts when no other entry present. If so, you can then add back in the other entries one-by-one - initially add these after the FSUIPC7 entry. If it fails to start when adding an entry (or the entry that you are adding fails to start), try re-ordering the <Launch.Addon> sections. If an entry for another program prevents FSUIPC7 from being auto-started, regardless of the order of the entries, then consider starting this application using FSUIPC's facilities to start/run external applications instead (registered versions only - see the FSUIPC7 Advanced User Guide for details). 4. Are you running MSFS as an Admin user? If so, set FSUIPC7 to also be ran as an Admin user (as well as any FSUIPC7 client applications that you may use). All MSFS client applications (and FSUIPC7 client applications) must be ran at the same privilege level. It is recommended to run as a normal user (i.e. not Admin) unless you have a good reason not to (and you know what you are doing!). 5. Check windows access permissions on the EXE.xml file and all folders under which this file resides. 6. If you have some anti-virus software running, check that this is not interfering by temporarily disabling and starting MSFS. If FSUIPC7 auto-starts when your anti-virus software is not running, you will need to add an exception or permissions to allow MSFS to auto-start FSUIPC7. If all else fails... If none of the above suggestions work, then I'm afraid that I am out of ideas and do not understand why MSFS cannot auto-start FSUIPC7. You can try reporting this to Asobo. You can also try switching to the other method of starting FSUIPC7, via the MSFS.bat file. To do this, you need to re-run the installer and manually selecting the MSFS.bat method in the Components selection page. If FSUIPC7 does not auto-start with this method, first open the MSFS.bat file and find the line that starts FSUIPC7 - it will look something like this: :: wait for MSFS to start (2mins) timeout /t %delay% /nobreak > NUL :: start FSUIPC7 start "" "D:\FSUIPC7\FSUIPC7.exe" "-auto2" N.B. The path shown to your FSUIPC7.exe will/may be different. Open a command terminal and try entering the start command in a terminal, e.g. start "" "D:\FSUIPC7\FSUIPC7.exe" "-auto2" (N.B. your path may vary) If FSUIPC7 does not start, you should get a windows error message or error number that you can look-up to rectify. Summary The FSUIPC7 auto-start component uses the EXE.xml facility provided by MSFS to allow MSFS to auto-start FSUIPC7. If the EXE.xml file is in the correct location and format, and FSUIPC7 still does not auto-start, there is nothing I can do. Check the recommendations above, and if all else fails try reverting to the old method of auto-starting MSFS, using the MSFS.bat file. Final Remarks I have nothing more to say on this issue other than what is provided here. Any new topics created in this issue will be closed/locked with a reference to this FAQ topic. You are welcome to comment on this topic, but any further requests for help with this issue will be ignored (I have nothing further to say on this topic!). However, any additional information or comments on how to improve this FAQ entry gratefully received. John

From the provided README.txt file: John

If nothing is logged, that just means the button is not using a standard FS control. Hvar activation and lvar changes are not logged (although the latter can be). I cannot help if the provided hvars don't work as advertised - FSUIPC looks to be sending the commands as configured, so if this is not working as expected then you need to ask about this either on the Asobo forum for this aircraft. However, rather than using the hvars directly, why don't you use the MobiFlight presets for the H145? There are currently 263 presets available for this aircraft. You can install the MF events.txt file using the FSUIPC7 installer, or download the latest version from the MF HubHob site (https://hubhop.mobiflight.com/presets/ - you need to create an account). You can also copy the presets that you want to use to a myevents.txt file instead, and remove the events.txt file so as to not overpopulate the controls drop-down menu (as there are > 7000 presets available!). John

Hi Leo, There is no concept of 'profiles' for the WideClient buttons page. You could create an initial page with the aircraft selection with "Go To" buttons, and then implement the buttons for each aircraft in separate (and also possibly multiple) pages. You could then select the top-level button page for the aircraft that you have loaded when started. Cheers, John

Logging is one way to determine the parameter, otherwise you can use the SDK header file. This has not been published yet, but you can use the P3D737 header file if you have that. The SDK for the MSFS PMDG 737 should be published in the next update. There is a guide in the FAQ section on how yo calculate the Rotor Brake parameter codes: John

I don't see why not, but as you assign these with your SIOC software (and not in FSUIPC) I don't really know. If they are button-type rotary encoders, you should be able assign the buttons to send the appropriate control or preset using those offsets. Not sure how you would do this if they are axis-type encoders though... John

This functionality is available in the latest beta, v7.3.8b, if you would like to try it, available here: John

This has been released in the latest FSUIPC7 beta, v 7.3.8b, available from: John

This sounds like the joystick ids, assigned by windows, have changed. The issues that occur when this happens can be avoided by using the JoyLetters facility (see the User guide for details). Rather than deleting your assignments and starting again, it should be possible to just switch the device' ids back by editing the FSUIPC6.ini. If you would like to try this, please attach your FSUIPC6.ini and FSUIPC6.log files and I will take a look and advise. Otherwise, to delete all your assignments, you can either just delete (or better to just rename) your FSUIPC6.ini and let a new default one be created - you will lose all your assignments to all controllers if you do this, as well as any general settings you have changed. Otherwise, you could open the FSUIPC6.ini file in an editor and manually remove any assignments - they should be relatively easy to identify. John

Good to hear - thanks for the update and the configuration details. It looks like something other than the lvars need updating. I am surprised that there is not a control, standard or custom, that cannot be used for this - hopefully this will be addressed in a future aircraft update. I remember issues with the throttle un the TBM930 but I thought they had been resolved (or maybe that was with using a mod...). I'll check this one (as I have access) next week and let you know. Make sure this change is in the WASM persistent storage area, and not un the FSUIPC_WASM.ini located under the Community\fsuipc-lvar-module folder as that will get overwritten the next time you update FSUIPC7. John

The presets use calculator code, and much of the calculator code uses the custom events, as well as lvars. The custom events/controls for the PMSG 737 in MSFS use the Rotor Brake control, with the parameter indicating the actual control/event. You can see the parameters used by looking at the calculator code for the presets (in the events.txt file, or, better, on the MF HubHob site https://hubhop.mobiflight.com/presets/). PMDG have not published the SDK yet - this should come in the next update, due any day now. I don't know. You need to work out if its not configured properly (i.e. the preset calculator code is not being sent to the FS) or if it is the preset/calculator code that isn't working correctly. For the former, I need to see your FSUIPC7.ini and FSUIPC7.log files, the latter with Event and Extras logging activated, and with Debug logging enabled in the WAPI (add the line LogLevel=Debug to the [WAPI] section of your FSUIPC7.ini file). If its the latter, you need to ask about this on the MF Discord server. Note also that there is an FSUIPC7 beta out with the additional offsets for the PMDG 737 populated (for read-only). See John

If the installer cannot see that file, then this must be due to one of three reasons: 1. Your APPDATA environment variable hasn't ben set correctly. To check this, open a command prompt and enter the command: dir "%APPDATA%\Microsoft Flight Simulator\UserCfg.opt" Can you see the file listed doing this? If not, you need to ensure that your APPDATA environment variable is being set correctly. 2. Anti-virus software is preventing this file from being accessed. Check any messages/warnings in any anti-virus software that you are using and maybe disable while installing. 3. Windows access permissions are preventing the installer from accessing this file. Check the windows permissions. Can you open this file in a text editor? Failure to determine the location of this file results in the WASM module not being installed and the the auto-start component not being enabled. If you cannot determine (and correct) why the installer cannot see this file, both of these components can be installed manually. I can provide further instructions on how to do this if needed. John Later: note also thar this file is only created the first time you run MSFS, so if you tried to install FSUIPC before running MSFS, try again

What does 'No mcro file' mean? Why not? If the list lvars/hvars menu items are available, then so should the items to activate hvars and to execute calculator code. Try setting the WAPI LogLevel to Debug by adding the following (in bold) to your FSUIPC7.ini file: Then check your log file (or, better, open the logging console using Log->Open Console) and you should be able to see what is happening when you try to activate hvars or execute calculator code. John