<
Previous Chapter: Hello, Avatar!>
<
Table of Contents>
<
Next Chapter: Syntax Revisited>
States And Events
Whoever desires to found a state and give it laws, must start with assuming that all men are bad and ever ready to display their vicious nature, whenever they may find occasion for it.
- Niccoll? Machiavelli
In LSL, we
desire to found a state and give it events! Or, better yet, several states -- each corresponding to a stage in the behavior that we want to script.
Arrgh, Why Can't I Just Start Coding?
Indeed, why bother with architecture at all? Just grab a lot of lumber and nails and have at it, until you get tired, or run out of lumber or nails. But if you work with LSL's nature instead of against it, you'll write better scripts and have more fun doing it.
LSL Architecture
An LSL script consists of:
- Optionally, global variables and functions. (But you aren't supposed to know about these yet!)
- At least one state, named default. Optionally, additional states.
- Optionally, some events within each state.
If you have programmed before, you are probably familiar with
flow charts, a graphical tool for designing programs in other languages. (If you aren't, so much the better; you won't be burdened with preconceptions!) Anyway, a useful graphical equivalent to an LSL script is a matrix of states and events.
Let's take the
Hello, Avatar! script as an example, and see what it looks like as a matrix:
| Event | default |
| state_entry | Say Hello, avatar |
| touch_start | Say Touched. |
The leftmost column lists events; states (this script just has one state) are listed in the top row. Where events and states intersect, we can write brief notes about what the event does in this state.
Talk about belaboring the obvious! But remember, this script does practically nothing; it just serves as a template for the script you want to write. Suppose you want the same event to be handled in more than one way, depending on some condition? You could, of course, test for the condition inside the event and branch to different sections of code. But it's easier to create a state for every variation of the condition (or anyway, it would be easier in a non-trivial example).
Two States, What A Thought!
Here's an example; the Tickle Box. The first time you touch it, it asks you to touch it again. The next time you touch it, it thanks you. The Tickle Box matrix looks like this:
| Event | default | tickled |
| touch_start | Say Now, touch me again.
Enter state tickled | Say Thank you! That felt good.
Enter state default |
What techniques do we need to write the Tickle Box script that we didn't already see in Hello, Avatar?
- A way to define a second state
- A way to move from one state to another
How To Define More States
Now here is a place where what has up until now been a boringly symmetrical language shows some character.
- If you define any state other than default, you need to prefix it with the word state or you'll get an error.
- But if you prefix default with state, you'll get an error.
Can you say
Works as designed?
Moving right along, here is the code to define the tickled state:
By the way, putting your terminating bracket in right away like this, and inserting the code that goes between the brackets later, is a good habit. It keeps your brackets-in and brackets-out balanced. Big time saver here! You're very welcome.
How To Move From One State To Another
Inside an appropriate event in state #1, use the
state command to enter state #2. For example:
// snip
state tickled;
// snip
How To Search This Wiki
To write your own script, you'll need to know how to find events, commands, etc. that you don't already know. In the bottom left corner of any page of this wiki, you'll see a text box labeled "