John Dowson

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.

I don't think this is necessary. Are you saying that the AP Alt inc/dec controls are reflected in offset 0x07D4 for the Boeing directly when sent, but not in the Airbus until you confirm with the AP Alt (set) button/control?

But this is correct, no? The offset only changes when the AP Alt is set.... I'm a bit confused now.... let me check this....

It is 0x07D4. I'm not sure I understand the log snippets you posted. How did you generate them? The A320 log (which you say isn't working) is using the AP_ALT_VAR_SET_ENGLISH event - is this via offset 0x07D4? The Boeing log only shows inc and dec controls,.

If it works on the Boeing but not on the Airbus, it sounds like an issue with the Airbus model. I'll take a look and see if this needs reporting to Asobo, but I don't think this is an issue with FSUIPC7. I'll report back once I've investigated. Thanks for the report.

That is strange. Could you activate logging for Axes Controls in FSUIPC7. Once activated, exit FSUIPC7 and restart (with MSFS running and an aircraft loaded). Then move your throttle. Then open and close the axes assignments dialog and then move the throttle again. Post the log file together with your .ini. Thanks.

No, as this would mean that it is not possible to send the full axis range, which seems a strange thing to do... joystickcurves looks interesting though.Shame its an application rather than an API! Improving the response curves to something like that used by jjpystickcurves could be added at some point in the future. However, this would be a lot of work for only a small benefit. It is something I can look into in quieter times... Thanks for the suggestion. John

I'm not sure if uses Simconnect, but probably not as I can see no other 'Open' calls in your SimConnect.log. Maybe check for that in the full log to be sure.

Btw, are you using any other SimConnect clients, or any 3rd party add-ons that use FSUIPC?

I doubt it, it shouldn't matter where FSUIPC7 is installed. I recommend you follow the advice in that link, and uninstall and re-install the VC runtime.

Sorry, but I need some more logging activated in FSUIPC. Could you go to the Log -> Custom menu entry, and enter x400, then repeat your tests. The FSUIPC7.log file produced will also be very big and may need culling. Thanks.

Sorry, I didn't realise your issue was that the buttons are outside the usual 0-31 (32 buttons) limit. You will have to use virtual buttons to get these recognised, as given in the solution posted by @jaxx (thanks!). John

Activating this control locally, I can see it being logged when you click the ADF frequency swap button in the UI, but sending this event via SimConnect/from FSUIPC has no affect. I'll also report this. Thanks for the report.

Hmm. This has been reported twice before on other versions of FSUIPC, and in both cases we could not determine why this happens, as the slope display is using standard windows API calls. Its maybe be related to a driver issue, but can't be sure. I'm afraid I don't think there's much I can do about this. See .

Ok, thanks - thats what I was looking for! I'll take a look.

Ok, thanks. I'll report this. That control was removed as it is not listed in the MSFS documentation. I'll re-enable locally to see if it still works and, if so, I'll add it back. I'll report back on this.

Strange...thanks for the update.

Why "by hand"? Magneto Left is a valid control. Turning the magneto in the C172 I see it uses the MAGNETO1_SET control, with parameters 0,1,2 for the various positions. You could try that. I'm off now, I'll look into this in more detail tomorrow if you are still having issues.

There are various types of variables used in XML gauges. I'm sure something similar to lvars exists, but I don't know if they are called 'lvars'. Somebody else may be able to explain this better - I'm not a guage programmer. However, as far as FSUIPC is concerned, it doesn't matter. Previously, in P3D, LM provided access to such variables through the Panels.dll. In MSFS, we only have access to data through SimConnect at the moment, and SimConnect provides no way to access anything that is not exposed through that API. We are still waiting for information on what facilities, if any, will be provided to access such data.

I mean the VCRUNTIME library is not installed correctly. Please see the release note or the provided README.txt file. This is explained there, under Issues, with a link on how to resolve this.