Thursday, November 30, 2006

Scripting: the basics, part 1

LSL, the Linden Scripting Language, is very similar to many modern scripting languages, such as JavaScript or PHP (which themselves have a lot in common with the C programming language and its descendants).

But not a whole lot of people write scripts in Second Life, maybe because it's a bit scary with all those curly brackets and parentheses and semicolons. I thought I'd try my hand at being a teacher in SL, since I learned so much in classes my first couple of weeks there, and wanted to "give back" to the community, so I'll use this blog to start organizing my thoughts for what and how I'd like to teach!



For this first post, let's look at the default "New Script" which gets created when you click the New Script… button in the Content tab of the edit window. (If you've never tried this before, rez a prim and select the Edit button on the Focus/Move/Edit/Create/Land panel that pops up. If it's a short window, click on the More » button in the lower right-hand corner. Then click on the rightmost tab labeled Content, and press the New Script… button.)

When you create a new script, your prim will say something like "Object: Hello, Avatar!" (assuming you haven't renamed it from its default name of "Object"). Double-click on the script (named, aptly enough, "New Script"), and an edit window will pop up. The script will look something like this:

default
{
state_entry()
{
llSay(0, "Hello, Avatar!");
}

touch_start(integer total_number)
{
llSay(0, "Touched.");
}
}

The first line in the script is "default". This means that the following code pertains to the object's default state. (States are an easy way of making the object react different ways to the same stimuli. If you don't have need of different states, as this script doesn't, then everything happens in the default state.)

The second line is an opening curly bracket (or curly brace). Curly braces are used in LSL, as in several other languages, for grouping multiple statements together. All states and functions must enclose their contents in curly brackets, even if those contents are empty. (They'll be more useful later on, when we get into conditionals and flow control.)

The third line is "state_entry()" - this is a function called every time the script enters a state. If it's located in the default state, it gets called every time the script is saved or reset. The parentheses appear after every function definition, and enclose the parameters that are passed to the function. The state_entry() function has no parameters, so there's nothing between the parentheses.

The fourth line is another curly bracket, this time enclosing the contents of the state_entry() function. (You'll notice that things are indented, and each time there's a set of curly brackets, everything inside them gets indented another level; this isn't required, but it does make it a lot easier for a human to read if the contents of every nested container are indented by a tab's worth of spaces.)

The fifth line — the actual contents of the state_entry() function — is a call to a predefined LSL function, llSay(). (Many predefined LSL functions start with "ll", for Linden Lab.) This particular function call causes the object to say "Hello, Avatar!" on chat channel 0 (zero), the one players talk on and the only one they can "hear" without some sort of scripted listening device. The line ends with a semicolon (;), which is put at the end of every statement.

The sixth line is a closing curly bracket, and as we can see by the way it's indented, it lines up with the opening brace for the state_entry() function. If you find a script where things are not indented like this, you may have to count the opening and closing braces to find out where things begin and end!

After a blank line (again, not strictly necessary, but good for readability), we have a new function, touch_start(). This one is called whenever someone begins touching the object or prim containing the script, and takes one parameter, an integer (whole number, with no decimal point) which indicates the total number of agents (avatars, or players) who have started touching it since the last time it was called. This is usually just one, unless people touched it simultaneously or the sim is very lagged. This particular script doesn't do anything with that parameter, but we still need to include it.

Handy Tip: When you type a word that the script editor recognizes as a valid LSL keyword, it changes color. You can hover your mouse pointer over a colored word to see more information about it — for example, if you type the name of a function and hover the mouse pointer over it, it will pop up a little tooltip telling you what parameters it takes, and what kind of data they are.


Within the curly brackets for touch_start(), we have another llSay() function. In this particular script, when someone touches the prim or object containing the script, it will say "Touched."

After the closing curly bracket for the touch_start() function is the closing curly bracket for the default state... and that's the end of the script!

6 comments:

Anonymous said...

I ran into an interesting web-site today about LSL. This website included the information on the compiler code color scheme. That might be a useful addition to your handy tip.

The in-world compiler color-codes and assists in formatting, as well as pinpointing the location of most errors. The colors for the types are roughly as follows:

maroon: states and functions

black: required non-function text and parameters

light blue: events

blue: program flow (IF, FOR, WHILE, etc)

dark blue: constants

semi-light green: type declarations (integer, string, etc)

dark/pale green: strings

orange: comments

Anonymous said...

Yes, I'm spending a lot of time running around looking for information on LSL.

http://www.reed.edu/~tuckers/jokes/foot.html

Had the following comment about shooting yourself in the foot with LSL:

- You spend hours designing the gun, and even more hours figuring out the physics scripting for the bullet, only to have it completely miss your foot, hit everyone else in the area, crash the server, and have the admins ban you completely.

- You forget to use a negative coordinate for the physics vector script, and when aiming down at your foot, end up shooting yourself in the face instead.

- You script a gun and a bullet object, and to make sure you don't miss, you make the bullet twice the size of your foot. When you aim down and fire the gun, the bullet remains in place, and you and the gun end up way up in the clouds.

Anonymous said...

lol

Anonymous said...

scripting makes my brain hurt....

onelilfizzle said...

wow good job, it just makes everything else a little similar

Anonymous said...




nice code , i am also started second life pls help me for some building issue and other.....