simple IF...ELSE question

feel like a complete imbecile but i can't get my if...else to work

i have two buttons, one sends "true" the other sends "false" ... i want "true" to make the thing rotate, and "false" (or anything else) to make it stop...

while i have tested that the link_message is indeed receiving "true" or "false" from the touched prims, the IF statement always makes it true -- it NEVER gets to the second condition.

what am i missing?


default
{
state_entry()
{

}

link_message(integer sender_num, integer num, string str, key id)
{
if(num)
{
llTargetOmega(<0,0,1>, PI/32,1);
}
else
{
llTargetOmega(<0,0,1>, 0,1);
}
}
}

I'm going to check if this is a bug. In the meantime, you sure you didn't declare a global variable "num?"

Edit: This works -

default
{
    state_entry()
    {
        llMessageLinked(LINK_SET,0,"","");
    }

    link_message(integer sender, integer num, string str, key id)
    {
        if(num) llSay(0,"Yar");
        else llSay(0,"Not Yar");
    }
}

Perhaps the problem is at the sending end? My guess is you accidentally put a single equal where a double should be, or something like that. I do it all the time.

I see a slight problem here:

 if(num)
{
llTargetOmega(<0,0,1>, PI/32,1);
} 

It's not checking for a condition, it's only checking for a number.
This should work:

default
{
state_entry()
{

}

link_message(integer sender_num, integer num, string str, key id)
{
if(num == 1)
{
llTargetOmega(<0,0,1>, PI/32,1);
}
else
{
llTargetOmega(<0,0,1>, 0,1);
}
}
}

And when you send a linked message send a 1 or 0(in this case 0 could
be anything since you have an else statement instead of an else if.

EDIT: Also I do see what Jeffery was pointing at, but this method
would be a way to get around using true and false as your integer.

Ok, one little thing I saw Jeffery do, no begin and end brackets,
so we can also do this to get the desired effect

link_message(integer sender_num, integer num, string str, key id)
{
if(num)
llTargetOmega(<0,0,1>, PI/32,1);

else llTargetOmega(<0,0,1>, 0,1);

}

checking for a number is perfectly legal. It wil give valid results as long as num is 0, or >1. I'm not sure how lsl treats negative numbers in an if statment.

it all boils down to
if(0) or if(1) whish is the same as if(FALSE) and if(TRUE)

Personally, I'd suggest putting debugging whispers in there, ala

ink_message(integer sender_num, integer num, string str, key id)
{
 llWhisper(0,"num:" + (string)num);
 if(num)
  {
   llWhisper(0,"rotate");
   llTargetOmega(<0,0,1>, PI/32,1);
   }
 else
  {
   llWhisper(0,"stop rotate");
   llTargetOmega(<0,0,1>, 0,1);
  }
} 

in this way you'll see what's being fed, and what the if-else really did

hmm... yes that did it.

i thought that if(num) on its own would test if num = true... but clearly not. if(num==TRUE) works

i had actually had a whisper telling me what was fed -- and it was being fed a 1 and a 2... but if(num) was always returning TRUE even with the 2...


thank you all!

lol now that this is working... on to the next challenge... i'm noticing that when i stop the rotatation it resets back to the original position (in which case the merry go round "leaps" backwards)... i assume that because this is client side there is no way around it.

This would be correct. The object's actual rotation when using
llTargetOmega stays at 0, so there is no way to check what
the rotation of the object is at when you stop TargetOmega.

ahhh yes, 1 is TRUE and 2 is TRUE

any positive value is true (in many languages any non-zero value is true).
This leads to the mental oddities that |!0| is TRUE, while the VARIABLE TRUE=1;

llTargetOmega does all it's work client-side, and as such 2 people looking at it on different computers will see it at different locations/rotations. I haven't tried this, but slowing the rotation and gain down to somethin like 0.001 may achieve the desired effect of it 'stopping' w/o a jump

That would be nice to have. I just ran a quick test on this,
it snaped the object back to it's original state after I called
another llTargetOmega, but good thinking

Your best bet here is to use a combination llSetRot/llTargetOmega, or llRotLookAt loop. I prefer the latter because it's easier to pull off, but if you simply must save those 10 extra sim FPS, you should be able to "guess" where your object is roughly rotated from llTargetOmega, then rotate to that point with llSetRot.

Of course, rotation over time is a touch harder than it sounds in this case, since there are other factors to compensate for (like the client-side nature).

Any nonzero value is treated as true in a LSL conditional statement. The only value that evaluates to false is zero.
==Chris

Even if he did, the parameter num would shadow (replace) the global num for the duration of the link_message event.
==Chris