John Dowson

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.

What problems? Not sure what you mean by 'install it under Windows 8 compatibility' - thought that was a run option. Anyway, that certainly shouldn't be needed to install FSUIPC7.

License sent via PM. John

Please attach a full FSUIPC7.log file (i.e. do not use the New Log button) as well as your FSUIPC7.ini. I can't see how those changes could cause this logging to restart - looks like the DontLogThese isn't set, but your files should show the reason...

👍😎

License sent via PM. John

Not by default. How are you doing this? The only way to read a simvar not held in an offset in lua would be to execute some calculator code to write the simvar value to an lvar (local variable) and then read the lvar. However, the best way to read (and write/update) to the AVATAR MODE IS ATTACHED simvar would be to add it to a free FSUIPC offset and then use that offset. To do this, please see the Advanced User guide section Additional Simulator Variables (simvars) to FSUIPC Offsets on page 36. John

Did you add the simvar AUTOPILOT HEADING LOCK DIR to that offset via the myoffsets.txt file? Do you see the following entry in your FSUIPC7.log file: ? Please attach files, not pictures.

By default, in your FSUIPC7 installation folder... John

Do you have any issues with that script?

First, you posted in the User Contributions sub-forum where it explicitly states NOT for support requests. I have moved your post to the main support forum What do you mean by shortcuts? Why not just assign to the standard controls? Or if the aircraft comes with an SDK and/or custom controls, you can try using them. Is this an add-on aircraft, and if so by who? If you look in your FSUIPC Documents folder, you will see a text file that contains a list if all available controls - open that in an editor and search for the controls you need. They are all available from the assignments drop-down menu. e.g. for heading try: 65880 HEADING_BUG_DEC 65879 HEADING_BUG_INC and/or the FSUIPC added controls (see Advanced User guide p 29) 1024 Heading Bug Dec Fast (–10) 1025 Heading Bug Inc Fast (+10) There are similar controls for SPD and ALT. John

Not 100% sure, but it will probably be missed, but this depends when the event flag on the button press is cleared - either when the function is called (in which case the 2nd button press will be registered) or when the function is finished (in which case it will be missed). I think its the latter, but should be easy to write a simple test lua to clarify if needed. Anyway, the function should really finish before the second button press, and you can also use button repeats. John