John Dowson

This surprises me as it was only a fix to restart the SimConnect connection when the TransmitClientEvent failure is received. Has nothing else changed? Do you still get the TransmitClientEvent failures and it reconnects ok, or have the failures stopped? I am surprised at either! @flash In your case you get the failures and its trying to restart the connection, but is still getting the failures on restart. It then crashes on the 3rd reconnect. As Pete says, please check the Event Viewer to see if there is a crash report for this.

You could try this version to see if it prevents the crash and if it re-connects successfully. It wont fix the original problem, the TransmitClientEvent failures, which is still under investigation: FSUIPC7.exe It if still crashes, can you show me your log again please.

You have this problem: It is being investigated. FSUIPC7 is also crashing as there is a problem with the automatic re-connect on this failure (by default after 5 failure messages, but configurable) - this should (hopefully) be fixed in the next build.

I've added this at offset 0x0B46 (1 Byte). And its also writeable! This will be in the next build release, within the next few days.

Have you checked the system tray? Note also that FSUIPC7 exits automatically when MSFS shuts down if the Exit with FS option is checked (in Options menu). If that's not your issue, and you think FSUIPC7 has crashed, please show me your FSUIPC.log file, and check for a crash event in the windows event viewer. Why do you also have the pfc.dll and the pfcfsx.dll in the same folder? Try removing/renaming those - you should just need the PFCcom64.dll.

Could you attach your FSUIPC7.log file please.

No, not possible in FSUIPC I'm afraid, you can only assign to one key + modifiers. However, I have added pass-through of multi-key assignments to to MSFS,for when FSUIPC7 has the keyboard focus.

There are some issues with key press assignments at the moment. This will hopefully be corrected in the next build update/release.

No, control numbers have not changed.

But that will only ignore that axis for that assignment "session". When you close the assignments panel, it is again 'seen' by FSUIPC. You can see this by going into the axes assignment panel again, and you will see that the axes are again visible. So, this makes no difference when the axes assignment panel is closed.

Hi Günter, This is an error from P2A. You need to contact their support - I cannot advise on other 3rd party products that use FSUIPC, sorry. John

FSUIPC6 runs as an embedded dll in the sim, and so the sim is always running/available in FSUIPC6 (as well as FSUIPC5, FSUIPC4, etc). FSUIPC7 is now an exe, and runs independently of the FS. However, this can cause issues if the sim is not running and you are using specific hardware/drivers that expect the sim to be available (or, at least, the offsets in FSUIPC populated when the sim becomes available). If using such devices, then you really need MSFS running.

Ok, but this has nothing to do with FSUIPC. Yes, there seem to be quite a few issues with the A320 Neo at the moment. There are currently many controls that work when assigned in MSFS, but are not working in external programs using SimConnect. It is a known issue and we are awaiting an SDK update to resolve these issues. Cheers, John

Ok, so you weren't using the GFdev64.dll on P3Dv5, so this makes more sense. I have no idea what the GFDevP3Dv4.exe is - does this work with MSFS, or is their an equivalent one for MSFS?

Yes, should be.

Fully up, with a slope value of -15 is more sensitive around the center point, and fully down with a slope value of +15 is less sensitive around the center point and more sensitive around the extremes. I'll post some pictures of the slope curves with the different values when I get a chance. Btw, which PFC driver are you using? If its the PFCcom one then you should calibrate in the driver UI and not assign/calibrate in FSUIPC.

Hi Hans, an interesting idea. It should really be the other way around, with FSUIPC7 starting automatically with MSFS, as it does for other FS versions. However, this will only be done once I've written the installer AND we know how to do this. I haven't seen how this can be achieved at the moment and am waiting for details on this from Asobo. There are also complications due to the different installation processes using Steam and MS Store. But I'll keep this in mind. Thanks for the suggestion. John

What do you mean by this? What 'task bar'? There is currently am issue with control loss due to a TransmitClientEvent failure that will be seen in the logs. If you have this in you logs, then this is already being investigated, and there is another topic covering this. And there is also this topic for control loss without this failure being noted: No solution at the moment as I'm still trying to determine if this is an MSFS issue or an FSUIPC7 one. Note also that someone previously reported this is a problem and it turned out to be an automatic co-pilot takeover that somehow got activated. Maybe worth checking for that as well. Otherwise, it would be helpful if you could determine if it is only the controls via FSUIPC7 that stop working, and if any assignments you have in MSFS are still functional.

Can you show me your FSUIPC7.ini file and I'll check the calibration. Not sure what this is or means! Ok. That would explain the RUDDER_SET events in your log.

Sorry, what does this mean?

I'll check further if its possible to set via events/controls - I think I checked this previously but it wasn't working, but I'll check again. If not working, I will report to Asobo on this issue.

Yes, its not updating the AUTOPILOT ALTITUDE LOCK VAR simulator variable on the AP_ALT_VAR_SET_ENGLISH event. I have reported to Asobo.

Offsets 0x05C4, 0x05C8, 0x05CC & 0x05D0 are no longer writeable. in MSFS, so for read only. Its not a bug unfortunately, but stated as read-only in the SDK documentation. The FUIPC7 offset status documentation documents these in red for writeable, i.e. not working.

But how was it working in P3Dv5? With LINDA and the GFDev64.dll? And you could see the devices buttons/switches in the FSUIPC assignments panel? Your log shows the device detected ok: I'm just wondering if LINDA is masking the input from that device somehow. Try temporarily disabling LINDA and see if the device is then visible in the assignments panels.

Please see John