John Dowson

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

Ok, thanks. I will look into this after Easter and post a version here for you to test.

Then why are you posting in this thread/topic? Please do not hijack unrelated topics - if you cannot find a topic for your issue, create a new one, And you should try the trial license before purchasing.... What does this mean? You need to explain what your issue actually is - I cannot help if you just say it isn't working. That is not an error, just an informational message. WideFS is a separate product and requires an additional license. If you don't know what it is, you don't need it. Again, this means nothing. What are you trying to get to work - a button or axis assignment maybe? Do not respond here. Create a new topic, appropriately titled, and specify what your actual issue is, and include/attach your FSUIPC7.log and FSUIPC7.ini files. Please at least read/peruse the provided documentation first - start with the User guide... John

The first log you posted shows: which should indicate that the device is detected as a standard HID device and should be assignable without the need for any other driver. Did you try without using the PFChid64.dll and without the PFC Test GUI running? If not, can you try that please, and set logging for Buttons & Keys (Log -> Buttons & Keys), open the logging console (Log -> Open console) and see if you get anything logged when you press a button. Also, please attach your FSUIPC7.ini file.

FSUIPC doesn't have anything to do with this issue - it doesn't do anything at all with graphics cards/devices. First check if there is an update for your graphics card drivers - they tend to get updated quite regularly. If you continue to get the same error, check the Asobo forums - I am pretty sure there are plenty of reports on such issues. Also, if using DX12, maybe try switching back to DX11. Not sure how stable DX12 currently is.

The available presets are from a community-driven effort led by MobiFlight. I provide the mechanism to use these presets, not the presets themselves, which are from the MF HubHop server (https://hubhop.mobiflight.com/presets/). For any issues with presets, first check the MF HubHop site (the source of the presets) for any additional information - the preset may be for a specific variant (for PMDG, this would be stable, development or experimental) and additional information is sometimes available in the description. For any questions on individual presets, please use the MobiFlight discord server, in the HubHop channel, and it is recommended to tag the preset author (using the @username notation).