Boolen, Bitwise, & more...

I have the following code snip-it in my script...

if (day == "02" && hour == "07"
if (WedOneClicked == 0)
llSetAlpha(1.0, ALL_SIDES);

I have an llSay just before this code that shows me the value of day is "02", the value in hour is "07" and the value of WedOneClicked is 0. The first two fields are defined as strings, the last field is an integer.

Given the values that I am seeing in the llSay, why is the llSetAlpha not getting executed? I'm thinking it has to do with '&' vs '&&' or with not enough parenthesis, or parenthesis grouped differently but I've tried several combinations and still can't seem to get this to work. What am I doing wrong???

Thank you,
Bartiloux Desmoulins

This looks like it should work, since the 2nd if clause is considered a single command for the purposes of the first. But in such cases, just to be safe, I always surround the inner clause with braces, thusly:

if (day == "02" && hour == "07")
{
    if (WedOneClicked == 0)
        llSetAlpha(1.0, ALL_SIDES);
}

Only other thing that comes to mind, is it possible that your day and/or hour strings actually also contain spaces which don't clearly show up in your llSay debug test? i.e., it's actually
"02 " and not "02"? Try having your llSay test enclose the string being checked in single quotes to be sure, e.g. llSay( 0, "'" + day + "'" ); I tend to do this when debug testing strings or keys.

Also, just to avoid problems with extraneous characters entirely, if day and hour will always be numerical values, why not cast them to integer when testing, i.e. if ( (integer)day == 2 && (integer)hour == 7) . Incidentally, testing equality on integers is faster than on strings, though the typecasts might eat up those gains, or more.

I'd certainly be incline dto use more parenthesis and I'm not a fan of unblocked if's for anything other than a single line. That said I dont think precedence order will have an effect in this case.

    if( (day == "02") && (hour == "07") )
    {
        if (WedOneClicked == 0)
            llSetAlpha(1.0, ALL_SIDES);
    }

I never trust operator precedence in any language.

Always, always explicitly parenthesize precedence order. Beyond making it slightly more readable, it guarantees (outside of serious compiler bugs, anyway) precedence is executed the way you want, instead of depending on the compiler's built-in implicit "assumptions" being a) sensible, and b) correct.

Thank you to all that replied to this thread. As always, with the help of a wonderful group of Forum Scriptors, I got passed by problem. I opted, you could say, for the belt and suspenders approach in that not only did I change my string compares to integers but I also blocked out the IF statements with bracket... and not just the high-level IF but the one nested below it as well.

After making those changes it worked beautifully.

Thanks again!
Bartiloux