AP A:vars FS9

[Guest rkruijer]

HelloTo check the status we look at the A:Var, to set it we use a K:VarK:AP_MASTER and A:AUTOPILOT MASTER for instance.What are the A:Vars for the following two?K:AUTOPILOT_OFFK:AUTOPILOT_ONThanksRoelof

[phjvh 0]

Hi,Did you check (A:AUTOPILOT MASTER,bool)?Probably the same A:Var. May be also (A:AUTOPILOT_ACTIVE,bool).Jan"Beatus ille qui procul negotiis..."

[rcbarend 37]

Roelof,Alos note that there are a lot of events that have simular functions and are read by the same variables.In general:"event"-toggle"event"-On"event"-OffThe latter two just set the "state" of the the funtion directly On or Off.As a sidenote: I don't like to use the "-On" and "-Off" events myself, but prefer the "toggle" version.Because the "toggle" version forces you to test the state first before giving the event to force it to a certain state. (avoids the "continuous event" problem).Cheers, Rob

[Guest rkruijer]

Thanks Gentlemen,The first one does the same as the second 2Like Rob said. If you cannot test the status, better not use them if you have the option.Roelof

[taguilo 33]

Roelof,Actually you don't need to test the status of the Autopilot to send either K:AUTOPILOT_OFF or K:AUTOPILOT_ON.Suppose you have a (Condition) that when met needs to turn off the autopilot. Then you assign true (1) to a control Lvar and issue(LAPshouldgooff) if{ (>K:AUTOPILOT_OFF) 0 (>LAPshouldgooff) }If the AP was ON, it will go to off, and will do nothing otherwise, because it was already off.There are lot of cases where this idea can be applied, and it works very well indeed.Tom

[rcbarend 37]

Hi Tom,Yes, of course your solution works as well.But what's the point in maintaining a local L:var to maintain such a state, while this state can easily be read from an FS variable ?(for those functions where FS has events directly visible in related variables).Because your method introduces a potential pittfall (which I stepped in myself a few times :-) ); and that is, that the Statevar may become out-of-sequence with the actual state.E.g.: at startup (from a saved flight) or when a user issues simular events as the gauge does, like via key/button commands.Now, this mis-synchronisation by itself isn't harmfull, if it's only used for the above purpose (because it only may give one event,not a stream, too many. But if you start to use this local State variable for other purposes as well, you might be in trouble :-)Cheers, Rob

[taguilo 33]

Hi Rob,""But what's the point in maintaining a local L:var to maintain such a state, while this state can easily be read from an FS variable ?""The point is, I want the event to be executed no matter its current state (its like an order:-)).For example, if I need the autopilot to turn OFF, why do I care to know its current AVar value, if I'm going to command it OFF anyway? Reading an AVar with its corresponding if{ requires extra program data; LVars have almost no cant limits, and are easier to monitor,IMHO. ""Because your method introduces a potential pittfall (which I stepped in myself a few times :-) ); and that is, that the Statevar may become out-of-sequence with the actual state."" The statevar is NOT a copy of the actual state Avar, but instead a logic value that indicates an action (event) has to be commanded; once done it is reset and the event will not execute again.So, no out-of-sequence problem is possible.""E.g.: at startup (from a saved flight) or when a user issues simular events as the gauge does, like via key/button commands.""I prefer to use "flags" inside commands whenever I need to control user action that may potentially interfer with my coded commands.On the other hand, it is mandatory to read the Avar state in those cases where _TOGGLE is the only event possible, for example when working with the A/C Lights.Tom

[rcbarend 37]

Hi Tom,NOW I see what you mean ... :-)I just was thinking of another function: not to set a function to a certain (internally defined state), but to keep it FORCED to that state.But yours works as well, combined with OnEvent for possible user interference.Just a shame that the OnEvent in FSX virtually has become extremely impractical to use. :-(Cheers, Rob