User:SuzannaLinn Resident/ScriptingClasses/Basics 1

Basics 1

Touch

-> Object 1 Touch (a red box) -> Script 1 Touch

Right-click your red box and edit it.

Go to the contents tab. There is a script there: "script 1 Touch".

Double-click the "script 1 Touch" to open it. We are going to look at it in detail.

Keep the script opened, and close the edit window.

There are several check boxes and buttons in the script windows. Let's look at them:

- Running. If it is checking the script is executing its code. Usually we will have it checked. Sometimes, if there is an error in the script, it gets unchecked automatically. If our script doesn't work at all, look at this box, perhaps the script is not running.

- Mono: it refers to the version of the scripting language. "Mono" is the modern version. It has more memory and it is faster. This option is kept for compatibility with the older scripts. We will always have "Mono" checked.

- Experiences: when it is checked, it means that we are using the script with an experience in the sim, if the sim has any experience configured. It allows more interactions with the avatars who have accepted the experience and with the environment. This is advanced scripting, for now we will leave it unchecked.

- "reset" button. This button stops the script, no matter what it is doing, and restarts it again. Touch the "reset" button to reset your script. It says "Hello, Avatar!".

- "save" button. To save the script. It will tell if our code is ok or tell us an error message.

Now we are going to look at the script.

It's the most basic script. It reacts to touches. Touch your red box and it says "Touched.".

In this script we want to know when somebody touches the box, and SL tells it to our script.

When there is a touch on the object, SL triggers an event in our script, and we can receive this event and do something, like saying "touched".

Think of an event as a heads-up that the script gets when something occurs to the object or around it, like when someone touches it.

These events are like signals that let us write code in our script to respond to different things, such as when users interact with the object, avatars move or chat, the environment changes, when timers reach a certain point, etc.... There are lots of events, around 40, and we'll be learning many of them in this course.

The name of the event that is triggered when our object is touched is "touch_start". We have it in our script in lines 7-10 (in the viewer with yellow background).

Events' names are always followed by parentheses, "(" and ")". They can be empty or have one or several values separated by commas.

These values are additional information that comes with the event. They are called "parameters".

touch_start has one parameter, called "total_number" and it is an integer number.

Each parameter has a "type", specifying the kind of information that the parameter can hold.

total_number is of type "integer", the type for whole numbers, positive or negative, without decimals.

The events, with their parameters in parentheses, are always followed by curly brackets, "{" and "}", containing our code to answer to the event.

Parentheses are used to know where our parameters start and end, and curly brackets are used to know where our code starts and ends.

In lines 2-5, state_entry is another event.

state_entry is triggered when the script starts (or after it is reset). Our script says "hello avatar" as we have seen after using the "reset" button.

Now let's look to the code inside the events, the lines with the messages that our red box is saying.

Both lines start with "llSay".

llSay is a function of the language.

Functions are predefined set of instructions that we can use in our code, they are built-in tools to perform specific tasks.

All the functions that the linden script language provides to us start with "ll" (2 letters "l" of linden).

The language has several hundreds of functions. We will be learning many of them along this course.

The function "llSay" is used to make the object say something in the public chat.

Functions, like events, are followed by their parameters between parentheses, or by empty parentheses if there are no parameters.

As we see in the script, llSay has two parameters, the first parameter is 0 in both cases, and the second parameter is the text to be said, enclosed in quotes, " and ".

The first parameter, the 0, is the channel. A "channel" is a way for different objects to communicate with each other, a line of communication agreed by both objects. We will use channels again in a while.

The channel 0 is a special channel that says the messages to the public chat.

It's a parameter of the type integer.

The second parameter is the text to be said.

We must write the text between quotes. This way we can use anyting in the message (like "()", "{}", names of events or functions...) and avoid confusions in the script.

This parameter is of another type, the type "string".

The type "string" can contain any kind of text, numbers, or symbols.

And at the end of each of both llSay() lines there is a semicolon, a ;.

The semicolon must be added at the end of each instruction of the block of code inside the curly brackets. It's used by the script to know when the instruction ends.

A new line is not enough, because we can write a long instruction in several lines. A instruction only ends at the semicolon.

And, summarizing, what are the differences between events and functions?

• events are called by something happening outside the script.
• functions are called by the script.

• events send parameters to the script.
• the script sends parameters to the function.

• we write code in the script to answer to the events.
• the function code is already written and it answers to the script.

• events' parameters are written with its type and name (like integer total_number). We need a type and a name for each parameter to use them in our script.
• functions' parameters are written with its value (like 0 or "message"). We send the values of the right types.

Events come to us. Functions go from us.

Let's look at the "default" keyword at the start.

"default" is the name of the section in the script where we place all the event, all enclosed between { and }.

When a script starts after a reset or after being modified, it look for this "default", and then for the event "state_entry" inside the default { }.

We must have a default { } in all our scripts.

It's possible to add other groups of events, with other names instead of default. They are called "states" and we will see them in future classes.

Now we can do some practices with our script.

For instance, edit the script and change the messages in the script to any other messages that you like.

Save the script using the "Save" button and touch the object.

We are getting plenty of messaging from all the red boxes. Let's do it a bit more quiet.

We will change the script to make that it says the message only to the owner of the object.

Instead of the function llSay( 0, "message" ) we will use the function llOwnerSay( "message" ).

llOwnerSay() sends the message to the object owner only. There is no way to send to a channel using this function, so it hasn't a parameter for the channel. llOwnerSay() has one parameter, the message,

Everything in the script (events, functions, parameters,...) is case sensitive. We must write it exactly with the right caps, otherwise we will get an error when saving. llOwnerSay() has the "O" and the "S" in caps.

Change llSay(0,... to llOwnerSay(... and save the script. If you get an error when saving that you can't solve, send the script to me.

Now you will see the messages from your red box only, because you are the owner of it.

You will also see the messages from your red box if someone else touches it, but the toucher will not see the messages. Try touching the cylinders of the students around you.

Touch with comments

-> Object 2 Touch with comments (a yellow tube) ->Script 2 Touch with comments

Now let's talk about a very important thing, commenting our scripts.

We will not only learn to script, but we will learn to script well, following good scripting practices.

And this includes adding comments to our scripts.

We can add a comment at the end of a line, or as a new line, always starting with a double slash, //.

The comments that you write in your script are firstly for yourself. To explain to yourself what the script does and how the script does it. They are meant to help you when you look to the script after some time to modify it, and also while you are writing a long script.

The comments will also help other scripters when you share your scripts.

The comments are not written for the teacher. But the teacher likes a lot to see your scripts and read your comments :)

You can write as many and as long comments as you want. They don't use script memory or any resources.

At the beginning, we will comment most of the lines. Later, we will not repeat the same comments to the same things that, by then, we will have scripted several times, and we will comment what is more important or new.

My suggestion is that later today or during this week, when you study the class notes that you will get at the end of the class, you add the comments to the script.

When you have the script commented, send it to me. It will help me a lot to follow your progress and to know what needs a better explanation.

In this script there is also another event, "on_rez".

"on_rez" is triggered when the object where the script is in is rezzed. Don't worry about the parameter start_param, is for more advanced uses and we will see it in the future.

llResetScript does, just that, resets the script. The same that the "Reset" button in the script window.

Everything is restarted and the event state_entry is called . Usually is good to do it to start clean in each rezzing. We will add this code in most of our scripts.

Listen

-> Object 3 Listen (a green cylinder) -> Script 3 Listen

Now our object is listening to what people tells, but in channel 3, not in public chat.

We could listen to the public chat, channel 0, but then it would be repeating everything that we say.

To write in a channel, type / and the number of the channel before your text, for instance: /3 I'm writing in channel three

When someones chats near our object, SL triggers the event "listen".

This event is a bit more complex than the event "touch", it has four parameters.

These are the parameters: listen( integer channel, string name, key id, string message )

• channel: the number of the channel in which the message has been said.
• name: the name of the avatar or the name of the object that has said the message.
• id: the UUID of the avatar or the object that has said the message.
• message: the message that has been said.

channel is of the type integer, name and message are of the type string. We already have seen and used these types before.

id is of the type "key". The type "key" is only for the UUIDs.

Keys has numbers, letters and "-"s, so we could use the type string for them. But in LSL script we will be using UUIDs (of people, objects, textures, etc) so often that there is a type for them alone.

The parameter "name", when the the message comes from an avatar, has the legacy name. Legacy names are the usernames in the format "firtname.lastname" or "name.resident".

In lines 9 to 12 we are saying to ourselves the values of the parameters.

llOwnerSay needs a string as parameter, but some of the parameters are not of string type.

We can change one type to another with the name of the new type between parentheses before the name of the parameter, for instance: (script)channel

In line 14 we say the name, the text "has said" and the message, all in one llSay. We can add together several strings with the + sign.

Now we have our event listen ready... but it's not enough for it to work.

The event listen differs from the events touch (and many other events). The problem is that there are more than 4 billions of possible channel numbers.

And the script can't be listening to all of them. So we need to tell to the script what channel or channels we want to listen to.

There is a LSL function to do it: llListen().

llListen() has the same 4 parameters that the event listen, in the same order. We must choose a channel, the first parameter, but we can leave the other 3 parameters empty, with "".

We can use these other 3 parameters, name, id or message, to listen only to a legacy name, or a UUID, or to a specific message.

This is a way to filter the messages to receive only the events with the messages that we are interested in.

If we want to use more than one channel, we will use a function llListen() for each channel.

We have the function llListen() in line 4. We are listening to the channel 3.

We use the function llListen in the event state_entry. This way we are listening since the script starts.

Listen and Touch

-> Object 4 Listen and Touch (a blue sphere) -> Script 4 Listen and Touch

Now we using both events, listen and touch_start, to say messages, but now saying the display name of the person.

We see another ll function: llGetDisplayName( id ).

But there is a difference between llGetDisplayName() and llSay() or llOwnerSay().

llSay() and llOwnerSay() do something: saying.

llGetDisplayName(), instead of doing something, returns us information.

In this case the display name of the avatar who has the UUID that we have given to the function as parameter.

The value returned is a string and we can add with "has said" and the message to say it.

In the event touch_start, to get the UUID of the toucher we use this function:

• llDetectedKey(0)

llDetectedKey() has one parameter, the number of the toucher, starting with 0.

llDetectedKey(0) returns us the UUID of the first toucher.

Answers to questions

When are scripts "out of range"?

• If we are editing a script and we take or delete the object where the script is in the title of the script shows the script name and (out of range). This script can't be saved, we will need to copy it and paste to the script in the object.

When are scripts saved with "running" unchecked?

• "running" gets unchecked, if we save a script with errors, and then we close the script without solving the errors. The script is saved, with the "running" unchecked.

If we get an object that has a script running without the "Mono" checked, should we check it?

• The old version, LSO, has some differences, and there are a few scripts that use these differences. So if you receive a script that works and has "Mono" not checked, dont touch it.

What are the LSL versions?

• There are two LSL versions: LSO (the old one) and Mono (the new one)

Could we have the event state_entry with a parameter?

• No, we can't change the parameters of the events. They are predefined and SL triggers the events with the predefined parameters.
• We can't change the quantity or the type of the parameters, we can only change its names, if we like, but usually we always use the same names. Using the same names make the code in the event easier to read, since we already know what are the names of the parameters.
• For instance, the event touch_start has one parameter, of type "integer", we can't change this. But we can use any name for the parameter, touch_start( integer suzanna ), is ok, but not recomended.

Events are the stimulus; functions are the response?

• Events are the stimulus, and functions are the tools we use to respond to those events.

Must we always have a state_entry event, because the script automatically looks for that?

• No, we can have scripts without state_entry. SL tirggers the event state_entry when a script starts, and if state_entry is not there, it does nothing.
• But we must have a "default { }" group of events, or state, with at least one event in it (any event, state_entry or another).

Can avatars chat only on positive channels?

• No, avatars can chat also on negative channels nowadays. This limitiation existed time ago. To chat in a negative channel type /- and the number of the (negative) channel.

How to listen to only one avatar?

• using the parameter id with the UUID of the avatar: llListen(0,"","0f16c0e1-384e-4b5f-b7ce-886dda3bce41","");
• or using the parameter name with the legacy name: llListen(0,"SuzannaLinn Resident","","");

If a script is listening and then saying, in the same channel, does that put the script in an endless loop of talking to itself and responding?

• No, because the objects can't listen to themselves.