Peculiar button behaviour

[richardkennedy]

I've come across a very strange issue with 0.8.11 and 0.9.0 where a dynamic button state isn't being displayed and when pressed, the button above or below it activates. I can't reproduce these issues under 0.8.7 at present (rolling back appears to fully resolve this issue).

This seems to get progressively worse over time to the point that a page could contain half a dozen buttons which are displaying an incorrect state and on-press, surrounding buttons activate.

Not all buttons are affected by this behaviour. It seems random to some extent. Restarting the plugin or the sim appears to resolve momentarily and/or cause another couple of buttons to fall out of sync.

Any thoughts on what might be causing this? I'm not seeing anything in the FSUIPC7, SD or PD logs.

Aircraft: FlybyWire A32NX Stable
FSUIPC7: 7.5.5
PilotsDeck: 0.8.11
Stream Deck App: 7.2.2
MSFS: 2024

[richardkennedy]

Example Korry Button
The below works as expected under 0.8.7 (extinguished, DECEL or on). This does not work with 0.8.11 or 0.9.0. The button will either remain extinguished and never change state or will randomly display the DECEL status, regardless of what the in-cockpit state is. This can also be replicated with a Dynamic Button, so the issue appears to be related to the calculator code.

Top Half
(L:A32NX_AUTOBRAKES_DECEL_LIGHT, Bool) (L:A32NX_AUTOBRAKES_ARMED_MODE, Number) 2 == and (L:A32NX_OVHD_INTLT_ANN) 0 == (L:A32NX_ELEC_DC_2_BUS_IS_POWERED, Bool) and or 1 and (L:A32NX_ELEC_AC_1_BUS_IS_POWERED, Bool) and (L:A32NX_OVHD_INTLT_ANN, number) 2 == if{ 0.1 } els{ 1 } * (A:CIRCUIT GENERAL PANEL ON, Bool) *

Bottom Half
(L:A32NX_AUTOBRAKES_ARMED_MODE, Number) 2 == (L:A32NX_OVHD_INTLT_ANN) 0 == (L:A32NX_ELEC_DC_2_BUS_IS_POWERED, Bool) and or 1 and (L:A32NX_ELEC_AC_1_BUS_IS_POWERED, Bool) and (L:A32NX_OVHD_INTLT_ANN, number) 2 == if{ 0.1 } els{ 1 } * (A:CIRCUIT GENERAL PANEL ON, Bool) *

Command
A32NX_OVHD_AUTOBRK_MED_ON_IS_PRESSED (On 1, Off 0)

[Fragtality]

Interesting that 0.8.7 makes a Difference at all: Calculator Code is sloooow, the Sim/Asobo doesn't really want you to use execute_calcalutor_code in the WASM.
Generally it has to be polled on every Cycle since there is no Event-based Pattern. I'd also had a Case where a certain Profile Page would slow the Sim down because RPN Code (as Variable) was used extensively (multiple Composite Actions each with multiple C-Vars for Values and even Conditions).
So I'd expected to work equally bad under all Versions.

So what might be interesting to know: how is the Behavior of 0.9 with the SimConnect DLLs from 0.8.7?
But that would be only an interesting Fact: the long-term Solution is to migrate away from using RPN Code for Variables and instead using Lua Scripts for Values/States that are a based on a Expression over multiple Variables. They subscribe in a Event-based Pattern to the individual Variables and only does recalculate when a Variable has changed.

[richardkennedy]

I've just tested every release since 0.8.7 and the issue appears with 0.8.8. No change in behaviour for each release thereafter.

I tested the SimConnect DLLs from 0.8.7 with 0.9.0 and everything went south (every button showed all states at once as if the annunciation switch was on test) so I called it a day 🤯 I'll test this again.

[richardkennedy]

Using the 0.8.7 SimConnect DLLs with version 0.9.0 doesn't work unfortunately.

2026-01-28 21:24:54.751 [ERR] [ App.xaml:UnhandledExceptionHandl ] ---- PLUGIN CRASH ----

2026-01-28 21:24:54.770 [ERR] [ App.xaml:UnhandledExceptionHandl ] Exception catched: 'System.IO.FileNotFoundException' - 'Could not load file or assembly 'Microsoft.FlightSimulator.SimConnect, Version=12.2.0.0, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.'

[richardkennedy]

Just before I start converting the buttons to composites, do you have any other thoughts on this one?

[Fragtality]

Not really - it isn't reasonable to check what Change could be the Reason. IF it is a Problem of the Plugin at all (could be as well just the newer Version of the SDK).
There has been so much Change in the whole Time-Frame since 0.8.7 and in that special Period paired with something that is even discouraged by the Sim/SDK. And hasn't a good Approach for Updates :/

While Composite Actions are really great to define some Logic in the Action that would have needed external Logic in the Past - they are not a Requirement to use Lua!
It's really a Case-by-Case Decision: If something could be done completely within a Composite Action they are a good Choice to reduce the overall "Logic" Code regardless if it is RPN or Lua. Or just use the Opportunity of recreating an Action to build something new and exciting with the Flexibility of the Composite Action.
But you could as well just keep the same Action in Question and use a Lua-Function as Value-Address (with the defined Function doing the Logic/Comparison on the Sim Variables).

[richardkennedy]

Roger, thank you!

[Fragtality]

Also don't forget: Lua isn't a Problem distribution-wise if the Profile Packages are used ;)