2 quick questions about variables

[pilakin]

what does @ in value="@var" mean?
what does ? in value="var?" mean?

[Fumblesneeze]

the ? basically checks whether the variable exists.

value="$var?" is true when $var has been set, and false when it hasn't.

[Mad_Joker]

? will check if the value exists

Say you have a pilot entity, and want to check if some variable that may be defined is of a certain value. You could do it like this:

Code: Select all

<do_if value="$pilot.$var?">
  <do_if value="$pilot.$var == 5">
    <!-- do some stuff -->
  </do_if>
</do_if>

@ will suppress any errors due to the expression it prefixes, and will return null. This allows some shortcuts in your code, so in the above you could do:

Code: Select all

<do_if value="@$pilot.$var == 5">
  <!-- do some stuff -->
</do_if>

which will resolve $pilot.$var to null if it doesn't exist, and then compare null with 5, which will return false.

Hope that helps.

[pilakin]

interesting, but whats the difference between <do_if value="var"> and <do_if value="var?"> then?

[andrewas]

The former will return true if var = true. The latter will return true if var exists, regardless of its value.

[pilakin]

ah, I get it now. var on its own is an expression. if it's defined and you don't compare it to anything it's a true expression. and var? is a function that checks if var exists.

[UniTrader]

nope, more like:

Code: Select all

<do_if value="$var">
 <!-- ERROR to debuglog/will not do -->
</do_if>
<do_if value="not $var">
 <!-- ERROR to debuglog/will do -->
</do_if>
<do_if value="@$var">
 <!-- will not do -->
</do_if>
<do_if value="not @$var">
 <!-- will do -->
</do_if>
<do_if value="$var?">
 <!-- Will not do -->
</do_if>
<do_if value="not $var?">
 <!-- Will do -->
</do_if>

<set_value name="$var" value="null"/>
<do_if value="$var">
 <!-- Will not do -->
</do_i>
<do_if value="not $var">
 <!-- Will do -->
</do_i>
<do_if value="@$var">
 <!-- will not do -->
</do_if>
<do_if value="not @$var">
 <!-- will do -->
</do_if>
<do_if value="$var?">
 <!-- Will do -->
</do_if>
<do_if value="not $var?">
 <!-- Will not do -->
</do_if>

<set_value name="$var" value="[TRUE]"/>
<do_if value="$var">
 <!-- Will do -->
</do_i>
<do_if value="not $var">
 <!-- Will not do -->
</do_i>
<do_if value="@$var">
 <!-- will do -->
</do_if>
<do_if value="not @$var">
 <!-- will not do -->
</do_if>
<do_if value="$var?">
 <!-- Will do -->
</do_if>
<do_if value="not $var?">
 <!-- Will not do -->
</do_if>

(sry, i am bad with words, i prefer example cases ^^)

[pilakin]

yeah I get that, but what I mean is: imagine you have an expression like "7 == 7" it compares if 7 equals 7 and returns true. but now if you use just "7" it's also a true expression, because a 7 is .. well ... a 7. it's a true statement. if you don't compare it to anything, logically it's gotta be true. however "null" is a false expression.

[UniTrader]

well, 0 is as far as i know false, too

[Mad_Joker]

Okay, this scripting language is a lot like JavaScript, so let's clear this up:

Only null and 0 (false is just the integer 0 as well) are falsy, everything else is truthy (even negative values afaik).

[bbeach]

@ will suppress any errors due to the expression it prefixes, and will return null. This allows some shortcuts in your code, so in the above you could do:

Code: Select all

<do_if value="@$pilot.$var == 5">
  <!-- do some stuff -->
</do_if>

IMHO, shortcuts make for long delays.

Code: Select all

<do_if value="$pilot? and $pilot.$var? and $pilot.$var == 5">
  <!-- "and" stops evaluating after the first false -->
  <!-- "or" stops evaluating after the first true -->
</do_if>

In the example above

If $pilot is null it won't move on and try to evaluate $pilot.$var and won't throw an error.
If $pilot.$var is null it won't move on and try to evaluate $pilot.$var == 5 and won't throw an error.

Suppressing warnings for use as a null check will make it much harder to debug because the script will just move along happily giving the illusion that you have a valid object when you don't.

[andrewas]

You say we aren't comparing it to anything, but the experssion:

$var

is equivalent to:

$var == true

The same can be done for any expression. The expression is always reduced to a true or false, and the conditional code is executed or not depending on it.

So, does "7" reduce to true? Logic doesn't mean anything here because this is a nonsense question, but the implementation has rules that will provide an answer. I believe that in this case, anything that isn't actually [TRUE] will evaluate to false.

[pilakin]

oh my god, i just tried it and 0 is really considered not a number but same as "null". now that also finally explains to me, why there's an issue with waresamount = 0 in the station mining script. first I thought, it might be a precaution against dividing by 0 .
wth really, they already have "null", why block the 0 like this ...

[UniTrader]

well, it depends on what you expect.. for example if you want to work with Local Vars of another Extension as Optional part of yours it is quite neat since you dont have to check if the var exists and then compare/evaluate it - you can do both in one step
but i agree that this should be used with caution if you dont want to waste a few hours bug-hunting.

[Mad_Joker]

...

IMHO, shortcuts make for long delays.

Code: Select all

<do_if value="$pilot? and $pilot.$var? and $pilot.$var == 5">
  <!-- "and" stops evaluating after the first false -->
  <!-- "or" stops evaluating after the first true -->
</do_if>

In the example above

If $pilot is null it won't move on and try to evaluate $pilot.$var and won't throw an error.
If $pilot.$var is null it won't move on and try to evaluate $pilot.$var == 5 and won't throw an error.

Suppressing warnings for use as a null check will make it much harder to debug because the script will just move along happily giving the illusion that you have a valid object when you don't.

Actually, I think you are wrong. I tried what you wrote when I started modding, and discovered, that in this scripting language boolean expressions are not short-circuited, i.e. in the expression you posted even if $pilot? fails, $pilot.$var? will be evaluated, and will throw an error. That's the reason the code I posted should be used.

Btw, using @ and ? in the same expression gave me strange results, but I never really validated them. It was like @$var? would always return true. I think this is because @ gets precedence, so @$var evaluates to null, and null? returns true.