Using true as a variable seems to do nothing

#1 Sounds like maybe something else was wrong, true and false work fine for me. You can verify it by going to the console and typing echo(true); and echo(false); ... you'll get 1 and 0 respectively.

T.

#2 Well thanks Tom for showing that it does work in TGB. Now I just got to figure out why it didn't work in my dynamic field case.

#3 Honestly, I've had a few issues with the values for true and false myself, and while I haven't nailed down a 100% duplication case, I'm pretty sure it has to do with the context sensitive way TorqueScript decides how to treat a particular variable.

In most cases, it will do as Tom says above, and treat true and false as 1 and 0 respectively, but occasionally, and I think that dynamic fields are one of the cases, it always treats the value as if it were a string, such as "true" and "false". In this situation, if you use the $= operator instead of the == operator, it will correctly evaluate logical conditions (which is most probably what you are trying to do).

In other words, if you are using:

if (%myObject.myField == true)
{
  doSomething();
}

try this instead:

if (%myObject.myField $= "true")
{
  doSomething();
}

I've found the above modification to normal use to work for me, and if/when I can pin down the root issue I'll run it by the Torque core tech team.

#4 Arguably, directly comparing something to true or false is somewhat pointless. If you are in a situation where you need to do that, then you are probably treating the field as a boolean and thus don't need the operator.

Of course, some people still prefer to do so. I never do it myself, which may go some way to explaining why I've never had a problem with true/false.

T.

Edit: To test this theory out, I did the following:

==>echo(true == true);
1
==>echo(1 == true);
1
==>echo(1 == false);
0
==>echo(false == false);
1
==>echo(false == 0);
1
==>echo(false == 1);
0
==>echo(true == 1);
1

Seems like it works as it should.

Edit 2: Just for the sake of completeness ...

==>$foo = true;
==>echo($foo == true);
1
==>echo($foo == false);
0
==>$foo = false;
==>echo($foo == true);
0
==>echo($foo == false);
1

Edit 3: Missed a case ...

==>$foo = true;
==>echo($foo $= "true");
0
==>echo($foo $= true);
1

In the latter case with the string comparison operator, it would appear that the interpreter is correctly converting true to 1 before evaluating it as a string.

If there is a case where true/false messes up, I'd be interested to discover what it is. It certainly seems to be working fine, though.

T.

#5 Interesting thread, thanks for the information.

I haven't ran into this myself, but if I do it's good to have a reference like this thread.

#6 @Tom: As I mentioned, I haven't been able to 100% track it down, but since you are having fun testing--

--try creating a basic static sprite (or even a sceneobject, rendering doesn't matter for our test) and give it a dynamic field (using the level editor ) called myVal, set to true
--give it a namespace, I'll use MyClass

function MyClass::testLogicals(%this)
{
  if (%this.myVal == true)
  {
    echo("Logical comparison: myVal is equal to true (1)");
  }
  else
  {
     echo("Logical Comparison: myVal is not equal to true (1)");
  }
  if (%this.myVal $= "true")
  {
    echo("String Comparison: myVal is $equal to \"true\" (string true)");
  }
  else
  {
    echo("String Comparison: myVal is not $equal to \"true\" (string true)");
  }
}

I'm pretty sure this is the context sensitive issue I'm having, as every time doing a $= instead of a == on a level builder assigned dynamic field is fixing my execution flow.

Edit/PS: I'm pretty sure this may even come down to a level builder created/assigned dynamic field issue, instead of TorqueScript in general. I've seen a couple of other minor issues with LB assigned field values that work in TorqueScript but not in the LB field--such as using a \n within a string for example. In that case, it does in fact assign, but won't display (which makes sense in the long run--it's a single line output window).

#7 Ahhhhhhh. I can't test it right now (my only non-clean copy of the LB is hacked to hell and back and is no longer usable as a T2D editor), but that is almost certainly a level builder thing.

Since it's been created in a text box, it will be a string. Thus, as far as Torque is concerned, it's been assigned the string "true" (or "false") and not the actual keyword. There is no way to safely get around that besides maybe a special case in the LB. If TS tried to convert the strings, you'd never be able to have a string "true" or "false" which would be a silly limitation. For example, echo("the answer is " @ (%foo ? "true" : "false")); would always echo 1 or 0 instead of the intended true/false.

Mystery solved, I think.

T.