Download and install the MSFS SDK, by enabling the developer mode (a download option is available in one of the developer menus).That’s a bummer, since I just optimised my requests in such a way that I only send (the previously sampled) values when there is an actual value change. for every simulated frame - set the same value. That implies that if I want to keep the canopy open I need to repeatedly - e.g. I just noticed that the canopy seems to close automatically again, each time I set the CANOPY OPEN simulation variable to a value > 0 (with unit “Percent”: 100 = fully open, 0 = closed). So I’d argue that “this is the expected behaviour”.Īs 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:ĬANOPY OPEN: Needs to be constantly "refreshed" (canopy closes automatically)? SimConnect Now here is the thing: whereas I cannot really judge the situation with the CANOPY OPEN simulation variable (two aircrafts both “automatically close the canopy”, two other aircrafts do not react at all) with the FLAPS HANDLE INDEX it is a bit different: all default aircrafts retain the set FLAPS HANDLE INDEX value, and so do all other 3rd party aircrafts that I have tested so far (and have access to). Or it is simply a bug in the SimConnect server implementation in FS2020 itself, who knows… And as discussed in the SDK topic the other two aircrafts (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. 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). Now I am not familiar at all with “designing aircrafts” and I merely know about the existence of those “local variables” (also called L:vars). 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. 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”. Every time the handle index is changed by Sky Dolly it is immediately changed back to zero. But in a replay with the Arrow, there is a fight going on.
0 kommentar(er)
