LSL 101/Compile Time Errors

← Creating a Script

↑̲  LSL 101  ̲↑

Logic →

---

LSL 101: The Wikibook

• A Gentle Introduction
• The Structure of a Script
  • Simple Script Skeleton
  • Comments, White-space and Formatting
• Events & Event Handlers
  • The touch start Event
• Variables
  • Strings and Simple Output
    • String Concatenation
  • Integers
  • Using Variables
    • Global vs Local Variables
    • Variable Initialization
• Functions
  • Functions That Return a Value

The End Game

• Creating a Script
• Compile Time Errors
• Logic
• Conclusion

Let's look more closely at what happens when you save a script. If all goes well, you will see the two lines

Compile successful!
Save complete

in the pane below your script. These messages correspond to the two major steps that happen each time you save.

The first step is called compilation. The compiler is a part of SL that reads your script and translates it into a form that can be executed by SL. (Specifically, it is executed by a sim's server.) In order for the compiler to do this translation, your script has to be perfect from a grammatical point of view. If it comes across an error, the compiler will stop and give you an error message. In some cases, you'll see immediately what your mistake is. But the error messages aren't nearly as specific as they might be, so sometimes you'll have to scratch your awhile before you figure out what is wrong. In order to give you a head start, we'll look at some examples here.

Let's start with the basic new script that SL creates.

default
{
     state_entry()
     {
          // Let the object's owner know the script is working
          llOwnerSay( "Congratulations! Your script has started to execute." );
     }
 
     touch_start( integer num_detected )
     {
          // Let the object's owner know the script is working
          llOwnerSay( "I've been touched!" );
     }
}

default
(
    state_entry()
...

Suppose that in typing this in, instead of the { on the beginning of the second line, we type a (. When we save the script, instead of getting "Compile successful!", we get the message

(1, 0) : ERROR : Syntax error

What the compiler is saying here is that there is a syntax error at line number 1, position 0. (Remember what we said about programmers counting from 0 instead of 1.) So it is telling you that the parenthesis isn't legal. Unfortunately, what it doesn't tell you is what should be there. In this case, the only legal continuation after default is a left curly brace, so it could have said that. But the LSL compiler is pretty dumb, and as a scripter, you have to patient with it.

...
{
     // ...
     llOwnerSay( "..." )
}
...

Let's take another example. Fix up the curly brace and then remove the semicolon at the end of line 5. Press the Save button again. This time, you'll get the message

(6, 5) : ERROR : Syntax error

This time, try double clicking on the error message. This will cause the cursor in the edit window to jump to line 6, column 5. This is generally more convenient than manually counting to where the error occurs.

You may be wondering why the compiler thinks the syntax error is on line 6, at the closing curly brace, when it is the semicolon at the end of line 5 that is missing. If so, you're thinking like a person instead of like a computer. What the compiler knows is that following the closing parenthesis on line 5 there should be a semicolon. But remember that white space is immaterial to the compiler. So after the closing parenthesis on line 5, it just keeps going on to line six, ignoring the indentation, until it gets to the curly brace. Since the curly brace isn't the semicolon it was looking for, it points to the curly brace as being where the error is. In general, if the compiler says there is a syntax error at some point, and it looks right to you, check to see whether the error is really a punctuation mark missing before the point at which the compiler noticed the error.

...
{
     // ...
     llOwnerSay( ..." )
}
...

Let's try another error. Leave the semicolon missing at the end of line 5, but also delete the double quote mark in front of Congratulations. Save again. This time, you'll see

(5, 36) : ERROR : Syntax error

The compiler thinks the error is at the exclamation point is. That's because, as we'll soon see, strings can be given names, so the compiler is thinking that the word Congratulations could be the name of a string. Not until it gets to the exclamation mark does it see something that it can't explain, so that's where it says the syntax error is.

A few other things are worth noticing with this example. Even though the semicolon is still missing at the end of line 5, the compiler doesn't say anything about it. In general, as soon as the compiler finds an error, it tells you about it and then gives up. Only after you figure out and fix the first error it finds will it find a second one. The first script you write from scratch will probably have lots of errors, so you'll go through this cycle many times before you see the "Compile successful!" display.

Also, before restoring the " at the beginning of the string, look at the colors the editor is using for the various parts of the script. If you've gotten used to associating green with strings, you might notice that the strings are now in black while things that aren't comments are green. If you see that, it's a sure sign that there is either a missing or an extra double quote mark in your script. You don't even need to use the compiler to find that error. Just start at the top of the script and look for the place where the color coding starts looking funny. Since you know that your intent is that the word Congratulations is the start of a string, noticing that it is black rather than green indicates that the opening " is missing.

...
{
     // ...
     llOwnrSay( "..." );
}
...

Not all errors are syntax errors. Fix up the double quote marks and then go to the first instance of llOwnerSay and remove a letter. You'll see that the coloring immediately changes from red to black. Built-in functions appear in red, so if you type in the name of a built-in function and it doesn't immediately turn red, you can know that you don't have the spelling right. But let's say we didn't notice that and pressed the Save button instead. This time, the error message will be

(5, 75) : ERROR : Name not defined within scope.

We haven't talked about scopes yet, so that part of the message will remain a mystery for now, but the "Name not defined" part should make sense -- the name preceding the point of the error is misspelled and the misspelled version isn't the name of anything. (It's harder to rationalize why the compiler chose to point to the closing parenthesis instead of the name itself, so we won't even try.)

There are a lot more possible error messages than what we have talked about so far. But hopefully, we've looked at enough examples that you'll be able to understand most of them when they pop up.

Go back to Creating a Script or proceed onward to Logic.