This is the third in a series of Caledon Oxbridge articles on scripting in Second Life™. In the first article we covered the environment of scripts in SL and in the second article the concept of variables and data usage. Now it’s time to look at the overall structure of scripts.What are the top-level building blocks of scripts?
Global Variable Definitions
Variables that are defined (but not necessarily initialized) outside of any other structure are known to the entire script and are called global variables. In addition, the values placed into global variables persist between events, so they are the means of communicating data between event-handlers in a script. One potential scripting tripping point is that, in the global variable definition section, any initialization done cannot involve operations (addition, subtraction, …) or function calls. Those have to be done in an event-handler. If you try such active definitions here, you will get the “highly informative message” syntax error on trying to save the script. Note also that global refers only to the single script and not to other scripts even in the same prim or linkset; it’s rather like World Series does not involve most of the world.
User Function Definitions
A function is essentially a bit of coding that’s been separated out to do a specific task. A function may get its data via arguments (also known as parameters) in its calling expression (i.e. the name of the function followed by data to be given to the function within parentheses) or it may do so via global variables. It may return a variable to the calling code or it may simply take some action. For example, a function might by passed the name of a texture in the object’s inventory, and put that texture on the face specified by a global variable. There are many built-in LSL functions, all having names starting with two, lower-case L’s. In addition, a scripter may create their own functions, outside of other structures. The reasons for doing so include having one definition of code needed in multiple places in a script (i.e. maintainability) or removing details from event-handlers to keep the coding easier to follow (i.e. readability).
State Definitions
States are containers for event-handlers and every state has its own set of event-handlers. Every script has one required state, the default state, which ironically is the only state defined without using the keyword “state” before the state name. The scriptwriter can define additional states (and their event handlers) as needed. Changing states has side-effects, such as removing listeners. Timers, however, persist across state changes.
One particular extra state that I’ve found to be useful is a parking state, a place to park the script until a needed inventory item is added, ensuring that the script isn’t active until then. Never mind that the declaration state park appeals to my sense of humor. Another simple example is a reflector state: a state that the script can change to that immediately changes back to the default state. Given that a state cannot change states to itself, this is a means of forcing a state_entry event in the default state.
Event Handlers
Event handlers are always defined within a state, and many scripts have only the default state. The event-handlers in one state do not effect other states. Well, at least they aren’t supposed to. There was a bug such that, on shifting to a state without a touch handler and then shifting back to a state with one, the first subsequent touch would be ignored. The work around was to create a do-nothing touch handler in the second state.. There’s a list of events on the LSL Portal.We will be using various events as we take up scripting projects.
Please note that the two characters “//” make everything on a line after them into a comment and that major script structures are delimited by curvy brackets ({, and }). With that, the basic script structure looks like:
// Comments saying what the script does, who wrote it, and when
// Global variables
// User Defined Functions
default {
state whatever {
That covers the basics of script structure. In the next article, we’ll start working with example scripts, which should make all of what I’ve covered to this point become a lot clearer. Actual usage helps a lot. As always, thank you for your attention.
Caledon Oxbridge also has an inworld Basic Scripting class, Mondays at noon SLT in our main lecture hall. Please see our schedule page.