John Dowson

Now available: John

It is most probably due ti the name of the file - it must be a substring match to the name of the aircraft as known by FSUIPC. To see what this name is, open your FSUIPC7.log file and look for the logged name, e.g for the C172 it logs the following: 52406 Aircraft="Cessna Skyhawk Asobo" so I would name the hvar file Skyhawk,hvar. Also be aware that it is far easier to write a preset to use a hvar than messing around with hvar files. For example, to create a preset for the vision jet for the H:checklist_scroll_up hvar, create a file called myevents.txt and add the following line: VisionJet_CheckList_Scroll_Up#(>H:checklist_scroll_up) In fact, you don't even need to do this as a preset already exists for this, called SF50 Checklists Scroll Up. You can assign to this directly by checking the Select for preset checkbox in the assignments dialog. Please see https://hubhop.mobiflight.com/presets/ for a list of available presets fir the Vision Jet - there are currently 103 available. John

See https://hubhop.mobiflight.com/presets/ Please read the documentation on the WASM and using presets, in the Advanced User guide. John

Try changing aircraft and then restart... Note that the reload function shouldn't be needed in the next version of the WASM / WAPI, as it will periodically (at 6Hz) scan for new lvars and automatically push them to clients if/when found. I will release this version, as well as an FSUIPC7 7.3.17-beta, later today. The total number of lvars supported will also increase from 3066 to 9198. John

I have provided functionality so that you can add any simvar (or A:type variable) to a free FSUIPC offset - see the Advanced User Guide section Adding Simulator variables (simvars) to FSUIPC offsets on page 34. I added this functionality as I am not planning on adding any more simvars to offsets unless they are general simvars and used by many aircraft (and also have been requested). It should be relatively straightforward for you to add the simvars that you want - TURB ENG FUEL FLOW PPH:5 and TURB ENG FUEL FLOW PPH:6 (or possibly TURB ENG CORRECTED FF:5 and TURB ENG CORRECTED FF:6). If you have difficulties (after reading the documentation and trying for yourself) then post again and I can assist. John

Btw and fyi, the execute_calculator_code function is a Gauge API function, not a simconnect function. The SimConnect ClientData areas are used to communicate from the Client to the WASM (that implements the Gauge functions) and back, and so the underlying mechanism is inherently asynchronous.

The best way to do this would be to handle the throttle assignment in a lua script. You would assign your throttle axis to a free FSUIPC offset, and the lua script (which should auto-run) would monitor this offset (using event,offset), perform any calibration needed and then send the appropriate throttle axis control to the sim (using ipc.control). The script could also monitor for the button/switch (using event.button) and set/clear a flag when the switch is pressed/released, and this flag can be used in the function that calibrates the throttle offset value, so that it can be calibrated differently depending upon whether the flag is set or cleared. John

Please try the trial license before purchasing, available here. I cannot advise on what PFC devices are supported (you need to try them). The MSFS 40th Anniversary edition is just the latest release of MSFS2020, which is supported by FSUIPC7. All versions of this are referred to as MSFS2020 (or just MSFS), to distinguish it from FSX. Also, as your question is related to FSUIPC7 / MSFS, you posted in the wrong forum - there is a specific sub-forum for FSUIPC7/MSFS. I will move your post there. You probably need to use the PFCcom64.dll, and without the serial to USB adaptor. If using the adaptor, you could try the PFChid64.dll, There are different drivers for com and usb devices - not sure if they work when using an adaptor though, you will need to try this. John

That's unuseable for me. As well as what Paul has said, your original question, and title of this topic, is how to get values back from a simconnect execute_calculator_code call - I explained that this was not possible but there is a workaround - you write the result of the calculator code to an lvar and then read the value of the lvar. You still need to execute the calculator code, as you would need to do if you were getting the value back from the execute_calculator_code call... I completely understand this...and you can get a callback/event when an lvar changes. However, as this is YOUR lvar, you also need to provide the mechanism for it to get updated,,, Paul has also provided a possible solution to this for you.

There is no GUI with the PFC hid driver - please see the documentation included with the driver (PFChidDLL User Guide.pdf). I am not sure how axes are handled with the driver - check to se if you can see them in FSUIPC's axes assignment tab, and if so, assign and calibrate there. According to the log you originally posted, a PFC throttle quadrant was acquired so that should be assignable, but no PFC rudder - only CH Pro pedals.

You posted in the User Contributions sub-form - I have moved your post to the main support forum. The usual way to handle this is to use an offset condition on your assignments to check the current state of the switch in the sim (held in an offset) and only send the control if needed. See the Advanced User guide on adding offset conditions. This is not possible as FSUIPC only acts on state changes (buttons, switches, axes), so there is no way to determine the initial state. However, if you use offset conditions, your switches will be syncronized after the first activation, if not already. John

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