John Dowson

For avionics power switch. you can use the ELECTRICAL_Avionics_Bus_1 input event, with a parameter of 1 for pwr, 0 for off. For the battery switch, you can use the input event ELECTRICAL_Battery_1, with a parameter of 2 for EMER, 1 for Off and 0 for On. Why can't you just use those rather than messing around with the bus connections? As for external power, how would you do that in the VC? If this is via ground services, I am not sure this can be implemented, unless it is possible to assign a key combination for this (in MSFS).

As to the question that is the title of this topic ('How to use SimVars / Events 2 indicies in Lua'), you have already given the answer - you would use the RPN calculator code and send it via ipc.execCalcCode. Can you perform each of these activities in the VC (i.e. what buttons/switches/etc do you ? If so, how? Have you tried the following Input Events: ? Not sure what they do, but maybe worth playing around with. Note that just because these are logged without a parameter, it doesn't necessarily mean that a parameter is not needed. And also remember that some input events have still not been exposed for external use, but more should be available in future SDK updates. You can check using the MSFS dev tools yo see what other Input Events are avalalable, and also how they work if they look appropriate. Other than that, I cannot really help you much with this. FSUIPC provides the tools to enable you to control an aircraft, but it is up to you to decide how these are used. I know very little about how the electrical systems work or are implemented for any specific aircraft (and don't understand how the system.cfg relates to the events/code that you would use to control the aircraft). You should maybe try asking these questions on the aircraft support forums. I can take a look in more detail at some point, but I do not have time for this at the moment. I still have quite a bit of work to do on the next release (Input Events), but can maybe take a deeper look once this has been released. Please update if you get any further with this or have further information (what UI/VC controls do you want to replicate?).

Run the installer again. The details from your key file will be used to populate the registration dialog - try validating them. If they validate ok, you made a mistake when entering them. If they don't validate correctly, you need to update your VC++ redistributables. John

You can use your old/existing FSUIPC7.key file when you re-install - no need to re-register. However, if it previously worked, it should still work. You are either entering it incorrectly, or your VC++ redistributables need updating. But if your FSUIPC7 key validates ok, then your VC++ redistributables should be ok. See the section Invalid Key Problems in the Installation and Registration guide. Also remember, if you are using a different name and/or address for your WideFS key than the ones for FSUIPC7, you have to check the appropriate box and enter the name and address you are using for WideFS. If you still get the same issues when you have checked all of the above, please let me know both your FSUIPC7 and WideFS order numbers and I can check them here for you. Do NOT post your key details. John

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'.