John Dowson

First, as stated in the beta announcement topic, for any issues in this beta release, please post in the beta release thread/topic. The issue was that the function call was always returning a failure even though it had succeeded. I have corrected this now, and the beta release has been bumped to 7.3.26d. John

The display library is for WideClient only. If not using WideClient. you probably want to use ipc.display. However, the SimConnect text display functions are no longer working in MSFS. You may see something, but it is not reliable and the underlying functions have been deprecated. For displaying information in a window from lua, you should use the Wnd library. John

For testing values, use '==' not '=', e.g. if avstate == 0 then .... A single '=' is used for assignment, not conditionals.

Please see John

Please see John

License sent.

Ok - they won't work in the King Air... This is strange - the individual AXIS_PROPELLER1_SET and AXIS_PROPELLER2_SET controls should be used... Ok, then I would use FSUIPC, that would give you more options. Try disabling the prop assignments in the PFC driver and assign to the individual prop controls in FSUIPC. Should be available later today...I will let you know when released. John

As the parameter is ignored, ipc.control(66494,1,0), ipc.control(66494,1,1), ipc.control(66494,1,99), etc will all have the same effect. You can use just ipc.control(66494) if you like, or maybe ipc.control(66494, nil) to indicate that a parameter can be given but not needed in this case. It is just personal preference really. Similar to a control or preset - there will be an additional checkbox 'Select for Input Event'. As B type variables are also known as Input Events, I suspect that they relate to these. But really, I have no idea - I only have the information provided by the SDK. I suspect they relate to how things are implemented on the aircraft itself. It may take a while for add-in aircraft to be update to use Input Events. For example, I have just taken a look at the PMDG 737 and no input events are available for this aircraft. I see your point, but It is not a double word - a word is 2 bytes, a double word us 4 bytes. It is a double double-word (hence DD). That is a 64-bit float, so use ipc.readDBL / ipc.writeDBL Well, the length is stated, just not the actual type. I can see that the type would be useful. In fact, for many offsets the description does indicate if it is a float/double or integer, just not for all. Generally, unless stated in the description, you should assume that all 8 byte values are double floating point values. For 4 byte values, they can be either floats (32-bit) or integers, but the description should tell you which for most offsets. Otherwise logging as both types should help you decide. John

MSFS is a completely different sim to FSX. There are many additional controls in MSFS, and many aircraft do not use the standard controls, and you have to use lvars/hvars/presets instead. The PFC driver was written many years ago (way before my time), and will not have access to the newer controls available in MSFS (or presets. etc). And as I don't have any PFC controls (and have never seen or configured any), so it is very difficult for me to advise on this. I do not understand why the left lever is also controlling the right lever. What axes controls do you see logged when you move the left lever? What do you see logged when you control the right lever? It is far easier for you to check this - just set axes logging and open the logging console and see what is logged when you move the levers. Have you checked in MSFS to see if these levers have also been auto-assigned there? Does MSFS recognise the PFC device? Does FSUIPC recognise your PFC axes/buttons, or are these only recognised and assignable in the PFC driver? I have just taken a quick look at the KingAir, and it looks like some Input Events are available for the condition lever: I will be releasing a beta version if FSUIPC later today that will allow assignment to Input Events, but for buttons/switches/keys, not axes. However, you can still use them for axes by writing the axes value to an FSUIPC offset and then using a lua script to pick-up the axes value (using event.offset), calibrate it and then send the value to the FS using an Input Event (ipc.execInputEvent). This will only be possible using FSUIPC though, and not via the PFC driver. It is also strange that the Input Event for condition lever 1 accepts a parameter (float64), but the one for lever 2 doesn't. I suspect that is an error somewhere within the aircraft itself (or in MSFS) [it is an error in the information received - both accept a parameter], Later: I have just taken a look at the kingAir condition levers. They cannot be controlled by axes controls, as they have three distinct positions: cut-off, low-idle and high idle, which matches the presets available. You can control both levers (including the visuals) by assigning to the FUEL_1_Condition_Lever and FUEL_2_Condition_Lever Input Events, using a parameter of 2 for cut-off, 1 for low-idle and 0 for high-idle. I will look into allowing input events to be assigned to an axes range (right-hand side of axes assignment dialog) to allow an axes to be assigned to these Input Events when moving through different positions, but I will do this after the initial beta release. For the propeller, assigning to PropPitch1 & PropPitch2 work as expected here. There are also Input Events available for the propeller levers (ENGINE_Propeller_1 and ENGINE_Propeller_2), but I don't see any reason to use these as the standard controls are working as expected. John

That looks fine. I don't understand why it is using the same vendor id (044F) as Thrustmaster though, but I wouldn't worry about this. The only worrying thing is the empty assignment line: 2= -{ DIRECT: Rudder }- I have never seeing anything like that (no assignment details but a valid comment/annotation). Can you remove that line (when FSUIPC/P3D is not running) and then try and reassign and re-calibrate your rudder, and check that the assignment line looks correct afterwards. You should also switch to using JoyLetters - just change this: AutoAssignLetters=Yes John

I have also just noticed that 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, where it belongs. John

Now I am confused...your initial message stated '' i use FSUIPC 4.90 with fsx? The file you attached is a SIOC config file (from opencockpits.com) and shows that it is using offset 034E: As I said, try logging that offset. I am pretty sure that that will be holding the correct value, and if you write to it then the active Com1 frequency will be updated. If this was previously working, what has changed? Are you running all your software with the same privileges, i.e. all as admin or all without admin? Everything must be ran at the same level to enable communication. I don't think your issue is anything to do with FSUIPC. You need to determine what has changed and correct this - either with the vatsim client or your SIOC config. I cannot help with either of these. John

The details of your controllers are taken from the windows registry - I do not know or understand why these have not been updated. I am also surprised that the rudder is working - the toe brakes seem to be assigned ok but the rudder assignment is empty: ? Can you attach your FSUIPC6.JoyScan.csv file please.

Did you read my last comment? Try reading it again...as I said, toggle events (usually) DO NOT take a parameter, they toggle/swiych between two states. If something is off and you toggle it, it goes to on, if it is on and you toggle it, it goes to off. You don't need a parameter. So use ipc.control(66494,0). Not with the toggle controls. Yo set the state explicitly, you would use the set controls: SET_FUEL_VALVE_ENG1, SET_FUEL_VALVE_ENG2, SET_FUEL_VALVE_ENG3 & SET_FUEL_VALVE_ENG4. These are events and have no state. They do allow the state of something to be changed - usually a simvar (a-type variable), but could also update other variable types, I would expect the fuel valve controls/events change the value of one or both of the following simvars (in aircraft using the new FuelSystem): That is another possibility, if using the legacy fuelsystem. Not sure if that is valid if/when using the new FuelSystem. Why don't you just monitor it and see if it changes? That is the only way to determine if its being used. By testing/checking. How else? If that offset doesn't change, look at those other simvars (i.e. add them to free/spare offsets). Note the C510 Mustang has 227 Input Events that will be available for assignment in the next beta release: 227 Input Events available: AS1000_PFD_1_NAV_Volume<> AS1000_PFD_1_COM_Volume<> AS1000_PFD_1_NAV_Swap<> AS1000_PFD_1_NAV_Mhz<> AS1000_PFD_1_NAV_Khz_Button<> AS1000_PFD_1_NAV_Khz<> AS1000_PFD_1_COM_Swap<> AS1000_PFD_1_COM_Mhz<> AS1000_PFD_1_COM_Khz_Button<> AS1000_PFD_1_COM_Khz<> AS1000_PFD_1_Baro<> AS1000_PFD_1_Course_Button<> AS1000_PFD_1_Course<> AS1000_PFD_1_Softkey_1<> AS1000_PFD_1_Softkey_2<> AS1000_PFD_1_Softkey_3<> AS1000_PFD_1_Softkey_4<> AS1000_PFD_1_Softkey_5<> AS1000_PFD_1_Softkey_6<> AS1000_PFD_1_Softkey_7<> AS1000_PFD_1_Softkey_8<> AS1000_PFD_1_Softkey_9<> AS1000_PFD_1_Softkey_10<> AS1000_PFD_1_Softkey_11<> AS1000_PFD_1_Softkey_12<> AS1000_PFD_1_DirectTo<> AS1000_PFD_1_Enter<> AS1000_PFD_1_Clear<> AS1000_PFD_1_Menu<> AS1000_PFD_1_FlightPlan<> AS1000_PFD_1_Procedure<> AS1000_PFD_1_FMS_Inner_Button<> AS1000_PFD_1_FMS_Inner<> AS1000_PFD_1_FMS_Outer<> AS1000_PFD_1_Range_Pan_X<> AS1000_PFD_1_Range_Pan_Y<> AS1000_PFD_1_Range_Zoom<> AS1000_PFD_1_Range_Cursor<;FLOAT64> AS1000_PFD_1_Heading_Sync<> AS1000_PFD_1_Heading<> AS1000_PFD_2_NAV_Volume<> AS1000_PFD_2_COM_Volume<> AS1000_PFD_2_NAV_Swap<> AS1000_PFD_2_NAV_Mhz<> AS1000_PFD_2_NAV_Khz_Button<> AS1000_PFD_2_NAV_Khz<> AS1000_PFD_2_COM_Swap<> AS1000_PFD_2_COM_Mhz<> AS1000_PFD_2_COM_Khz_Button<> AS1000_PFD_2_COM_Khz<> AS1000_PFD_2_Baro<> AS1000_PFD_2_Course_Button<> AS1000_PFD_2_Course<> AS1000_PFD_2_Softkey_1<> AS1000_PFD_2_Softkey_2<> AS1000_PFD_2_Softkey_3<> AS1000_PFD_2_Softkey_4<> AS1000_PFD_2_Softkey_5<> AS1000_PFD_2_Softkey_6<> AS1000_PFD_2_Softkey_7<> AS1000_PFD_2_Softkey_8<> AS1000_PFD_2_Softkey_9<> AS1000_PFD_2_Softkey_10<> AS1000_PFD_2_Softkey_11<> AS1000_PFD_2_Softkey_12<> AS1000_PFD_2_DirectTo<> AS1000_PFD_2_Enter<> AS1000_PFD_2_Clear<> AS1000_PFD_2_Menu<> AS1000_PFD_2_FlightPlan<> AS1000_PFD_2_Procedure<> AS1000_PFD_2_FMS_Inner_Button<> AS1000_PFD_2_FMS_Inner<> AS1000_PFD_2_FMS_Outer<> AS1000_PFD_2_Range_Pan_X<> AS1000_PFD_2_Range_Pan_Y<> AS1000_PFD_2_Range_Zoom<> AS1000_PFD_2_Range_Cursor<> AS1000_PFD_2_Heading_Sync<> AS1000_PFD_2_Heading<> AS1000_MID_COM_1<> AS1000_MID_COM_1_Mic<;FLOAT64> AS1000_MID_COM_2<> AS1000_MID_COM_2_Mic<> AS1000_MID_COM_3<> AS1000_MID_COM_3_Mic<> AS1000_MID_COM_Swap_1_2<> AS1000_MID_PA<> AS1000_MID_SPKR<> AS1000_MID_MKR<> AS1000_MID_HI<;FLOAT64> AS1000_MID_DME<> AS1000_MID_NAV_1<;FLOAT64> AS1000_MID_NAV_2<> AS1000_MID_ADF<> AS1000_MID_AUX<> AS1000_MID_MAN_SQ<> AS1000_MID_Play<> AS1000_MID_Isolate_Pilot<> AS1000_MID_Isolate_Copilot<> AS1000_MID_Pass_Pilot<> AS1000_MID_Pass_Copilot<> AS1000_MID_Display_Backup<> AS1000_MFD_1_NAV_Volume<> AS1000_MFD_1_COM_Volume<> AS1000_MFD_1_NAV_Swap<> AS1000_MFD_1_NAV_Mhz<> AS1000_MFD_1_NAV_Khz_Button<> AS1000_MFD_1_NAV_Khz<> AS1000_MFD_1_COM_Swap<> AS1000_MFD_1_COM_Mhz<> AS1000_MFD_1_COM_Khz_Button<> AS1000_MFD_1_COM_Khz<> AS1000_MFD_1_Baro<> AS1000_MFD_1_Course_Button<> AS1000_MFD_1_Course<> AS1000_MFD_1_Softkey_1<> AS1000_MFD_1_Softkey_2<> AS1000_MFD_1_Softkey_3<> AS1000_MFD_1_Softkey_4<> AS1000_MFD_1_Softkey_5<> AS1000_MFD_1_Softkey_6<> AS1000_MFD_1_Softkey_7<> AS1000_MFD_1_Softkey_8<> AS1000_MFD_1_Softkey_9<> AS1000_MFD_1_Softkey_10<> AS1000_MFD_1_Softkey_11<> AS1000_MFD_1_Softkey_12<> AS1000_MFD_1_DirectTo<> AS1000_MFD_1_Enter<> AS1000_MFD_1_Clear<> AS1000_MFD_1_Menu<> AS1000_MFD_1_FlightPlan<> AS1000_MFD_1_Procedure<> AS1000_MFD_1_FMS_Inner_Button<> AS1000_MFD_1_FMS_Inner<> AS1000_MFD_1_FMS_Outer<> AS1000_MFD_1_Range_Pan_X<> AS1000_MFD_1_Range_Pan_Y<> AS1000_MFD_1_Range_Zoom<> AS1000_MFD_1_Range_Cursor<> AS1000_MFD_1_Heading_Sync<> AS1000_MFD_1_Heading<> AUTOPILOT_AP_1<> AUTOPILOT_Heading_Mode<;FLOAT64> AUTOPILOT_Heading_Sync<> AUTOPILOT_Heading<> AUTOPILOT_Bank_Button<> AUTOPILOT_Approach_Button<> AUTOPILOT_Backcourse_Button<> AUTOPILOT_FD_1_Mode<;FLOAT64> AUTOPILOT_YD_Button<;FLOAT64> AUTOPILOT_FLC_Button<;FLOAT64> AUTOPILOT_Altitude_Button<> AUTOPILOT_Altitude_100<> AUTOPILOT_VS_Mode<;FLOAT64> AUTOPILOT_VerticalSpeed<> AUTOPILOT_Transfer_Mode<> AUTOPILOT_NAV_Mode<;FLOAT64> AUTOPILOT_VNAV_Mode<;FLOAT64> AUTOPILOT_SpeedToggle_Mode<> AUTOPILOT_Course_1_Sync<> AUTOPILOT_Course_1<> AUTOPILOT_Course_2_Sync<> AUTOPILOT_Course_2<> DEICE_Windshield_1<> DEICE_Airframe_1<;FLOAT64> DEICE_Engine_1<> DEICE_Engine_2<;FLOAT64> ELECTRICAL_Battery_1<;FLOAT64> ELECTRICAL_Avionics_Bus_1<> ELECTRICAL_Circuit_5<> ELECTRICAL_Alternator_1<> ELECTRICAL_Alternator_2<> ENGINE_Starter_1<;FLOAT64> ENGINE_Starter_2<;FLOAT64> ENGINE_Starter_Disengage<> ENGINE_Ignition_1<;FLOAT64> ENGINE_Ignition_2<;FLOAT64> ENGINE_Throttle_1<;FLOAT64> ENGINE_Throttle_2<;FLOAT64> ENGINE_TOGA_1<;FLOAT64> ENGINE_TOGA_2<> FUEL_Pump_1<;FLOAT64> FUEL_Pump_2<;FLOAT64> FUEL_Crossfeed_1<> HANDLING_ElevatorTrim_1<;FLOAT64> HANDLING_Flaps<;FLOAT64> HANDLING_Anti_Skid<> HANDLING_RudderTrim_1<;FLOAT64> HANDLING_AileronsTrim_1<;FLOAT64> HANDLING_Yoke_Hider_1<;FLOAT64> HANDLING_Yoke_Hider_2<;FLOAT64> INSTRUMENT_Attitude_Indicator_Bars<;FLOAT64> INSTRUMENT_Altimeter_1<;FLOAT64> INSTRUMENT_Airspeed_Calibrator<> LANDING_GEAR_Gear<> LANDING_GEAR_ParkingBrake<;FLOAT64> LIGHTING_PANEL_1<;FLOAT64> LIGHTING_POTENTIOMETER_30<;FLOAT64> LIGHTING_CABIN_1<;FLOAT64> LIGHTING_CABIN_2<;FLOAT64> LIGHTING_CABIN_3<;FLOAT64> LIGHTING_CABIN_4<;FLOAT64> LIGHTING_CABIN_5<;FLOAT64> LIGHTING_CABIN_6<;FLOAT64> LIGHTING_CABIN_7<;FLOAT64> LIGHTING_STROBE_1<;FLOAT64> LIGHTING_BEACON_1<;FLOAT64> LIGHTING_NAV_1<;FLOAT64> LIGHTING_LANDING_1<;FLOAT64> LIGHTING_WING_1<;FLOAT64> NAVCOM_ADF_ADF_ANT_MODE_TOGGLE<> NAVCOM_ADF_BFO<> NAVCOM_ADF_FRQ<> NAVCOM_ADF_FLTET<> NAVCOM_ADF_SETRESET<> NAVCOM_ADF_Volume<> NAVCOM_ADF_Freq_100_Khz<> NAVCOM_ADF_Freq_Increment<> NAVCOM_ADF_Freq_1_10_Khz<> SAFETY_Alternate_Static_Air<> SAFETY_ELT_1<> SAFETY_Caution_1<> SAFETY_Caution_2<> SAFETY_Warning_1<> SAFETY_Warning_2<>

Sent

They are toggle events - toggle events don't usually have a parameter (although if I remember correctly some actually do!). A toggle event switches between two states, and no parameter is usually needed. They are not variables, they are events. See https://docs.flightsimulator.com/flighting/html/Programming_Tools/Event_IDs/Aircraft_Electrical_Events.htm: Although that is confusing, as it talks about index when i presume they mean parameter (simvars can be indexed, not events, as far as I am aware). So a param of 24 would indicate circuit 24 (and its a toggle event with a parameter, in this case justified!). What circuit 24 is, I have no idea - this will be dependent on the implementation of the electric circuits in the aircraft and you would need to dig into the aircraft config files to determine what that is. Just use the parameters as logged. John

Presume you mean 034E or 0x034E. Maybe you have configured to use the wrong offset? How are you actually using this offset? I do not see any assignments using this offset in your ini. Please explain how this offset is being used, and by what. There are also no annotations/comments in your ini, even though Annotate=Yes is set, which is strange. Then this must be an issue with the update - FSUIPC hasn't changed. You need to see what has changed in the FQZ - maybe try VatSim support? You could try logging offset 0x034E using FSUIPC's offset logging facilities log as U16 in hex and send to the FS Title bar. You should then be able to see what the offset is holding.

Not yet, but I will add another lock on sending calc code when lvar/hvar updates are being received in the next beta, which I am planning on releasing in a couple of days. Increase it further - your log still shows lvars are being discovered after this period, and you are getting the new lvars continually pushed. You want to set it to a value where most, if not all, lvars are found on the first scan. Try 15 seconds, and if you are then still getting new lvars pushed, increase further. John

How am I supposed to help you when you provide no information as to what your problem actually is? Please explain what your problem is, and also attach your FSUIPC4.ini and FSUIPC4.log files. However, before anything else, please update to the latest version of FSUIPC4, which is 4.977. Only the latest version is supported. John

There are no such functions. To read a simvar that is not currently held in an offset, you have to first add it to an offset via the myOffsets.txt file, and then read the offset value. There is no direct way of reading a simvar due to the asynchronous nature of the simconnact API (i.e. you request a value and sometime later you will get the value back via a message). You can also write the value of a simvar to an lvar (using calc. code) and then read the value from the lvar, but I wouldn't recommend this method due to the delay between writing and reading - you have to wait for the updated value to be returned, also for the lvar to be recognised and returned to FSUIPC if the calc code also creates the lvar. You can use the same method. Or wait until next week when I release the beta which has access to Input Events. Note that the Input Events available are/will be restricted to the 'set' ones. Asobo have indicated that more Input Events (toggle, inc, dec) will be accessible in future updates. John

You also have a large null zone set on your proppitch axes: And as I said, you will be better off creating a profile-specific calibration section for the DC-6. You could also clean-up the aircraft names in your profiles to use substring matching, so, for example, change this: to this: That will then catch all variants, i.e. any aircraft containing the string 'PMDG DC-6'.

Not really. Those lua functions read offsets. Of course, if the offset holds an avar (aka simvar) or lvar, then you are reading the value of that variable. What does this mean? The examples how the variable, the type and the units, e.g. the example from the Advanced User guide: i.e. 3rd column is simvar/avar variable name, 4th column is type, as defined in the same place I am not sure what your problem is or why you are asking this.... You can't, either via simconnect or guage code in the WASM. As I have said, I will be adding access to Input Events (aka B vars) in the next release. There is no access to O type variables at the moent. As I have said, no access at all to O vars. For B vars, no direct access at the moment (again, wait until I release access to Input Events). I have already shown you a hack to introduce an lvar to control b vars. Please try and understand the answers I have already given - you seem to be asking the same questions again and again. These new variable types are new to us all. And access is limited to such variable types. I have no further information other than what is provided in the MSFS SDK documentation. John

What controls are they assigned to? You can try setting logging for axes controls and see what is logged, if anything, when you move the assigned levers. Looking at the HubHop page for the King Air (https://hubhop.mobiflight.com/presets/), it looks like the condition levers require a combination of axes controls (SET_FUEL_VALVE_ENG1/2), lvars (L:Condition_Lever_CutOff_1/2) and simvars/a:vars (TURB ENG CONDITION LEVER POSITION:1/2). I have no idea how you would set-this up with a PFC device (I don't have any!), but I could look into how to control with a standard joystick axes if you like to see if that helps. Note it was previously reported that the controls for the condition lever were working, but they were not controlling the visuals, i.e. you could hear the change in the engine but the lever in the VC wasn't moving - that maybe why you also need to set the lvar and avar. See I can take a look at the condition lever in the Asobo King Air, but this will be next week. I can only do this with a standard joystick axis, but if this can be done we can then look into how to set this up with the PFC driver, if possible. That is strange... what do you see on the PFC config page for the left lever? Does it jump from 0-100 there? Could you activate logging for Axes Controls in FSUIPC7, and generate a short log file where you just load the aircraft and then move the left lever through its full range, from min to max, and then back again. Then exit FSUIPC7 and show me/attach your FSUIPC7.log file, together with your PFC.cfg file and FSUIPC7.ini file. Normally an axis that jumps from 0-100 and back again has been flagged as a digital axis in the registry, and you need to clean the registry to resolve this (there is a FAQ entry on how to do this in the FAQ sub-forum). However, as this also seems to be interfering with the right propeller, best to show me those files before anything else. John

License sent via PM. John

You seem to be using an old version of the WASM/WAPI - latest version is: In later version of the WASM/WAPI, you don't need to reload as lvars are automatically pushed to clients when discovered. Presumably there is a later version of Pauls';s ,Net client dll that can be used (probably using WAPI 1.0.2), so you should update. And update your WASM version (and FSUIPC) to the latest version before anything else. John