John Dowson

I don't see why an axis would depend on the direction of travel... Do you not use the tiller when taxiing? Ah yes...well, it should control the nosewheel direction regardless, but for pushback you don't want to be using the nosewheel steering... For pushback control, you need to use offset 0x31F4. However, you cannot control the angle precisely, you can only set the direction -tail swing to the left or right. You will need a lua script to do this if you want to control using the tiller, and you need to take care that the nosewheel also isn't being controlled when in pushback, so the lua script should also control the steering when not in pushback. You therefore need to assign your tiller to write its value to an FSUIPC offset, The lua script should have an event function on this offset, and when the value changes it can decide if this is meant as a steering control or a pushback control by reading offset 0x31F0 - or, better, have an event on this offset that sets a flag in the lua script that you can use to determine steering control [value of 3] or a pushback control [value != 3], and then either send on the steering control or write to the pushback control offset if the value there needs changing.

What FS and version of FSUIPC are you using, and what A320 model? Use events/controls, not variables. Have you tried assigning to the FSUIPC axis SteeringTiller (under Send direct to FSUIPC calibration - calibrate on page 9), or the standard control Steering Set? John

There also seems to be an issue with your new parking brake, as windows is reporting the same GUID for this device as one of your T-Pendular-Rudders: GUIDs are supposed to be unique...not sure what is going on here or what can be done about it....lets wait and see what your updated files say.... However, may be best to leave this disconnected for the moment, and we can add this back once we have corrected the rest of your devices. John

This is a very bad idea - please do not do this again... Your registry is in a complete mess now, with many of the GUIDs associated to your deices being wrong. This issue may now take quite a few iterations to get things back in order. First, we'll try and remove all the dodgy registry entries and see if they can be regenerated correctly. Take a backup of your registry, and then please disconnect the following devices: Fulcrum One Yoke Parking Brake Joystick - HOTAS Warthog AGRONN B737 Yoke V2.2 Cat3Design A320 FO Tiller V2 Landing Gear Lever Then run this attached .reg file to remove the registry entries for those devices: removeDevices.reg Reboot and re-attach those devices. Download and use the attached FSUIPC7.ini: FSUIPC7.ini Then run FSUIPC7 and exit, and show me/attach those 3 files again. Is your "throttleTek 3" device no longer connected?

For help with MobiFlight, please use the MobiFlight discord channel. For help with FSUIPC6, please use the main FSUIPC support channel: https://forum.simflight.com/forum/30-fsuipc-support-pete-dowson-modules/ Not sure why you posted in the FeelThere support forum - shall I move your post to the FSUIPC support forum? Or do you require support from FeelThere? If so, there support platform has moved - see John

I will update later today if I find time, otherwise tomorrow or possibly on Monday morning. John

I have released 7.4.8 now - please update to the released version. Regards, John

Because FSUIPC is an embedded dll in P3D, and in MSFS2020 it is an external app/exe. With XINPUT, only applications that have the window focus will receive the input from such controllers. With P3D, FSUIPC will receive the input when P3D has the focus (as it is embedded), and with MSFS2020 FSUIPC will not receive the input as MSFS2020 will have the focus and not FSUIPC7.

First, you posted in the FAQ sub-forum where it explicitly states NOT for support requests. Please take care to post in the correct place if you require support. I have moved your post. What are these files? Where are they located? What do they contain? What do you expect FSUIPC to extract from them. i.e. what data do you want to find in the offsets from these files? As I do not know what files you are talking about, I expect that FSUIPC currently does nothing with these. Maybe you can attach an example and I will take a look. Is there a fixed location where these files are located/created? John

The xbox controller uses XINPUT protocol that is not supported by FSUIPC7. However, you should be able to use this by using a conversion utility - from the README,txt file (included in the zip file that you downloaded): Have you tried this? John

I think I have found the root cause of this issue! Looks to be related to the new Input Event interface which is still rather flakey - there are already quite a few issues/bugs reported in this. I have added further checks around this now which should prevent such issues Hopefully this will be the ;last beta and should prevent any issues. I will probably release this tomorrow or Sunday, after further testing. John FSUIPC7.exe

This is an interesting log as it shows when the button section was written as empty: I am not sure why this is at the moment (I will investigate), but the reload performed here on reception of the Input Events is not strictly necessary, so I have removed this in the attached version. Please try this version attached below. I have also added a further check to not re-write the buttons section if empty. John FSUIPC7.exe

Found one memory issue and it is corrected in the attached, so please use this version: FSUIPC7.exe

I just got the same issue but with the Keys section being overwritten... This is definitely a symptom of memory corruption somewhere...

Can you please use the attached version and send me the log again the next time this happens: FSUIPC7.exe I will continue to test here to see if I can also reproduce... John

No, this is not possible as various sections of the ini are re-written quite a bit...far too often in fact. I am adding some additional logging around the writing of the buttons section and will provide you an update version to use.

Ok, this is rather worrying... Looks slightly different than before as the [Button] section is now missing completely... From the log, when started, the Schweizer S300CBi White was loaded (last aircraft from previous session), and then you then switched to the "Bell 407 Blue Stripes" before starting the flight. When you switched aircraft, or started the flight, was the FSUIPC button (or any) assignment window open by any chance? Did you open any assignment window at all during this test? But that was even before the Bell was loaded, as was this one: I dont think this can happen during a flight as the buttons section is not read or written during a flight - only updated/saved when you are in the Button assignments dialog, and only when OK is pressed. I presume this occurred at some point before the flight was started. I will try and reproduce here. For future tests/flights (after restoring your FSUIPC7.ini), could you make a note of when you are using the FSUIPC UI, especially the assignments panels.

As your question is on FSUIPC7, I have moved your post to the FSUIPC7 sub-forum. Note also that 7.4.7 was released yesterday - please update. Most 3rd party apps do not require a key/licensed version, but some do. Looking at SkyDemon, that uses the GPSOut facilities of FSUIPC7 so a licensed/registered version is required. If you have purchased a license, you can always retrieve the license details from your SimMarket account. Once you have a license, you also need to configure FSUIPC7 to send out the GPS coordinates. For example, see John

👍

I think this may have been caused by an issue in the 7.4.7b release (a string termination was missing) that was fixed in the final release. The same issue could also prevent auto luas being started. Please restore your buttons in your Schweizer.ini file (by backup, if possible) and continue testing. Post your files if you have an issue. Its also strange that the lua auto issue has gone...

Ahhh - I see the problem in your Schweizer.ini file - the button section has been trashed: Hope you have a backup... This is worrying and I don't know what could have caused this....looks like a memory corruption error somewhere....I will investigate.... No button assignments in the Bell2206.ini, and the CabriG2.ini looks ok. Please take a backup of all your ini files before anything else....

Ok, but just a good idea to remove these assignments at some point. Understood, but you should clean-up your profile aircraft names and this won't cause any issues, and will make sure a profile is loaded regardless of the aircraft livery being used.

Understood, but may be tomorrow before I can review your latest files.

Btw, are all your devices attached to the server PC, or do you have some attached to the client PC? When the profile buttons are not working, are these in a device attached to the server PC or the client?

Not related to your issue, but a few problems I have noticed in your ini fille... You have assignments to these two missing joysticks - best to remove those assignments (or change the letters to an existing device) and remove those lines. You should update to use substrings in your profiles. e.g. change to Change to etc. Do this for each of your profiles, i.e. use a substring of the aircraft name that identifies all aircraft of this type you want to capture, and no others. Doing this will match the aircraft to the profile regardless of livery.