John Dowson

What update? If you edit a previous post, you need to check the 'show the message has been updated' checkbox and specify the reason in the provided text entry field, otherwise it is not noticed.

I'm checking this and will get back to you at some point, but it may take a while.

Ah, ok. Thanks for letting us know.

Ok, thanks.

I'm not sure, which is why I am asking for you to check. is that the config you have when you experience this issue? If so, then no. But if your assignments were previously different, then please check again with those assignments (presuming each of those axes is also calibrated in FSUIPC7 - if not, do that first).

@ark1320 I've just tested the numeric keypad input and it looks like FSUIPC is not receiving the input events for these keys. Not sure yet if this is an MSFS or FSUIPC problem, I'll take a look. In the mean time, I suggest you assign to other keys. John

That log file shows nothing, not even any key presses, although you have Button & key logging activated. Are you sure that either MSFS or FSUIPC7 has got the focus during your tests? Can you also update to the latest FSUIPC7 build, with date 08/09/2020. Thanks.

Ok, this is normal when using the PFC dlls and is nothing to worry about.

This is not the case anymore. ou can assign in both MSFS or FSUIPC7. Just make sure that you don't assign the same axis (or button/switch/keypress) both in MSFS and FSUIPC7. Its probably a good idea to create a 'FSUIPC profile'. But this can have assignments and doesn't necessarily have to be empty. John

Can you check if this is calibrated in FSUIPC7. If so, remove the calibration. Or, alternatively, change assignment to ;direct to FSUIPC calibration' instead. Also, check that you don't have auto-rudder enabled (presuming this is an option in MSFS, as it was in FSX/P3D).

I doubt it. I've just checked my install (deluxe steam version), and all aircraft have an aircraft.cfg except the following: Baron G58 C152 Aerobat C172sp-classic DA40-TDI DV-20 Longitude Pipistrel Savage Shock Ultra SR-22

SPAD will not allow you to assign in FSUIPC - it has its own interface. You need to uninstall the Saitek software, and I think also the drivers, so please try that. Note that when you had this working in FSUIPC4, you must have been using something else other than just FSUIPC4. Images of text are not very helpful.

Could those who experience the disconnect due to the SimConnect issue (with TransmitClientEvent failures) please check their ini/assignments. It seems that there is an issue when assigning to the FS control (i.e. not direct to FSUIPC calibration) but then calibrating in FSUIPC7. If you do this, can you either update to 'direct to FSUIPC calibration' and calibrate, or if you sent to the FS directly, then delete the calibration in FSUIPC7. Thanks.

Please note that there are known issues with flight loading at the moment, so use this feature at your own risk. I'll take a look at your logs later and get back to you, but could you check your MSFS settings in relation to this, as reported in similar post (FSUIPC7 Control problem): John

Did you not read the announcement or the README.txt file provided in the xip: John

@zkiwi, @jaxx& @Fremmed Thanks for the logs. I;ll take a look, but no need to provide any more at this stage. Uoi can stop the logging now (SimConnect + FSUIPC). I also released a new build yesterday. This has the automatic re-connect in and also (hopefully) fixes the crash that this introduced - please download and try this version. Report back if it re-connects and continues working please (or if it doesn't!), bit no more logs needed at the moment for this. @N987PL Your issue is not related to the SimConnect error. I see you are using both the PFCcom and PFChid drivers - do you need both? Your PFC throttle is also recognised as a standard USB device, so that shouldn't need either driver. This is also very strange: 2408781 Attempt to set external joystick assigns refused Not sure what this means at the moment, I'll check, bit maybe you can determine which driver you actually need,, if any.

It looks like there is a new simvar for this - TRANSPONDER_STATE: Its also documented as read/write, but looks to be only readable at the moment. I'll find a free offset and add this, but it won't be writeable until this has been corrected in the SDK/ SimConnect. John

You do not have any keys assigned in FSUIPC7. You don't have any buttons or switches assigned in FSUIPC7 either. Your log file doesn't show much. Could you activate logging for Axes Controls in FSUIPC7. Once activated, exit FSUIPC7 and restart . Load an aircraft and then move your throttle through its full range, from 0 to full and then back to 0. Then open and close the axes assignments dialog and repeat. Send me the logs. There is currently another support request from a user with a similar problem, although his throttle (also mixture/prop) starts working after he has opened and closed the axes assignment dialog, which is why I would like you to also try this. See Probably also worth trying with a different aircraft as well, although it works fine here with the TBM 930. John

Your log file doesn't show anything as FSUIPC7 was not connected to MSFS. Was MSFS running? What do you see in the title bar of FSUIPC7? When you start FSUIPC7, it should initially have the title 'FSUIPC7: Simulator not detected'. When it detects MSFS, this should change to 'FSUIPC7: Simulator is available: Trying to connect....', with a log entry of 'Simulator detected'. And when FSUIPC7 connects, this changes to 'FSUIPC7: Simulator is available: Connected'. So, I am surprised that anything works!

Is there a new update? What is the version? I am still on 1.7.14.0, released on the 28th August. Even if you assign in MSFS? Seems like a problem for MSFS then. Could you attach your FSUIPC7.log and FSUIPC7.ini files please and I'll take a look. John

@borgfan & @IanAbel I have now added the ICAO designator, manufacturer and model (read directly from the aircraft.cfg file) to the following offsets: icao_type_designator: 0x0618, 16 bytes (including string terminator) icao_manufacturer: 0x09D2, 16 bytes (including string terminator) icao_model: 0x0B26, 32 bytes (including string terminator) However, not that these will only be available if the full path name of the aircraft.cfg file is received AND if it exists! I say this as, during testing this, I noticed that when loading the C172 classic (without G1000), I receive the aircraft.cfg file as D:\MSFS2020\Official\Steam\asobo-aircraft-c172sp-classic\SimObjects\Airplanes\Asobo_C172sp_classic\aircraft.CFG However, this file does not exist....! There does not seem to be an aircraft.cfg file for this aircraft model. Also, it seems that the path to this file is relative if/when you start FSUIPC7 AFTER the plane has been loaded in MSFS, but the full path is given if you load or change the plane when FSUIPC7 is already running. I will post to Asobo about these various issues. I will release the build containing this update later this evening (or perhaps tomorrow morning). John

The Saitek switch panel is not recognized by FSUIPC/windows as a hid device. To use this, you are better off using the SPAD driver (free) or SPAD.next (payware).You can also use via lua, but have not tried this - see John

Sorry, but you log doesn't tell me much as its a 'continuation' log - I can't even tell what aircraft you were using. Anyway, it doesn't matter, I think I know what the issue is, but need to look into this a bit further. I'll get back to you, but I suspect that the airbus is not updating the AUTOPILOT ALTITUDE LOCK VAR simulator variable correctly.

Btw, how are you sending the alt/dec controls? Is this using FSUIPC, or are you operating it in the UI? If the latter, can you activate event logging in FSUIPC, and see what events are being sent when you do this. I suspect that FSUIPC may not be seeing the alt/dec events in the Airbus,, but are in the Boeing.

Ok, I'll take a look. Thanks.