Yes, I am sorry, that was my confusion: I placed the “Flaps Position” value under “Secondary Controls”:
(Please ignore the displayed values: those are randomly generated “test values”)
The “Flaps Position” (simulation variable: FLAPS HANDLE INDEX) is a value between 0 (“flaps fully retracted”) and the number of flaps handle positions (minus one).
(You can hover the mouse over any value and it will reveal the underlying “simulation variable” as tooltip - that is usually only of “academic interest”, for the more technically inclined users ;))
That’s what I suspected as well: depending on how the aircraft is modelled it may give its own “local variables” preference, or the (externally readable/settable, via the “SimConnect API”) “simulation variables”. In my opinion the later simulation variables should always take precedence - that is, if a given simulation variable is set to a certain value then that value should be the “single source of truth”, until changed again later on.
Now I am not familiar at all with “designing aircraft” and I merely know about the existence of those “local variables” (also called L:vars). For instance the mentioned Spitfire and T-45C Goshawk do not react at all to the “official” CANOPY OPEN simulation variable: they use their own “local variables” for the canopy animation (and operation). And as discussed in the SDK topic the other two aircraft (that I have access to) - the Fiat G.91 and a freely available “Alpha Jet” - automatically close the canopy (possibly for the same reason: they might use “local variables” internally as well, which - wrongly, IMHO - take precedence over the CANOPY OPEN simulation variable. Or it is simply a bug in the SimConnect server implementation in FS2020 itself, who knows…
Now here is the thing: whereas I cannot really judge the situation with the CANOPY OPEN simulation variable (two aircraft both “automatically close the canopy”, two other aircraft do not react at all) with the FLAPS HANDLE INDEX it is a bit different: all default aircraft retain the set FLAPS HANDLE INDEX value, and so do all other 3rd party aircraft that I have tested so far (and have access to). So I’d argue that “this is the expected behaviour”.
As I do not have access to the Arrow, if you want you could help me prove the above theory, as done in the previously mentioned SDK discussion:
That is:
- Download and install the MSFS SDK, by enabling the developer mode (a download option is available in one of the developer menus)
- Start FS2020
- Start a flight
- Start the SimvarWatcher example application, located in
C:\MSFS SDK\Samples\SimvarWatcher\bin\x64\Release - Click on the “Connect” button
- Add the FLAPS HANDLE INDEX simulation variable, with unit “number”: “Add Request”
- At this point the simulation variable should display the currently set flaps handle position
- Now try to set the value to a value between 0, …, N-1 (where N is the number of flaps positions, including “fully retracted” = 0)
- (Uninstall the SDK again)
Now my theory is that with the Arrow that value would immediatelly go back to 0 (when it should really retain its value).
Is that the case? Well, you basically already illustrated that case with FSUIPC, but reproducing it with the “SimvarWatcher” example app would be the “ultimative proof” (because that is essentially what Sky Dolly is doing).
Also refer to a similar discussion, which illustrates the “SimvarWatcher” user interface: