Jump to content
You are about to reply to a thread that has been inactive for 1590 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Posted

I can use if statements but for some reason i cant use else if or else statements at all in my scripts. I've tried so many different ways to solve this. here is my sample code.

 if (message == "Add 1 to green" && count == 0)
            green_count += 1;
            count += 1;
            llSetText("Green: " +(string)green_count,<1.0,1.0,1.0>,1.0);
 else
            count -= 1;

 

I'm constantly getting an error on the else command line.

Posted (edited)

Unless your if() is to control only one statement, you just encapsulate the entirety of the conditional code in braces { }. I always use braces, even for single statement conditionals. You are getting the error message because your if() is terminated by the single command it controls "green_count += 1;". The next two lines are always executed and the "else" is unexpected and flagged as an error.

Try this...

if (message == "Add 1 to green" && count == 0) {
            green_count += 1;
            count += 1;
            llSetText("Green: " +(string)green_count,<1.0,1.0,1.0>,1.0);
}

else {
            count -= 1;
}

Edited by Madelaine McMasters
  • Like 3
Posted

The easy solution is to take Maddy's advice and always use curly brackets to mark the start and end of a conditional scope, even if they are not strictly required.  It's a great habit to be in.  It keeps you from forgetting those brackets when they truly are required.

  • Like 3
  • Lindens
Posted

White space and indentation is not meaningful in LSL beyond making your code easier to read. 

Code blocks in LSL are delineated by curly braces 

if (test)
{ 
    statement;
}

and 

if (test) 
{ statement; }

for instance are identical to the compiler.  

(Python will 💔 every time . )

  • Like 2
Posted (edited)
9 hours ago, Rider Linden said:

Code blocks in LSL are delineated by curly braces 

Don't forget, you can do:

if (test) { statement; statement; statement; }

...if you're chaotic evil.

@Mollymews That's a syntax error.

Edited by Wulfie Reanimator
  • Like 3
Posted (edited)
19 hours ago, Wulfie Reanimator said:

@Mollymews That's a syntax error.

is LSL legal as it conforms to the syntax of the language. It will compile and execute. Test example:

default
{
    state_entry()
    {
        integer test;
        if(test);else if(test);else if(test);else llSay(0, "i failed the test 3 times");
    }
}

 

edit add: best that I add a comment  just in case

am not suggesting that we should ever actually include code like this in our scripts to this 3rd degree on the same test. Is just a fun example of diabolical.

Edited by Mollymews
  • Confused 1
Posted
12 hours ago, Mollymews said:

is LSL legal as it conforms to the syntax of the language. It will compile and execute. Test example:


default
{
    state_entry()
    {
        integer test;
        if(test);else if(test);else if(test);else llSay(0, "i failed the test 3 times");
    }
}

 

edit add: best that I add a comment  just in case

am not suggesting that we should ever actually include code like this in our scripts to this 3rd degree on the same test. Is just a fun example of diabolical.

Ah, yeah, even I got tricked by the syntax. See, I thought it would have a syntax error because of a dangling-else.

Properly expanded, that code becomes:

default
{
    state_entry()
    {
        integer test;

        if (test)
        {
            ;
        }
        else if (test)
        {
            ;
        }
        else if (test)
        {
            ;
        }
        else
        {
            llSay(0, "i failed the test 3 times");
        }
    }
}

As in, the if/else-if "blocks" only contain an empty statement that does nothing.

What I expected at first glance was basically this:

if (test) {};
else if (test) {};
else if (test) {};
else
{
    llSay(0, "i failed the test 3 times");
}

As in, the conditions would have empty blocks, then followed by an end-of-statement. This would cause a syntax error, but it's not what happens.

  • Like 1
Posted
13 hours ago, Mollymews said:

is LSL legal as it conforms to the syntax of the language. It will compile and execute. Test example:


default
{
    state_entry()
    {
        integer test;
        if(test);else if(test);else if(test);else llSay(0, "i failed the test 3 times");
    }
}

 

edit add: best that I add a comment  just in case

am not suggesting that we should ever actually include code like this in our scripts to this 3rd degree on the same test. Is just a fun example of diabolical.

My fav ones are when someone hands me a script they need help with and it’s like

default{state_entry(){llSomething();llSomething();llSomething();llSomething();}touch_start(integer x)llSomething();llSomething();llSomething();

but on a large scale. A friend of mine was the most recent one and claimed “i can keep track of scripts better like this”

  • Like 1
Posted
4 hours ago, Wulfie Reanimator said:

 


if (test) {};
else if (test) {};
else if (test) {};
else
{
    llSay(0, "i failed the test 3 times");
}

As in, the conditions would have empty blocks, then followed by an end-of-statement. This would cause a syntax error, but it's not what happens.

yes you are right and have explained the trap issue of this coding style quite well

it helps to highlight why people like Rolig, Maddy and others who have been up and down the mountains remind us from time to time to use curly braces even when there is only one statement following a conditional. When we don't then it can sometimes lead us to fall off cliffs. Our code doesn't do what we think/assume it does even tho it compiles and executes without throwing an error

Posted (edited)
4 hours ago, ItHadToComeToThis said:

My fav ones are when someone hands me a script they need help with and it’s like

default{state_entry(){llSomething();llSomething();llSomething();llSomething();}touch_start(integer x)llSomething();llSomething();llSomething();

but on a large scale. A friend of mine was the most recent one and claimed “i can keep track of scripts better like this”

i am not this bad but I do have a tendency to put multiple statements on the same line. Particularly when resetting variables to default starting values. Like

a = 0; b = -1; c = ""; d = E;   // where E is some global variable

i do this as a convenience to myself, not because i think is "better". I do it so i have more viewable space in the code editor window for the following code that operates on the variables

which raises the whole topic of what is "better" or "best" coding style wise.  For me "best" means that the person who follows me into the chair that I have vacated can read what I written without spending a day or three trying to work out my typing peccadilloes. 

"Best" to me also means following the coding style of the language tool provider.  Microsoft code editor do it the Microsoft way, Java do it the Eclipse way, LSL do it the Linden way, etc

edit add: by following the provider coding style then it helps me when I change between languages. Like in VB I am typing and thinking in BASIC.  In Delphi I am typing and thinking in Pascal.  In GCC then thinking in C++.  In SL thinking in LSL, and so on

Edited by Mollymews
Posted
1 hour ago, Mollymews said:

i am not this bad but I do have a tendency to put multiple statements on the same line. Particularly when resetting variables to default starting values. Like

a = 0; b = -1; c = ""; d = E;   // where E is some global variable

i do this as a convenience to myself, not because i think is "better". I do it so i have more viewable space in the code editor window for the following code that operates on the variables

which raises the whole topic of what is "better" or "best" coding style wise.  For me "best" means that the person who follows me into the chair that I have vacated can read what I written without spending a day or three trying to work out my typing peccadilloes. 

"Best" to me also means following the coding style of the language tool provider.  Microsoft code editor do it the Microsoft way, Java do it the Eclipse way, LSL do it the Linden way, etc

edit add: by following the provider coding style then it helps me when I change between languages. Like in VB I am typing and thinking in BASIC.  In Delphi I am typing and thinking in Pascal.  In GCC then thinking in C++.  In SL thinking in LSL, and so on

I usually do that if I have to set multiple bools at the beginning of a block. Or do it the cheating way if it’s the same value

a = b = c = FALSE

Also if I am clearing multiple lists

a = b = c = []
 

I don’t switch so easily with syntax though. I am notorious for dropping the wrong syntax into other code. For example, if I am doing some work in Swift I keep adding parentheses to if statements when I don’t need them or semi colons to functions. Granted swift accepts this way of doing things but it isn’t needed. In the case of if statements it’s necessary if you want to group such as (a + b) == c but otherwise it’s
if a == b {

Posted
4 hours ago, ItHadToComeToThis said:

a = b = c = FALSE

Also if I am clearing multiple lists

a = b = c = []
 

I don’t switch so easily with syntax though

yes a = b = c = FALSE is in many professional coding shops the expected way to do this.  Were we to write a = FALSE; b = FALSE; c = FALSE; in these shops then we probably get sent off to make the tea

tbh I tangle up myself sometimes. Usually when I don't take a break between changing from one environment to another. Without a break my muscle memory can still be a bit stuck in the past

 

You are about to reply to a thread that has been inactive for 1590 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...