John Dowson

Not sure what you mean by this - just use the latest release of each product. The PFC hid and com drivers are the same for FSUIPC5, FSUIPC6 and FSUIPC7, i.e. you use the same driver for each FSUIPC version,

Those errors are nothing to worry about - your PFC Throttle is detected and should be ok to use - what exactly is your issue? Note that the PFChid64.dll was also updated at the end of January so you should update this. The update was for PFC avionics stacks when using MSFS, so should not really affect you, but always a good idea to use the latest version if needing support. John

Download and install the latest PFCcom64.dll and try again...

Sorry, what does this mean? You can ignore that message. You can add a PFC.mcro file to override the default controls/events that are assigned to PFC devices - see the provided documentation for details. Of course - you are using the same PFChid64.dll...there is no difference in the handling of PFC devices in FSUIPC5 and FSUIPC6. Your PFChid64.log file does show these errors: which is probably your issue. Not sure what can be causing those - I will take a look, but tomorrow now. In the mean-time, please reboot and try again... Does it still work with FSUIPC5? John

You need to execute the calculator code to update the lvar. If the lvar (that holds the result) changes value, then you would receive the update value in exaclty the same way as you would get the value from any lvar (I haven't used the websocket server so cannot comment on that). Not sure what you mean by '...without the need of explicitly retriggering (polling) the calculatorCode... ' though... Anyway, just try it and see how you get on.... Johh

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