John Dowson

But why does SayIntentionsAI need to see this? If the button on the intercom switch of the Airbus Radio Control Panel triggers this and writes to an FSUIPC offset (via the "gate"), then you can have a lua script that monitors the offset and sends the required PTT control to the FS. How is the current PTT button assigned - is that in FSUIPC or elsewhere?

Thats exactly what the script should be doing. This is what I requested above --> My intention would be to have the pedals disconnected as long as the button is being pressed down and to reconnect them as soon as I release the button. So it is still disconnecting when the assigned button is pressed? This wasn't clear from the OPs original post. The issue is probably that he is using a momentary button, rather than a sticky button or switch, and so the diconnect is activating then de-activating on each button press/release. If he wants 1 press/release to toggle on, and another to toggle off, then he should use the MF preset, and update that to also trigger the animation if needed. John

But how are you expecting to trigger this virtual button press? Rather than the trigger writing to offset 0x3340 to trigger a virtual button, that then triggers the PTT, why can't the initial trigger just trigger the PTT directly?

And when the button is down, are the pedals not disconnected? Those presets consist of 2 parts - one to control the function (via the lvar L:S_FC_CAPT_TILLER_PEDAL_DISCONNECT) and one to control the animation (via the lvar L:S_FC_CAPT_TILLER_PEDAL_DISCONNECT_Anim). So it seems that the functional part is not working. There is also an MF preset for this which acts as a toggle- FNX320 Misc Tiller Pedal Disconnect Captain Press. That just controls the functional part. Can you try that preset to see if it works for you?

I think you are misunderstanding the functionality provided by offset 0x3340. Setting a button flag in that offset range will trigger a virtual button press in fsuipc, which will trigger the button assignment in FSUIPC and you can see the button in FSUIPC's button assignment panel for assignment. it cannot simulate a button press for other applications, i.e. it is not possible to force/send an actual button press event for other programs to action. John

I thought FSUIPC could handle up to 64 devices, but looking at the code that writes the [JoyNames] section it only writes 16 devices. Not sure why - I will check this and get back to you, but probably not until next week. Could you please set a custom log value (Log -> Custom) of 0x200000. restart FSUIPC7, exit and then attach your FSUIPC7.log, FSUIPC7.ini and FSUIPC7.JoyScan.csv files.

First, only a subset of simvars are added to FSUIPC offsets. And I do not add any new simvars to offsets unless by request and I think it a useful addition for everyone. Several years ago I added a new facility in FSUIPC to allow the user to add any simvar to a spare/free FSSSUIPC offset via a file called myOffsets.txt. Please see the Advanced User guide for details on using this feature. Note also that as FSUIPC7 is compatible with both MSDS202 and MSFS2024, it is build using the latest SDK for MSFS2020 and not the MSFS2024 SDK. However, it should still be possible to request simvars from the MSFS2024 SDK, but make sure this is only done when using MSFS2024 and not MSFS2022. John

First, please use the FSUIPC7 / MSFS support sub-forum for all issues/questions with FSUIPC7 and not the main support forum which is for all other versions/products. I have moved your post. Yes. The main cause of such stuttering is excessive logging by MSFS. Can you check the MSFS logging console to see what messages are logged, and if they are being logged at a very fast rate (you will need to activate Developer mode in MSFS to see the logging console). Does this occur with all aircraft or only a selection (please try both simpler/ GA aircraft and more complex ones)? Excessive logging can be caused by FSUIPC requesting variables from the new fuel or electrical system in an aircraft that does not use them. FSUIPC does not do this by default, and so if this is the cause it is due to a simvar being requested via the myOffsets.txt file. So, if using that file, check to see if it has any such simvars added and if so you should only use that file when flying an aircraft that uses the new systems. Please attach your FSUIPC7.log and FSUIPC7.ini files, as well as your FSUIPC_WASM.log file. Please only attach files once FSUIPC7 has exited, and only attach the WASM log file after exiting MSFS.

I am not sure I understand this - how is your controller assigned, in FSUIPC or elsewhere? The software cannot send such events to FSUIPC and all events are received from the FS. So I suspect that it is the Elite software that is sending the events to the FS, and then FSUIPC is receiving them for logging purposes and possibly for calibration. It should be possible to calibrate such events when not assigned in FSUIPC or when assigned but not with 'Send direct to FSUIPC Calibration', as long as the ini parameter AllowSendToFSCalibration is not set to No. If you cannot see any movement in the elevator trim calibration tab, could you please activate logging for Axes Controls, load your aircraft, move the assigned elevator trim axis through its full range and back again, exit FSUIPC7 and show me / attach your FSUIPC7.log and FSUIPC7.ini files. John

I have updated the display vals.lua script to use the Wnd library in the attached version. John display_valsW.lua

If you are having issues, please attach your log files (FSUIPC_WASM.log and FSUIPC7.log, with appropriate logging activated) and I will take a look.

What do you mean? You should be able to control this aircraft already, either via standard controls, lvars or presets - there are currently 386 presets available for this aircraft. There is currently no access to the iFly SDK - I will look into adding these (as read-only offsets) at some point when time permits - see John

No - as I said, the folder for saved flights is determined by the FS.

No - the folder for saved flights is determined by the FS. FSUIPC delegates the flight save/load operations to simconnect API. Unfortunately in MSFS2020 (and MSFS2024) the flight save function is still not working 100%, and is still documented as "NOTE: The current status of this function is NO ERROR, NO RESPONSE", which is Asobo's way of saying that this function still isn't 100% reliable. So the flight load/save functionality needs to be used with caution, and seems to work better in some aircraft and not in others. There is nothing I can do about this in FSUIPC and this needs to be fixed/addressed by Asobo. John

This has been on my To-Do list for quite some time already - I will look into adding such functionality when time permits. John