John Dowson

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

Windows error 740 is "The requested operation requires elevation", i.e. you need admin privileges for the operation, so yes, it is a permissions issue. Do you mean you set each one as unchecked? If checked, they will run in admin mode and so would require FSUIPC7 to be ran in admin mode, which in turn would require MSFS to be ran in admin mode. I think the issue is that TrackIR does require admin mode, and will request this if not ran in admin mode. See the following post for possible work-arounds to start TrackIR automatically: John

I don't know what "pop out manager" is but I would be very surprised if that updated your FSUIPC7.ini file....anyway, glad its all working again. John

Hard to test without the GF hardware though.... And a Happy Easter to you! John

Yes, I would think that 0x07F2 should be a signed word ("SW"). @eagle11 Your script would also be simpler if you read the value as a signed value rather than unsigned, and you are also using value as both an integer type and a string type...seems quite confused...but if it works....!

Again you are not providing enough information - what do you actually see when you move the axis? Is another axis recognised? If so, ignore that and try again. If another axis is again recognised, ignore that and try again. Repeat this until the axis you want to assign is recognised. Profiles have nothing to do with axes scanning / recognition - profiles just dictate how the axes assignments are saved/stored. If you still get issues, please attach your FSUIPC7.log and FSUIPC7.ini files.

As the Asobo cessna 172 classic (aka "Cessna Skyhawk Asobo") uses your dr400 profile - does this occur with all aircraft using that profile, or only this one? It would strike me as very strange if this only occurs to this aircraft in this profile... Also strange that this suddenly started! You have got DirectAxesToCalibs set (to Yes) in your profile - not sure why you have set this. Anyway, I have cleaned your ini a bit, so could you please try the attached (save/rename your current FSUIPC7.ini, and then download the attached to your FSUIPC7 installation folder). If you get the same issue, could you generate another log file for me, with Axes Controls logging enabled as well as Extras logging, but just load the aircraft, and then activate the left brake through its full range, then the right brake, and then exit FSUIPC7. Then attach the log and ini files again. And if you really need DirectAxesToCalibs set (please see the Advanced User guide for this ini parameter), try setting that to All instead of Yes - this will allow offset writes for axis inputs to the brakes to be calibrated, where Yes will only allow this for rudder, aileron and elevator axis offsets, FSUIPC7.ini

The AFC Bridge is only for the lights on the Bravo, and shouldn't affect the Axes. At least it was - I haven't looked at this for a while (and don't use it). There are also other ways to get the lights to work with FSUIPC. Yes - that icon only displays a splash screen and starts MSFS. It doesn't start FSUIPC7 - that is done by MSFS itself, if you selected the auto-start component during installation. To start FSUIPC only, you can just double-click the FSUIPC7.ese in windows explorer. If auto-start isn't working, see the FAQ section - there is a topic there on this subject. You can assign to the Honeycomb axes without MSFS running, but only in the general section (i.e. not in an aircraft-specific profile) and this also has other limitations, so always better to have MSFS running when assigning axes. And I suggest you read some of the documentation - the Installation and Registration guide to start with, and the User guide. You should at least be familiar with those documents, and also check the documentation (as well as searching this forum) before asking for support. I get the same questions all the time from new FSUIPC users...it would save everyone time if they read the provided documentation and used (i.e. searched, not post) the forums for similar issues. What was your issue with the Assignments menu not being present (i.e. registration valid in installer but not registered when running FSUIPC7)? You haven't responded in your other post - can I take it that this is solved and delete that post (as if it is for FSUIPC7, its in the wrong place) ?

What do you see when you hit the rescan button? Do the MOVE LEVER labels change to Joy# and Axis# and show a joystick id and axes letter? If so, an axes change was detected - if this isn't the one you are moving, click the Ignore Axis button and that axis will be ignored until you close the axis assignment dialog. Sometimes a jittering axis can prevent the axis you are trying to be assigned from being detected. If that is not the case, please explain what you see in that box (e.g. do the MOVE LEVER labels change? Is a joystick number and axis letter registered, and if so what?)and attach your FSUI{C7.ini file. Didn't you also post in the main support forum saying that you had registered in the installer but FSUIPC was unregistered? Was that for a different version of FSUIPC?

Good luck with that!

Ok, some progress... But did you see anything registered in the button assignments window? I don't think so, as the button state reported is always empty: So no virtual flag would be triggered. However, it does look like something is changing, as the actual 'data read' is different, so you could perhaps do something with this, but that could/would be quite complicated - especially for a non-programmer, or someone who doesn't have the device...

Ok, thanks for the update - good to know. I believe DX12 with nvidia is still not that stable. If you have a driver version that seems stable I would stick with that, but try the new releases anyway to see if they are ok, otherwise revert back to the version that is working for you. I have issues with DX12 when I have tried that (although I haven't tried for a while now) so I am sticking to DX11 for the time being. But, as I said, such issues are not related to FSUIPC.

For the lua script test. the lua file is not being started as this is your [Auto] section: whereas it should be As I said: So please try that. Also, with this lua test, open the button assignments dialog to see if any (virtual) button is recognised. However, this is the test I asked for in my last post, so you can ignore that one now. Your log shows that only button presses on device 19 were detected, which I presume is one of your PFC com devices. Also note it is also a good idea to wait for a short period after aircraft load for everything to be initialised and started, especially when trying to track down issues. If you have the console window open, wait until the following lines are logged before doing anything: Please try the lua test, but it does seem that this device requires some sort of "tickle" to be sent by the/a driver before it becomes active...Have you asked PFC about using this device with MSFS2020? Do you have any technical documentation for this device? Try the lua test but after this I am out of ideas. I will ask Pete, who has more experience with PFC devices (and wrote the drivers) next week, but I think it will be PFC you need to contact for this device... John