Difference between revisions of "LSL 101/Creating a Script"
m (header fix) |
m (<lsl> tag to <source>) |
||
(2 intermediate revisions by one other user not shown) | |||
Line 1: | Line 1: | ||
[[Category:LSL 101]] | [[Category:LSL 101]] | ||
{{NavNextPrev|prev=Functions That Return a Value | {{NavNextPrev|prev=Functions That Return a Value|next=Compile Time Errors}} | ||
{{LSL Wikibook Index}} | {{LSL Wikibook Index}} | ||
We've covered enough of the LSL basics that it makes sense to go ahead and actually create and test a script in SL. If you're not there already, log in, go to some place you have permission to build, and create a cube. Go into Edit mode and rename the object to something like ''First LSL 101 Test'', or whatever other naming convention you generally use. | We've covered enough of the LSL basics that it makes sense to go ahead and actually create and test a script in SL. If you're not there already, log in, go to some place you have permission to build, and create a cube. Go into Edit mode and rename the object to something like ''First LSL 101 Test'', or whatever other naming convention you generally use. | ||
Now left click on the Content Tab, and then on the New Script button | Now left click on the Content Tab, and then on the New Script button in the Content tab. Two things should happen. The line ''New Script'' should appear in the Contents list, and your cube should chat the phrase ''Hello, Avatar!''. | ||
Before we look at the new script, lets rename "New Script" to something more meaningful, like ''First LSL 101 Test v0''. The ''v0'' at the end is short for ''version 0''. If you've ever built anything in that took more than an hour or so, you've probably learned the wisdom of making periodic backups of your work. <small>With scripting, it is even more important to regularly make a copy of your work '''and''' number each copy sequentially. Compared to the backups you make while building objects, you'll probably have more script backups, you'll be going back to older versions of a script more often, and it is generally much harder to distinguish between two scripts that have the same name than two objects that have the same. You can get away without assigning scripts version numbers for very small scripts, but you might as well get in the habit of doing it from the start. | |||
If it seems strange to start at version 0 instead of version 1, be warned that programmers, unlike normal people, generally start counting at 0. We'll be seeing a lot of built-in functions that ''require'' you to start counting at 0. So it's another thing to do from the start.</small> | |||
Let's take a look at the script we're created. Double click on the script's name in the Contents list, and a new window should open. This is the window you will use to edit scripts in SL. You'll see that the window already contains a script, which in fact looks a lot like our most recent example. Whenever you create a new script, SL will give you this standard starting point. If you would prefer to start with a completely empty script, you can use the Edit/Select All menu command and delete it. | Let's take a look at the script we're created. Double click on the script's name in the Contents list, and a new window should open. This is the window you will use to edit scripts in SL. You'll see that the window already contains a script, which in fact looks a lot like our most recent example. Whenever you create a new script, SL will give you this standard starting point. If you would prefer to start with a completely empty script, you can use the Edit/Select All menu command and delete it. | ||
Line 13: | Line 15: | ||
Let's look at the differences between the script SL creates and our example. In case you are reading this without the SL script window open, here's the two together. | Let's look at the differences between the script SL creates and our example. In case you are reading this without the SL script window open, here's the two together. | ||
New SL | New SL scripts look like this: | ||
< | <source lang="lsl2"> | ||
default | default | ||
{ | { | ||
Line 27: | Line 29: | ||
} | } | ||
} | } | ||
</ | </source> | ||
But our example script looks like this: | |||
< | <source lang="lsl2"> | ||
default | default | ||
{ | { | ||
state_entry() | state_entry() | ||
{ | { | ||
llOwnerSay( "Congratulations! Your script has started to execute." ); | llOwnerSay( "Congratulations! Your script has started to execute." ); | ||
// this tells the owner the script is in *state_entry* | |||
} | } | ||
touch_start( integer num_detected ) | touch_start( integer num_detected ) | ||
{ | { | ||
llOwnerSay( "I've been touched!" ); | llOwnerSay( "I've been touched!" ); | ||
// this tells the owner the script has been touched | |||
} | } | ||
} | } | ||
</ | </source> | ||
If you are looking at the SL script editing window, you may notice that the colors used for words in the SL window don't always match those used here in the Wiki. This is not a significant difference. The colors are determined by the software that displays the script, i.e. the LSL editor in SL and the WikiMedia software here on the Wiki. The intent of the coloring is to make it easier to spot errors in your program my special categories of words different colors. | |||
If you are looking at the SL script editing window, you may notice that the colors used for words in the SL window don't always match those used here in the Wiki. This is not a significant difference. The colors are determined by the software that displays the script, i.e. the LSL editor in SL and the WikiMedia software here on the Wiki. The intent of the coloring is to make it easier to spot errors in your program my special categories of words different colors. | |||
In both SL and the Wiki, strings are always displayed in green. If you notice that some of your script that ''isn't'' meant to be part of a string is green, find the start of the string by seeing where the string starts and add the closing " mark where the string is supposed to stop. Everything after that should return to its normal color. This can be quite helpful for those of us who aren't 100% accurate typing. But it's just an aid to human reading. The colors don't have any affect on the meaning of script. | |||
Similarly, the comments in our examples (or lack thereof) don't have any affect on how the script is executed. But there is a meaningful difference between the two built-in functions '''llOwnerSay''' and '''llSay'''. You'll notice that '''llSay''' requires two parameters instead of just one. The second parameter for '''llSay''' plays the same role as the lone parameter in '''llOwnerSay''' -- it is the text to be "said". The additional parameter allows us to designate a '''chat channel'''. Chat channels are integers (e.g. 0, 1, 10, 4779738, -254, ...) that function somewhat like radio channels. Channel 0 is the "public" channel. Any avatar who is within 20 meters can hear '''llSay''', within 5 meters '''llWhisper''' and within 100 meters for '''llShout'''. | |||
'''To continue this tutorial, proceed onward to [[LSL 101/Compile Time Errors | Compile Time Errors]], or go back to [[LSL 101/Functions That Return a Value|Functions That Return a Value]].''' |
Latest revision as of 12:40, 24 January 2015
← Functions That Return a Value | ↑̲ LSL 101 ̲↑ | Compile Time Errors → |
We've covered enough of the LSL basics that it makes sense to go ahead and actually create and test a script in SL. If you're not there already, log in, go to some place you have permission to build, and create a cube. Go into Edit mode and rename the object to something like First LSL 101 Test, or whatever other naming convention you generally use.
Now left click on the Content Tab, and then on the New Script button in the Content tab. Two things should happen. The line New Script should appear in the Contents list, and your cube should chat the phrase Hello, Avatar!.
Before we look at the new script, lets rename "New Script" to something more meaningful, like First LSL 101 Test v0. The v0 at the end is short for version 0. If you've ever built anything in that took more than an hour or so, you've probably learned the wisdom of making periodic backups of your work. With scripting, it is even more important to regularly make a copy of your work and number each copy sequentially. Compared to the backups you make while building objects, you'll probably have more script backups, you'll be going back to older versions of a script more often, and it is generally much harder to distinguish between two scripts that have the same name than two objects that have the same. You can get away without assigning scripts version numbers for very small scripts, but you might as well get in the habit of doing it from the start.
If it seems strange to start at version 0 instead of version 1, be warned that programmers, unlike normal people, generally start counting at 0. We'll be seeing a lot of built-in functions that require you to start counting at 0. So it's another thing to do from the start.
Let's take a look at the script we're created. Double click on the script's name in the Contents list, and a new window should open. This is the window you will use to edit scripts in SL. You'll see that the window already contains a script, which in fact looks a lot like our most recent example. Whenever you create a new script, SL will give you this standard starting point. If you would prefer to start with a completely empty script, you can use the Edit/Select All menu command and delete it.
Let's look at the differences between the script SL creates and our example. In case you are reading this without the SL script window open, here's the two together.
New SL scripts look like this:
default
{
state_entry()
{
llSay(0, "Hello, Avatar!");
}
touch_start(integer total_number)
{
llSay(0, "Touched.");
}
}
But our example script looks like this:
default
{
state_entry()
{
llOwnerSay( "Congratulations! Your script has started to execute." );
// this tells the owner the script is in *state_entry*
}
touch_start( integer num_detected )
{
llOwnerSay( "I've been touched!" );
// this tells the owner the script has been touched
}
}
If you are looking at the SL script editing window, you may notice that the colors used for words in the SL window don't always match those used here in the Wiki. This is not a significant difference. The colors are determined by the software that displays the script, i.e. the LSL editor in SL and the WikiMedia software here on the Wiki. The intent of the coloring is to make it easier to spot errors in your program my special categories of words different colors.
In both SL and the Wiki, strings are always displayed in green. If you notice that some of your script that isn't meant to be part of a string is green, find the start of the string by seeing where the string starts and add the closing " mark where the string is supposed to stop. Everything after that should return to its normal color. This can be quite helpful for those of us who aren't 100% accurate typing. But it's just an aid to human reading. The colors don't have any affect on the meaning of script.
Similarly, the comments in our examples (or lack thereof) don't have any affect on how the script is executed. But there is a meaningful difference between the two built-in functions llOwnerSay and llSay. You'll notice that llSay requires two parameters instead of just one. The second parameter for llSay plays the same role as the lone parameter in llOwnerSay -- it is the text to be "said". The additional parameter allows us to designate a chat channel. Chat channels are integers (e.g. 0, 1, 10, 4779738, -254, ...) that function somewhat like radio channels. Channel 0 is the "public" channel. Any avatar who is within 20 meters can hear llSay, within 5 meters llWhisper and within 100 meters for llShout.
To continue this tutorial, proceed onward to Compile Time Errors, or go back to Functions That Return a Value.