John Dowson

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.

If you can't find an existing topic, please create a new one with a relevant title, rather than posting in another topic that has nothing to do with your issue. I have moved your post to a new topic. Throttle2 (Direct) will use AXIS_THROTTLE2_SET, so the settings are basically the same. The only difference will be that Throttle2 will be calibrated before being sent to the FS, and Throttle1 will be sent uncalibrated, received back and masked, calibrated and then resent. Probably better to have them both assigned the same way though. Not sure why the Aileron assignment isn't working though - assigning direct to Aileron works fine here. If you go to the axis assignment calibration tab, do you see the axis/in-out values change for the aileron? You can also try logging Axis Controls (Log -> Axis Controls) open the logging console (Log -> Open Console) and see if you can see the aileron axis values being sent. You may see a lot of LIGHT_POTENTIOMETER_SET events logged - you can ignore these by adding DontLogThese=67227 to the [Profile.DA62X] section of your FSUIPC7.ini file. Please report back what you find, and maybe also attach your log again, if relevant. I am finishing now for the day - I may take another look tomorrow, but if not it will be on Monday now. John

But why U32? That is 4-bytes. You are adding this as 2-bytes: You should therefore use U16, as I said...

It is probably started from your ipcReady.lua.... but it doesn't matter if you don't have any issues. Your log shows that offset A000 is being updated with the correct heading, you are just logging that offset incorrectly as far as I can see....

It is not a FLT64 (8-bytes) but a an unsigned word - 2 bytes (U16) , as also used in the lua script (UW) - try logging it as that (i.e. U16), and also please send the offset logging to the normal log file as well. The logging in the lua is definitely showing the correct value: You still have Linda running and have not set only the logging asked for... John

What is the issue? It looks like the script is working: ? Can you please explain what your issue is, and attach a full log file (i.e. always please exit FSUIPC7 before attaching a log file, and never use the New Log feature) with logging for lua plugins enabled (and no other logging set please) as well as offset monitoring for offset A000. Also please disable Linda for the time being - you can re-enable it after we have solved your problem. John

License sent. John

This can happen if/when FSX crashes, even though the crash is not related to FSUIPC. You can usually safely ignore this, but if it persists, please see this FAQ entry: If the crash is not related too FSUIPC, I am not sure that I will be able to help. Can you attach an FSUIPC4.log file from when FSX CTDs and I can take a look. Does the crash still occur when not using Vatsim or vPilot? You could try setting FSUIPC to no receive Ai data to see if that makes a difference - to do this, set ProvideAIdata=No in the [General] section of your FSUIPC4.ini. There is a known issue that can cause CTDs with FSUIPC, which is a corrupt weather file. However, this usually results in a CTD soon after start-up. You can also eliminate this by using the following ini parameter (also as a test): NoWeatherAtAll=Yes

You have Event logging acticated, as well as some other logging (00000005). If you don't want logging, deactivate it from the :Log menu. Please read the section on logging in the User guide.