Difference between revisions of "LSL 101/Simple Script Skeleton"
Prajna Vella (talk | contribs) |
m (<lsl> tag to <source>) |
||
(28 intermediate revisions by 5 users not shown) | |||
Line 1: | Line 1: | ||
{{LSL Wikibook Index}}Here is the simplest possible valid LSL script. It doesn't actually ask the computer to do anything but all scripts have, at minimum, this structure: | [[Category:LSL 101]] | ||
{{NavNextPrev|prev=The Structure of a Script|next=Comments, White-space and Formatting}} | |||
{{LSL Wikibook Index}} | |||
Here is an example of the simplest possible valid LSL script. It doesn't actually ask the computer to do anything but all scripts have, at minimum, this structure: | |||
< | <source lang="lsl2"> | ||
default { | default | ||
state_entry() { | { | ||
state_entry() | |||
{ // state_entry event handler goes here | |||
} | } | ||
} | } | ||
</ | </source> | ||
Looking at a script, the first thing you might notice is that the ratio of punctuation to words is quite high. This is a general characteristic of LSL. Along with parenthesis and curly braces, there will be lots of semicolons, quotation marks and square brackets, and it all has to be done just right. Fortunately, the rules for using punctuation are much simpler than for a natural language. So even though you are likely to struggle a lot with punctuation at the beginning, that phase won't last long. | |||
LSL | In addition to the punctuation, there are two "names" in this example, "default" and "state_entry". In LSL, the underscore is not a punctuation mark, but one of the characters that can be used in names. It's most often used to combine what might be multiple words in English into a single name, because LSL requires every name to be a single word. | ||
Based on this example script snippet, you might guess that there is a recurring pattern of the form | |||
<source lang="lsl2"> | |||
heading | |||
{ | |||
... | |||
} | |||
</source> | |||
in LSL, and you would be absolutely right. Each one of these is called a <b>block</b>, and a large part of an LSL script is made up of blocks within blocks (within blocks ...). Since getting the punctuation just right is mandatory, it is a good idea to vertically align opening and closing curly braces with their heading, and indent everything in between. | |||
This is all grammar; what about the <u>meaning</u> of the two blocks? | |||
The outermost block, with the heading <b>default</b> denotes something referred to as the <b>default state</b>. States are a unique aspect of LSL, and we'll cover them later. But it will be easier to understand just how they work when you know more about other aspects of LSL. So for now, you can regard the outer block to be just a grammatical structure that is required in all scripts. | |||
< | The inner block, headed by <b>state_entry()</b>, is an <b>event handler</b> block. Unlike states, understanding events and event handlers is crucial from the very start. In fact, if you happen to have had some prior experience with programming, it's <u>especially</u> important that you grok(understand) events, because unlike a traditional computer program, events occurring outside of your script determine when the various parts of your script get executed. | ||
</ | |||
The first | The state_entry event is a pretty simple one. It occurs when the script first starts running. Typically, this will be when you add a new script to a prim's inventory or save your changes after editing a script that is in a prim's inventory. When the sim server detects the state_entry event, it executes any commands (and only those commands) that occur between the { and } of the state_event handler block. | ||
'''Click on [[LSL_101/Comments, White-space and Formatting | Comments, White-space and Formatting]] to continue.''' |
Latest revision as of 12:45, 24 January 2015
← The Structure of a Script | ↑̲ LSL 101 ̲↑ | Comments, White-space and Formatting → |
Here is an example of the simplest possible valid LSL script. It doesn't actually ask the computer to do anything but all scripts have, at minimum, this structure:
default
{
state_entry()
{ // state_entry event handler goes here
}
}
Looking at a script, the first thing you might notice is that the ratio of punctuation to words is quite high. This is a general characteristic of LSL. Along with parenthesis and curly braces, there will be lots of semicolons, quotation marks and square brackets, and it all has to be done just right. Fortunately, the rules for using punctuation are much simpler than for a natural language. So even though you are likely to struggle a lot with punctuation at the beginning, that phase won't last long.
In addition to the punctuation, there are two "names" in this example, "default" and "state_entry". In LSL, the underscore is not a punctuation mark, but one of the characters that can be used in names. It's most often used to combine what might be multiple words in English into a single name, because LSL requires every name to be a single word.
Based on this example script snippet, you might guess that there is a recurring pattern of the form
heading
{
...
}
in LSL, and you would be absolutely right. Each one of these is called a block, and a large part of an LSL script is made up of blocks within blocks (within blocks ...). Since getting the punctuation just right is mandatory, it is a good idea to vertically align opening and closing curly braces with their heading, and indent everything in between.
This is all grammar; what about the meaning of the two blocks?
The outermost block, with the heading default denotes something referred to as the default state. States are a unique aspect of LSL, and we'll cover them later. But it will be easier to understand just how they work when you know more about other aspects of LSL. So for now, you can regard the outer block to be just a grammatical structure that is required in all scripts.
The inner block, headed by state_entry(), is an event handler block. Unlike states, understanding events and event handlers is crucial from the very start. In fact, if you happen to have had some prior experience with programming, it's especially important that you grok(understand) events, because unlike a traditional computer program, events occurring outside of your script determine when the various parts of your script get executed.
The state_entry event is a pretty simple one. It occurs when the script first starts running. Typically, this will be when you add a new script to a prim's inventory or save your changes after editing a script that is in a prim's inventory. When the sim server detects the state_entry event, it executes any commands (and only those commands) that occur between the { and } of the state_event handler block.
Click on Comments, White-space and Formatting to continue.