John Dowson

Do you have a reference? Noy sure how you can get an axis value from a rocker switch,,, Both are needed, and you shouldn't add them manually - if you remove them, FSUIPC will automatically add the joystick id lines back. It cannot work without them. It is difficult to tell what is happening from such a large log file...its far easier for you to see what is logged in real-time (with the logging console window open) when you perform the action. When you adjust the ridder trim in the VC, what do you see logged? Any controls? Does offset 0C04 change value, and if so through what range? When you move the rocker switch, do you also see offset 0C04 changing value?

As you are using the C152, if you look at the presets to control the ADF mode (C152 ADF Mode Selector BFO/ADGH/TEST/REC) (see https://hubhop.mobiflight.com/presets/), these use the lvar L:XMLVAR_ADF_Mode but the description on these presets says: Knob in sim is controlled by O: var so it won't move. So the lvar controls the ADF selection but won't move the log in the sim. For the cabin lights in the C152, you can use the standard controls Toggle Cabin Lights, Cabin Lights On, Cabin Lights Off, or Cabin Lights Set. You should always try standard/default controls before resorting to lvars. Note all lvars are writable, and many do not work on their iwn and may require the use of a hvar or kvar (event). Please also note the following: - the WASMClient is not supported. This is only provided as a test client sample for developers who want to use the WAPI. You shouldn't need to use this - all the WASM functionality you need is available from the Add-ons->WASM menu in FSUIPC7. - please attach log files rather than pasting their contents. And please only enable relevant logging - or no logging if you are not sure. I will ask for a log file with specific logging activated, if needed. - I only provide access to lvars (and hvars and presets) - I do not control what they do, and do not know what most of them do. Some are not even writeable/updateable. Its better to check for a MF preset before using an lvar directly (or if it doesn't work as expected) , and check the code and description - it may be fine to just use the lvar, or sometimes something more complicated is needed, and better to use the preset. You should also check for standard controls before looking for presets or lvars. John

Is the rocker switch an axis then? I am not sure how that works - I would expect a rocker to trigger buttons... Your ini file is quite strange as you only have the letter assignments under [JoyNames] and no lines with the joystick ids - did you remove those? For the MilViz DHC-2, as you are using inc/dec controls on offset 0C04 for the rudder trim, create a specific profile for this aircraft and switch around the controls, so perform the decrements in the range you are currently performing the increments and vice versa. For Ant's T-28's, check what the rudder trim in the aircraft is using by logging events and also set logging for offset 0C04 as S16. Then load the aircraft and adjust the rudder trim in the virtual cockpit and see what event (if any) is logged, and if the offset value changes (which I expect not). If the rudder controls Rudder Trim Left/Right are logged, you could try using those. Otherwise, if the Axis control Rudder Trim Set is logged, you could try assigning to that as an axis. You can also attach your FSUIPC6.log and latest FSUIPC6.ini files here and I can take a look. John

We always recommend not using/installing the Saitek drivers (or any additional software) if using FSUIPC, as these invariable cause issues. Just let windows install the default drivers. I have the X55 (not the X52, but should be similar), and the mode switch on the throttle is recognised by FSUIPC as buttons 31, 132 and 133. John

This depends on what models they are... You should just try it. A trial license for FSUIPC7 is available from here: For the GoFlight mofules, you can check what is supported and download the 64-bit driver from http://fsuipc.com/. You can also download the PFC driver from the same location - use either the PFChid64.dll or the PFCcom64.dll, depending on whether it is one of the more modern USB HID devises or an older COM-port connected devices respectively. User manuals are provided with the PFC drivers, and both the GF and PFC driver dlls should be copied to your FSUIPC7 installation folder. John

Thanks @fabio777 for the detailed investigation and explanation for this issue - hope that helps others. Regards, John

Flight simulation is a pretty small market compared to xbox gaming.... A couple of other interesting posts on MSFS weather access: https://forums.flightsimulator.com/t/what-weather-data-exactly-does-the-api-provide-precip-wind-turbulence/533447 https://forums.flightsimulator.com/t/how-to-query-the-metar-information-for-dest-origin-airport-throught-wasm-or-simconnect/562648 John

This is very strange! I've checked here and have no issues with the rudder in any of the PMDG 737 variants. FSUIPC makes no distinction between the variants as your PMDG 737 profile will be used for all of them. I can only presume that your PMDG 737 installation has been corrupted somehow. Try uninstalling and re-installing the aircraft to see if that helps. John

Note that Ambient Visibility has also been reported as not working - see https://devsupport.flightsimulator.com/questions/16304/bug-aambient-visibility.html John

Yes, access to weather is currently very limited and I don't think there are any plans by Asobo to provide a new weather API, but you should check for this on the Asobo forums. Currently, only ambient weather simvars are available: John

The MobiFlight add-on events use the *.evt files, and you need the MobiFlight WASM module installed to handle these events. That is the older method of using the MF events. The newer and better method is to use presets, which are handled by the FSUIPC WASM, and you don't need the MF WASM module to use these. The logs you posted are strange in that they show no macro names being written to offset 0D70, and your hid log file is also not logging the macro names. Add-on events are handled by FSUIPC, so will work. If the MF add-on events aren't working, then either the MF WASM isn't installed or perhaps these are no longer working as they have also been replaced/superseded by the presets/calculator code provided in the MF events.txt file. Anyway, glad its now working... John

Maybe also a good idea to monitor the macro execution offsets to check the dll is sending the correct data. Use Log->Offsets and monitor 0D6C as S16 and 0D70 as AsciiZ and check Normal log file.

I have checked this now and using both add-on events and presets in macro files seems to work as expected, and for presets you can either use the preset control number or the preset name itself (i.e. <indexNo>=<macroName>=CP<presetName>, <parameter>) which is preferred - and easier. So I am not sure why the add-on event is not being sent for you. Could you activate logging in FSUIPC7 for Buttons & Keys as well as Events, and generate a short log file where you try an execute a macro using an add-on event. You can also try this with the logging console window open (Log->Open Console) and see if anything is logged. Also maybe try with presets, presuming you have the FSUIPC WASM installed and enabled. To do this, for example, you would change your macro entries from, for example: to John

They do - MF presets for the GNS530/430 work for both the default/Asobo and Working Title versions. The presets for these start with AS430 and AS530 respectively. Check the MobiFlight HubHob site for a list of available presets. They should work in the same way as the MF events, except that you don't need the MF WASM module installed to use them. Also, if you look at the preset code, most of them (I haven't checked all) just activate a hvar or send a standard event (K-type). So, for example, the event :MobiFlight.AS530_CLR_Push is the same as the preset AS530_CLR_Push, whose code is "(>H:AS530_CLR_Push)", so that just activates the hvar H:AS530_CLR_Push. Unfortunately this doesn't help much though, as to use hvars (and lvars) in macro files, you do this by setting the macro name to the hvar/lvar name, and you cannot do this in the PFC.mcro file is the macro names are pre-determined. So really you do need to be able to assign the given macro name to either send an add-on event (as you are now doing, which doesn't seem to work), or to send a preset. But I still need to check the calling of presets from a macro file, as I do with add-on events. As I said, I will let you know about this, but it will probably be tomorrow now (sorry, I have also has other things I need to look into). I will get back to you once I have checked. If its not working correctly at the moment, as I suspect, I will update to get this working and give you an updated version to test, but this may take a day or two. John

No - the event files are just used by FSUIPC, not by the PFChid64.dll. The WAPi is also only used by FSUIPC, not by the PFChid64.dll. And you don't need the WAPI/WASM if using add-on events, as you seem to be using. The WASM / WAPI is only needed if using presets. Your issue seems to be that the add-on events are not working when being used in a macro file. This surprises me but I will check this and get back to you. Note that it is probably easier these days to use presets rather than add-on events. However, I am not sure if calling presets in a macro file is implemented (although it should be!). I will check all this and get back to you. John

Looks like you are using an old version of FSX. Can you please install SP1 - and also recommended to install SP2. From https://answers.microsoft.com/en-us/windows/forum/all/microsoftflightsimulatorsimconnectdll/89761287-052f-4f63-9443-17ffbc46babd: After you have updated your FSX installation, install the required SimConnect versions (also mentioned in that post). John

How are your buttons assigned? You can try logging Buttons & Keys as well as Events, open the logging console (Log -> Open console) and see if what is happening when you press the buttons. Maybe the first press is a press, and the second a release? You can post/attach your FSUIPC7.ini and FSUIPC7.log files here as well and I can take a look. If you are using lua to control the buttons, I will need to see the lua scripts, as well aa your FSUIPC7.ini and FSUIPC7.log files, the latter generated with Lua Plugins logging enabled.

Sorry, but i do not understand your question. FSUIPC does not work on xbox.

When you set the flag to change the state id the encoder, also store the time using ipc.elapsedtime(). In the function that handles the rotary button presses, you can again get the elapsedtime and check the difference between thus and the mode flag change, and if greater than a certain amount then chage the mode back and then oerform the action based upon the mode. You can also reset the mode elapsedtime flag if still not in the default mode, so it would only switch back to the default/noirmal mode after a certain periond of inactivity. You can activate presets in lua by writing the preset name to offset 0x7C50 using ipc.writeSTR. Note the preset name should ne preceded by P: and the preset name should be as written in the events.txt file, i.e. usually with underscores '_' and not spaces, as they are shown in the preset assignment menu. Give it go, show me what you come up with and I can correct it for you. John

No - only the profile-specific JoystickCalibration section will be used if present. If the aircraft uses a profile but there is no profile-specific JoystickCalibration section, then the general JoystickCalibration will be used. Note also that to log slope adjustments, you can set logging for Extras. Also, be aware that the toe brake axes are also not linear: Sets the left brake position from an axis controller (e.g. joystick) to the value given as the parameter [0], from -16383 (0 braking) to +16383 (maximum braking). Note that this is on a non-linear scale: -16383 = 0% -8191 = 8% 0 = 27% +8191 = 53% +16383 = 100% John

Do the rotary encoders use buttons or are they an axis? If they are buttons, you can use the conditional format as explained in the Advanced User guide. However, you cannot use conditional assignments for axes, and there is not concept of times in standard assignments, so for both of these you would have to use a lua script. You would need to use the event.button function to handle the button presses, and you can use the ipc.elapsedtime function to get the timestamps if the button presses to determine the time between button presses to determine what mode you are in. You could also use the event.timer function to check and time-out the current mode. If the rotary encodes use an axis, then you can assign these to write the axis value to an FSUIPC offset, and then pick-up this value in an event.offset handling function. Take a look at the Lua Library document for a description on how to use these functions, and maybe some of the example lua scripts provided (in your FSUIPC7 Documents folder) - maybe the TripleUse.lua as this does different things based upon the period between button presses - and/or maybe take a look un the User Contributions section to see if there is anything there that you can adapt to your needs. I can't write this script for you, but I can help if you get stuck or have any issues. John

Is your PFC Cirrus II a com or a hid device? If it is a com device, you need the PFCcom64.dll driver, and if its a HID device you need the PFChid64.dll driver. As FSUIPC7 is a 64-bit program, it won't load the 32-bit pfc.dll - you need the PFCcom64.dll driver (if it is a com device). What do you mean by "PFCCOM64.dll unfortunately doenst work"? What have you tried? Have you read the provided documentation for the PFC drivers , please do that before anything else, although bare in mind that this hasn't been updated for FSUIPC7. You should see a PFC entry in FSUIPC7's Add-on menu, so look there. And are you now using a registered version of FSUIPC7? If you still can't get your PFC device to work, please show me your FSUIPC7.log and FSUIPC7.ini, as well as the driver log and ini files, if present. Please also state clearly what your PFC device actually is, and check the driver documentation to see if supported.

These are Pete's comments on this:

Pete took a look and it seems that the PFC430 is recognised/supported and can be used with the PFChid64 driver, but no default actions are supplied and you need to provide these yourself via the PFC.mcro file. From the PFCmacroIndex.csv file, these are the macro names you need to define for the buttons (3rd column): and for the encoders: John

This seems more complicated rather than simplified! I don't know why you are checking for a value > 9900 and then negating - as you are passing in a signed value, this test will never pass. And where is ID set? I think you would be better off using your first script but with a signed value, i.e. John