John Dowson

The lvar holds the correct value but writing to this does not update it. The MF in/dec presets work, but I don't know what can be used to set a specific value.

Ok, the install log shows the 3 simconnect versions installed, so this should be ok... You could try a clean FSX install first... Sorry, but not sure what else I can advise.

It looks like the VS uses the lvar L:A32NX_AUTOPILOT_VS_SELECTED. Try listing the lvars to see if that holds the correct value, and if so add that to a free FSUIPC7 offset. See the section Adding Lvars to Offsets in the Advanced User guide (P46) on how to do this. I don't know if writing to that lvar is working to update the VS, but you can also try that by writing to the offset that holds the lvar, and FSUIPC will try to update the lvar value. Note that the MF presets for the VS in/dec use the following calculator code: inc: (L:A32NX_TRK_FPA_MODE_ACTIVE, bool) 1 == if{ (>H:A320_Neo_FCU_AP_INC_FPA) } els{ 3 (>K:AP_VS_VAR_INC) (>H:A320_Neo_FCU_VS_INC) } dec: (L:A32NX_TRK_FPA_MODE_ACTIVE, bool) 1 == if{ (>H:A320_Neo_FCU_AP_DEC_FPA) } els{ 3 (>K:AP_VS_VAR_DEC) (>H:A320_Neo_FCU_VS_DEC) } So it looks like updating this depends on the track FPA mode - whatever that is... Later: there is also the lvar L:A320_Neo_FCU_VS_SET_DATA that may also be worth adding and checking.... - checked this and this doesn't hp;f the set value, but the lvar L:A32NX_AUTOPILOT_VS_SELECTED does, but haven't checked if it can be updated...

Shouldn't this be 0x07FA (Autopilot RPM (N1) hold value, 16384 = 100% N1) - did you try that one? Don't the same offsets also show the throttle axis value and engine N1 values when AT is engaged?

Nom that was for FSX-SE - I only have the steam version, which is 10.0.62615.0. That is because they are trying to install 10.0.61259.0 which you already have installed. Oy seems that FSX Acceleration uses 3 simconect versions: I am not sure what the difference is between microsoft.flightsimulator.simconnect and the Simconnect.dl and why these are at different versions, but I guess you are ok with the versions installed. Could you attach your FSUIPC4 Install.log file please as that will tell me the simconnect versions installed/detected in your system. But I don't think this can be related to your CTD issue.

With version 7.3.20 or 7.3.21? If its working with 7.3.20, can you try 7.3.21 again please. Before re-installing, just rename your FSUIPC7.exe to FSYUPC7.exe.7320 so that, after the newer version is installed you can easily switch back to the older version if needed. If its now working in 7.3.21, I don't know what could have caused this temporary issue... If its working in 7.3.20 but not un 7.3.21, I will need to look into the cause... Thanks, John

That is the xpack installer, not the simconnect one. If you go to your FSX installation folder. look under SDK\Core Utilities Kit\SimConnect SDK\LegacyInterfaces\FSX-XPACK and you should see a SimConnect.msi file/installer there - try that one. Ok, no problem - just wanted to confirm you had tried this to rule out the possibility of a corrupt weather file.

I am not sure if this is possible in FSX. You could try activating logging for Events (non-axis controls) and see if anything is logged in your FSUIPC4.log file, and if so then try using that. In MSFS, this is possible in the FBW and Fenix versions of the A320, but not in the default/Asobo one, as far as I am aware. John

No...that is the logging console. As I said, you close that using the Log -> Close Console menu option. Sorry, but I don't understand what is so complicated about this... The logging console is open when requested, and stays open until you close it....

It should be un the system tray. You can open it using the (default) hot-key combination of Alt+F. If you see the splash screen, it should be running, unless it has either exited or crashed. If you are sure it isn't running, please show me/attach the FSUIPC7.log file generated (and before you start FSUIPC7 manually). John

Ok. Strange an improvement mod would do that. I will take a look at that mod when I get a chance... The console window is open until you close it, using the Log -> Close Console menu option. FSUIPC7 always starts iconised to your system tray, unless you always want to displau the main window when it is started by adding the following to your FSUIPC7.ini: OpenOnStart=Yes To show/hide the main window, you can use the (default) hot-key assignment Alt+F. You should at least read the User guide to familiarise yourself with the FSUIPC7 basics.... John

License sent via PM. John

There is a mismatch between your FSX version and the Simconnect version: 31844 Running in "Microsoft Flight Simulator X", Version: 10.0.61637.0 (SimConnect: 10.0.61259.0) You could try installing and using SimConnect 10.0.61637.0 to see if that makes a difference. That wasn't in the ini file you linked to, but if you have tried with no weather requests from FSUIPC and you still get this issue, then it will not be relayed to a corrupt weather file. You are using an unregistered version of FSUIPC, so all FSUIPC is doing is supporting your add-ons. Then I really don't have any further advice, sorry. John

Have you tried deleting your fsx.cfg file and letting that get rebuilt? Otherwise it could be caused by another FSX add-on. What add-ons do you have installed? And have you tried uninstalling them and adding them back one-by-one until you find the culprit? Have you at least tried the NoWeatherAtAll ini parameter to tule out a corrupt weather file? Other than that, I can't really help with FSX CTDs that are not caused by FSUIPC. Have you tried the avsim CTD guide for advice, and there are many other FSX CTDs in API.dll reported on avsim...

Done.

That thread was for when you have to trust FSUIPC every time you start FSX. If you don't need to do this, then you can ignore that. Does this happen each time you load that flight plan? Can you also please post the crash event from the windows event viewer. You could try setting NoWeatherAtAll=Yes just to make sure that this is not caused by a corrupt weather file. If it isn't, and the crash is not related to FSUIPC, I am not sure how I can help.... John

So the aileron controls are being sent to the sim, so I so not understand why they are having no affect. Do you not see the joystick on the DA62 moving left/right when you do this? If not, I don't know what can be causing this as it seems to work just fine here. Do you have any mods installed for the DA62?

Wouldn't offsets 0x3330 and 0x3332 be better? 0r 0x089A and 0x0932? I am not sure about this - best to just monitor the offset values using FSUIPC's offset monitoring facilities, to see how they change when the AP has control. May also be worth looking at offsets 0x0898 and 0x0930. I have moved your post to the correct support forum - hopefully some other motorized TQ users will see this and can help you... John

For the ATR throttle and condition levers, see the following post: Where is this assigned - in MSFS or FSUIPC7? You should have tried a trial license before purchasing.... Not necessarily - do you see FSYUPC7 running? If auto-start is enabled, it will start and sit in your system tray. You can also use the (defauly) hot-key combination ALT+F to show/hide the main window. You register your license at the end of the installation process. Please see the provided Installing and Registering FSUIPC7 document. Also please at least read the User guide. Yes, please see the provided documentation. There are also many support requests in this forum on settings for specific aircraft. it is recommended to start with an empty profile in MSFS if you are assigning in FSUIPC7, although you can mix-and match assignments between MSFS and FSUIPC7 if you so wish. However, make sure that that you are not assigning anything both in FSUIPC7 and MSFS - which is why i recommend starting with an empty profile in MSFS if assigning in FSUIPC7. John

Similar to the heading, 0x07F2 holds the AUTOPILOT VERTICAL HOLD VAR and 0x07EC the AUTOPILOT VERTICAL HOLD, so try them. There is also the custom events for the VS: A32NX.FCU_VS_INC A32NX.FCU_VS_DEC A32NX.FCU_VS_SET A32NX.FCU_VS_PUSH A32NX.FCU_VS_PULL so if writing to offset 0x07F2, you will have to do the same as you did for the heading - add the simvar to a spare FSUIPC offset and use a lua script to call A32NX.FCU_VS_SET when changed. John

License sent via PM. John

You can use any offsets that are designated as 'free for general use' in the offset status document, or any offset allocated to a 3rd-party aircraft or utility that you do not use. For example, the following are all free for general use: 0x2544 - 184 bytes 0x2644 - 184 bytes 0x2744 - 216 bytes 0x2ABC - 68 bytes 0x6174 - 28 bytes 0x66C0 - 64 bytes 0xA000 - 512 bytes John

Trial licenses have been sent via PM. John

The FSUIPC flight load/save/auto-save facilities rely on the flight load/save facilities provided by the MSFS SDK. Unfortunately, the flight save function is still documented as "NOTE: The current status of this function is NO ERROR, NO RESPONSE.", which is Asobo's way of saying that there is no guarantee that this function is working as expected. You could try saving/loading the FSUIPC offset data with an autosave, but I don't think this will help. To do this, select 'for Autos' for the Reload FSUIPC data option in the Miscellaneous panel (Options -> Miscellaneous). See the FSUIPC7 User guide for further details on this option. Other than that, as these aircraft are add-ons, I suspect that this issue must be addressed by the add-on aircraft providers. You could raise a support request with them about this issue. John

License sent.