FSXA Landing variable

[Ar Alm]

Hey guys,

I'm trying to learn how to create gauges and panels, because there's this panel I want to create as a freeware.

I went through microsoft's FSX variables page
(https://msdn.microsoft.com/en-us/library/cc526981.aspx) to look if there's a variable that indicates if a plane's wheels are on the ground or not.

The closest variable which I thought would do that was "SIM ON GROUND". The description was "On ground flag".

So, does this do what I think it does? Does it indicate if the wheels are on the ground? If not, what does "On ground flag" mean?

Thanks

 

[WarpD]

Yes.

 

[n4gix]

When (A:SIM ON GROUND,bool) is "not zero" (i.e. is TRUE) the wheels are on the ground.

Now you might be wondering why I specified "not zero" as the TRUE condition. That is because an undocumented factoid is that "the only guaranteed value for a Boolean variable is zero." Some A:vars actually return -1 instead of the expected +1. As it happens, the (A:SIM ON GROUND,bool) variable is one that does return +1 when TRUE, but I still don't rely on that.

To save you from becoming frustrated in the future, always test for either "zero" or "not zero"...

(A:SIM ON GROUND,bool) 0 == if{ airborne } els{ on ground }
is the same as
(A:SIM ON GROUND,bool) ! if{ airborne } els{ on ground }
is the same as
(A:SIM ON GROUND,bool) 1 ==  if{ on ground } els{ airborne }

The first two versions will always work with any Boolean variable; the third version is not so reliable!

 

[Roy Holmes]

Bill,
I get versions 1 and 3, but not 2. Could you explain that one to this old geezer?

Explained in post 15 below, thanks
Roy

 

[Ar Alm]

When (A:SIM ON GROUND,bool) is "not zero" (i.e. is TRUE) the wheels are on the ground.

Now you might be wondering why I specified "not zero" as the TRUE condition. That is because an undocumented factoid is that "the only guaranteed value for a Boolean variable is zero." Some A:vars actually return -1 instead of the expected +1. As it happens, the (A:SIM ON GROUND,bool) variable is one that does return +1 when TRUE, but I still don't rely on that.

To save you from becoming frustrated in the future, always test for either "zero" or "not zero"...

(A:SIM ON GROUND,bool) 0 == if{ airborne } els{ on ground }
is the same as
(A:SIM ON GROUND,bool) ! if{ on ground } els{ airborne }
is the same as
(A:SIM ON GROUND,bool) 1 ==  if{ on ground } els{ airborne }

The first two versions will always work with any Boolean variable; the third version is not so reliable!

Thanks. That was really helpful. But I have the same question as Roy. Does "!" mean "not zero"?

 

[WarpD]

Technically it represents being not true... because that's how the logic flows... but yes, it means it's not zero because a boolean value is simply a numerical variable of either zero or not zero.

 

[taguilo]

Thanks. That was really helpful. But I have the same question as Roy. Does "!" mean "not zero"?

Not quite.

The ! (negation) sign acts like a toggle operator. It works by extracting the last value on the stack and converting it:

- to 0 when it is >= 1 or <= -1 (equivalent to logical FALSE, or "zero" )
- to 1 when is > -1 and < 1 (equivalent to logical TRUE, or "not zero" )

Tom

 

[Ar Alm]

Thanks guys. This has been really helpful

 

[Roy Holmes]

It took another very careful read of Bill's post, but I finally got it.

I think my problem is that the more common use of ! is as a toggle, for example (L: init,bool) ! (>L:init,bool).
In that context, surely, if (A:SIM ON GROUND,bool) was zero the negation would yield a positive result which would incorrectly say you were on the ground.

But the first check for 0 == would show that result to be wrong and you have to do the first check if you want to rely on the second.

It is still hurting my brain.

- to 0 when it is >= 1 or <= -1 (equivalent to logical FALSE, or "zero" )

I can read that two ways depending of what the "is" means. I assume it means the value before conversion, what it was, not what it is afterwards.
The other way is that >= 1 or <= -1 is equivalent to logical FALSE, or "zero" which does not seem correct.

Roy

 

[taguilo]

Roy,

Actually a bool value should not be tested against any other true/false value ( for example (A:SIM ON GROUND,bool) 0 == ) because of being a redundancy and perhaps leading to wrong results, as pointed out by Bill.

Then,

(A:SIM ON GROUND,bool) if{ do something } els{ do another } = if bool value is true (any number different than 0 *) then if{} is processed; if bool value is false (0) then els{} is processed.

(A:SIM ON GROUND,bool) ! if{ do something } els{ do another } = if bool value is false (0), ! toggles it to true (1 in this case) then if{} is processed; if bool value is true (any number different than 0 *) ! toggles it to false (0) then els{} is processed.

I can read that two ways depending of what the "is" means. I assume it means the value before conversion, what it was, not what it is afterwards.

You must read it straight out: The last value is extracted and,

- when it is >= 1 or <= -1, converted to 0
- when it is > -1 and < 1, converted to 1

Some examples:


345.23 ! = 0
0.235 ! = 1
-0.777 ! = 1
-467 ! = 0
0 ! = 1
1 ! = 0
-1 ! = 0

Tom

EDIT : * actually meaning any number >= 1 or <= -1

 

[Roy Holmes]

(A:SIM ON GROUND,bool) if{ do something } els{ do another } = if bool value is true (any number different than 0 *) then if{} is processed; if bool value is false (0) then els{} is processed.

In our case do something means you are on the ground.

(A:SIM ON GROUND,bool) ! if{ do something } els{ do another } = if bool value is false (0), ! toggles it to true (1 in this case) then if{} is processed; if bool value is true (any number different than 0 *) ! toggles it to false (0) then els{} is processed.

So if we were in the air the zero false (0) would be toggled and the resultant if{ do something } would mean we were on the ground.

And how does this work, if zero has been toggled to give a true result

(A:SIM ON GROUND,bool) ! if{ on ground } els{ airborne }

Brain still hurts, sorry
Roy

 

[JB3DG]

In the second quote the ! means do something = airborne so your 3rd quote should actually have the airborne and on ground swapped around.

 

[taguilo]

Roy,

In the second quote the ! means do something = airborne so your 3rd quote should actually have the airborne and on ground swapped around.

Correct. In that specific example from Bill results should be inverted = (A:SIM ON GROUND,bool) ! if{ airborne } els{ on ground }.

Tom

 

[Roy Holmes]

That is what bothered me, my brain thanks you
Roy

 

[n4gix]

Argh! I even managed to confuse myself. I had it right, then had second thoughts and swapped 'em around. I should have left well enough alone...

In the interest for possibly preventing future "brain hurt" I've now re-corrected my faux pas!

 

[WarpD]

The only way to represent any of this is that false is indicated by a value of zero and only zero. Any other value indicates true. No exceptions (unless there's a bug in the code interpreter).

 

[taguilo]

The only way to represent any of this is that false is indicated by a value of zero and only zero. Any other value indicates true. No exceptions (unless there's a bug in the code interpreter).

That is correct.
However, the source value to which the ! evaluator applies does not need to be zero, because it is previously casted to int by the interpreter.

Then, in this expression : 0.455 ! if{ do1 } els{ do2 }, 0.455 ! becomes 0 ! and the part in bold is executed.

And the same behavior is found in if{}/els{} evaluators:

0.455 if{ do1} els{ do2 }
-0.232 if{ do1} els{ do2 }
23.455 if{ do1} els{ do2 }
-11.45 if{ do1} els{ do2 }

In all cases the script in bold is executed.

Tom

 

[WarpD]

Then that is a flaw in the interpreter as it violates the rule of 0 == false and any other value == true.

And let's be clear... we're discussing evaluating a boolean value... not a numeric value. Logically speaking, it is definitely different.

 

[taguilo]

Then that is a flaw in the interpreter as it violates the rule of 0 == false and any other value == true.

No flaw at all. As I previously stated, the interpreter converts the source value to int before applying that rule.

And let's be clear... we're discussing evaluating a boolean value... not a numeric value. Logically speaking, it is definitely different.

There are no booleans in XML scripts. All of FS variables (Avars, LVars,CVars,GVars) are of type double (FLOAT64 macro), and bool unit is simply a pnemonic descriptor for number unit.
In case of LVars, for example, it is possible to assign any value to (L:Var,bool) without being internally changed (although it doesn't make sense to use bool unit for that!).

Tom

 

[WarpD]

You do realize you're writing contradiction after contradiction... if the variable is a double, and you're requesting it as a boolean and it's being converted to an integer... the process is horribly broken. 0.477 is not equal to zero and should not have been rounded down to zero. While in your opinion that may not be broken... it is. It actually violates the core definition of true versus false by changing the value before evaluation. That's bad interpretation.

Just to be stupendously clear... there's no boolean in any software language. Just a numeric value, the format of which may vary based on definition. Even at the most basic level (machine language) there's only a difference between a value being zero or not zero. It cares not regarding the position of the decimal.