John Dowson

There have been many reports of FSUIPC7 causing MSFS to crash, and my response is always the same: FSUIPC7 is a separate executable, running in a separate process, and in no way should be able to cause MSFS to crash. It communicates to MSFS via the SimConnect API, provided by MSFS, and so if there is an issue here it is also an issue for Microsoft / Asobo. There is just no way or possibility for me to debug or look into an MSFS crash. FSUIPC7 does include the FSUIPC WASM module which runs in the simulator, but the whole point of a WASM is that it is sandboxed and so should also not cause MSFS to crash either. I can only suggest two things: - enable SimConnect logging and see if you get any SimConnect errors reported - this may give you a hint as to what the issue is - raise a CTD issue with Asobo Sorry I can't be of any more help with this. John

Yes - it has 4684 lvars on first load - maybe more are created later... I have updated now to handle up to 9198 lvars. I don't think there is a need for an ini parameter to specify the number of lvars used. I will release this as a beta in a few days (next week sometime) - I will post here again when available. John

Yes, after a short delay - as I said: Or do you mean something else? John

Just tested this and this is the case. You can therefore create your lvar when you initialise and then issue a reload to make the lvar known to the WAPI. Then, you can execute the calculator code and write that value to an lvar (in the calc code, as shown), and the value should be available in that lvar, after a short delay - 200ms or so by default with a 6Hz refresh rate, but sooner if you increase the refresh rate. John

Ok, yes it does. I will update to allow more lvars by default in the next release, up to 4088. I will also look into adding a new WASM (and maybe WAPI) ini parameter so that the max number of lvats available can be set by the user, up to a hard-coded maximum of 9198 - but maybe not in the next release, I will see... Yes, some lvars are created only once used for the first time. currently you have to issue a reload command when this happens, so that the lvar scan is done again. I have been thinking of doing this automatically in the WASM, so that new lvars are automatically pushed to clients (including FSUIPC) when they are detected. I will look into this as well. John

No. You can create and read lvars by using offset 0x0D70 (or via lua). Maybe also using calculator code - I think if you execute a calculator code string that writes to an lvar and that lvar doesn't exist, it will be created. It should be straightforward to test this using FSUIPC's WASM menu: execute dome calculator code that writes a value to a non-existent lvar, issue a reload and then list the lvars to see if the one you created exists with the value that you gave it. To get the value of a calculator code string into an lvar, you would just execute the calculator code string: (<CalcCodeString>) (>L:myLvarToHoldCalcCodeStringResult) Probably bit misleading...FSUIPC doesn't create lvars, but does provide facilities for such. After you create the lvar (however you create it), you will need to issue a reload command to get the updated list of lvars, containing the new lvar you created, together with its current value. John

As explained in this post, if you get 3066 lvars loaded it is best to just restart MSFS with the aircraft loaded that you intend to use, and you should see the number of lvars reduce.

Did it not work installing using that method (i.e. with the add-on.xml component unchecked during installation)? If not, due you know what the difference was to the DLL.xml as changed/updated by FSUIPC or with your DLL.xml edit - was it just in a different location maybe?

That is strange... Can you show me a log file please, with logging for Axes Controls activated. Start MSFS / FSUIPC7 and activate logging for Axes Controls and also open the logging console window, load your aircraft and then move the rudder through its full range. Do you see any rudder event logged in the console? Then go into the Axes Assignments panel and detect the rudder, close and move the rudder again. Do you then see the rudder events logged? Exit FSUIPC7 and attach your FSUIPC7.log file and I will take a look. Simpler to just use: John

It's John no Pete - Pete retired several years ago. Can you please show me / attach your FSUIPC7.log and FSUIPC7.ini files and I will take a look. Do you have the saitek drivers or software installed? If so, best to uninstall/delete those and let windows install its own drivers.

No. However, there is a way around this. You can create your own lvar, have the calculator code write its result to an lvar, and then read the lvar value (or add it to an FSUIPC offset). As there is a relatively simple workaround (explained above), I am not planning to implement such a feature at the moment, although it could be something I could consider adding in the future. Regards, John Later: ...and many (most?) MF output presets are just the value of an lvar anyway - for those you can just read the lvar directly and not use presets. The one you are using uses a combination of lvars and simvars (a:vars). Rather than using calculator code, you can get the lvar and avar values (directly or via offsets) and embed the calculator code in your code.

You can compress/zip it. The log file shouldn't be that big anyway - just run MSFS/FSUIPC7, check all logging is disabled, load an aircraft and then exit FSUIPC7 and attach both your log and ini. Please also review what I said in my previous comment, and answer the questions....

Which joystick? Your ini only shows a Saitek Pro Flight Yoke connected, you have assignments to device A which is missing. and have a letter assign to a Speed Wheel 5 Pro but this has no joy id number for some reason. It would help me to understand things better if you could also attach your FSUIOC7.log file. Note that you also only have assignments in your PMDG profile. Have you been manually editing your FSUIPC7.ini file? It looks like it... To which device have you assigned your buttons? I cannot tell as it looks like you have manually removed the name and GUID of device A... Note also that if using Saitek devices, you should NOT install their drivers or software. If you have, you should uninstall and delete them and let windows install the default drivers. Please review this and if you still have issues, please attach both your FSUIPC7.log and FSUIPC7.ini files. John

👍😎

If you had a steam install and changed to an MS Store install, you need to manually delete or rename the steam version of the UserCfg.opt file so that an MS Store installation is detected, otherwise a Steam installation will be assumed. John

The community folder location is taken from the InstalledPackagesPath property in your MSFS UserCfg.opt file. This is located under your user account folder under the following folder for steam installations: AppData\Roaming\Microsoft Flight Simulator\ and under one of the following folder for MS Store installations: AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalState\ AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\ If you take a look at the InstallFSUIPC7.log file, this should tell you the location of the one used. But you shouldn't need to change this manually - this should have been updated automatically if you re-installed into a different folder.... John

This seems like the WASM hasn't been installed or enabled. Can you show me your FSUIPC7.log file. If you are not using the latest version, 7.3.16, please update and try again first. John

Try listing the available lvars using the Add-ons -> WASM -> List Lvars... menu option. If the lvar isn't listed, it cannot be directly used as an lvar. Also note the number of lvars loaded (will be displayed in the FSUIPC7 main window). If you have 3066 lvars loaded, then you have reached the limit and the lvar you are trying to access most probably has an id > 3065. Any aircraft should not have that many lvars, but the problem is that MSFS doesn't clear lvars from previously loaded aircraft, and so the number of lvars seen/loaded increases each time you switch aircraft. To get around this, if you switch aircraft you should exit MSFS (after changing aircraft) and restart, so that the aircraft you are flying is the only aircraft loaded, and all lvars seen will be for that aircraft - and there should be < 3066! That is because you can use lvars via calculator code without them being known to FSUIPC. So, another way to use an lvar without this problem (i.e. without having it loaded by FSUIPC) is to create a preset for it. See the Advanced User guide for details, but basically you just add a line with the following format to a file called myEvents.txt: <preset name>#<calculator code> So you could add MD80_Start_Switch#536870912 5 + (>L:overhead_event, number) or maybe MD80_Start_Switch#$Param (>L:overhead_event) or even MD80_Start_Switch#536870912 $Param + (>L:overhead_event) and then assign to that preset using the appropriate parameter. Also, check for existing presets on the MF HubHop site (https://hubhop.mobiflight.com/presets/) - there don't seem to be any specifically for the MD-80, but there are currently 62 presets available for the MD-82, which may also apply to the MD-80. All MF presets are available for assignment in FSUIPC7, and if you create your own preset I recommend that you also submit this to the MF HubHop site for others to use.

👍

But these are the SAME details that were in your registration email that you should have been using all along. If you weren't using those details, what were you using when it failed? AND, if the key file containing your registration details was in the correct place (i.e. your FSUIPC7 installation folder) then the details in the registration page would have been pre-populated from the key file. Try running the installer again and you will see that the registration details are pre-populated. Therefore, I have no idea what you were doing but you were certainly not following my instructions... Because that is not an error. You move a controller axis and then it will be registered Notice it says MOVE LEVER aside the top two boxes - when you move an axis lever, they will change to Joy# and Axis# once FSUIPC detects an axis movement., and then you can assign that axis to a control, as explained in the User guide. Every now again someone has issues with registration and it is ALWAYS due to either user error (i.e. entering the wrong information into the registration fields) or due to the VC++ redistributles being out of day. Your issue was the same, although you don't seem to realise this. Please do what I ask - re-run the installer, and you will see the registration fields pre-populated from the key file, and they should register ok. You can either uninstall, delete everything and then re-install from scratch, and if you enter the correct information in the correct fields then you will see how easy it actually is. I have no idea why YOU are having such difficulties. I hope you understand the I am extremely frustrated in wasting so much time on this type of thing when there is no issue and it is down to user error or misunderstanding. I also provide an extended trial license so that you can try FSUIPC BEFORE purchasing, which I encourage everyone to do. I have explained your mistakes and is up to you to correct them and to understand what you did and are doing wrong. FSUIPC has been going for around 20 years now with thousands of happy users. I really don't understand why you are having such issues and why you cannot follow my simple advice. What you say just doesn't make any sense. As your 'installation issue' is now solved, I am locking this topic. I suggest you do as advised and try to understand what you have been doing wrong, as your key is obviously valid and accepted,... John

Ok - good luck! Cheers, John

There are two methods to get P3D to use FSUIPC - either using an add-on xml file or by using P3D's DLL.xml. By default, the installer uses the first method. If having issues with this, then you could try using the 2nd method, by unchecking the add-on.xml component when selecting the components to install. However, you shouldn't need admin privileges for the add-on.xml. This is created in an FSUIPC6 sub-folder of the Prepar3D v5 Add-ons folder (or v4 for P3Dv4), which is usually created by P3D under the user' %USERPROFILE%\Documents folder. So, first check that folder exists. I have also attach an example add-on.xml (you will need to change the Path to point to the location of your FSUIPC6.dll: add-on.xml Further details on this can be found here (for v4, v5v is the same except for the folder name): https://www.prepar3d.com/SDKv4/sdk/add-ons/add-on_packages.html If using the DLL.xml method, the DLL.xml file is created (or updated if it already exists) under the user' AppData\Roaming\Lockheed Martin\Prepar3D v5 folder. The format of this file is defined here: https://www.prepar3d.com/SDKv4/sdk/add-ons/add-on_configuration_file_formats.html That folder should be for the add-on.xml file only (is it there?). If you installed FSUIPC6 in that folder, please re-install (this will uninstall the current installation first) and select a non-windows protected folder (i.e. not under Documents and not under Program Files or any other windows-specific folder). Once you have done that, check the add-on.xml file is correct. If it is and FSUIPC isn't loading, switch to using the DLL.xml installation method. You can attach the InstallFSUIPC6.log file for each each installation type (add-on.xml and dll.xml) id you continue to get issues and I will take a look. John

You have assigned a single axis to THROTTLE_AXIS_SET_EX1 and THROTTLE2_AXIS_SET_EX1. This is not correct - either assign to THROTTLE_AXIS_SET_EX1 only, or assign to both THROTTLE1_AXIS_SET_EX1 and THROTTLE2_AXIS_SET_EX1. The assignments in the referenced post were for using two separate throttle axes, one for throttle1 and one for throttle2. If you are only using one axis, you will only have one assignment. Not sure why you have an FSUIPC profile called FSUIPC - you should change this or remove it. Change this to This will catch more variants, i.e. when using other liveries. Any further issues, please attach your full FSUIPC7.ini file rather than pasting extracts. Thanks, John

First, it looks like the GUIDs of your JAY Rudder and Redbird Alloy YK1 changed at some point, You re-assigned to these devices again when this happened. You don't need to do this - it is easier/quicker to update the [JoyNames] section to handle such changes. You don't have to do anything now, but remember this next time - or post your ini here and I can update for you. For now, I have cleaned your ini to remove these missing devices and the assignments to them - please use the attached ini: FSUIPC7.ini For the CRJ, you need to assign with 'Send to FS as normal axis' and use the Throttle1 Axis Set Ex1 and Throttle2 Axis Set Ex1 controls/events. You should create a specific profile for this - i.e. in the axis assignment tab, check the Profile Specific checkbox, create a new profile (you can import current axes assignments into the profile), and then clear the throttle assignments and then assign to those controls. You should then go to the calibration tab, again check the Profile Specific checkbox, and then re-calibrate the throttles on page 3. Once that is done, you should be able to calibrate further in the EFB, if needed. I can't see how throttle1 and throttle2 can be different as the assignments and calibration are the same. However, I suggest you also create another profile for the 737, as many controls are also very different for this aircraft. If you have issues with the throttle then clear your current throttle assignments and assign again using 'Send to FS as normal axis' and use the Axis Throttle1 Set and Axis Throttle2 Set controls. Again, after assigning go to the calibration tab and check the Profile Specific checkbox and check the throttle calibration. If you still have issues, please attach your updated FSUIPC7.ini file. John

Please first check that there is an FSUIPC7.key file in the installation location (and this hasn't been renamed to FSUIPC7.key.txt, which sometimes happens). Try with both key files - the trial one and the one containing your license (the one I sent you via a PM). Any issues, please show me / attach your FSUIPC7.log file. For all auto-start issues, please see