287Scripting Basics for the Designer
Line 11 has a new function to tell the object to do. This function, like the llSay() function, also needs
some information, put inside its parentheses, called parameters. The typical syntax for the function
and all that it expects to have on its line is this:
llSetColor(vector color, integer face);
What this means is that you must dene the color in terms of red, green, and blue percentages, and you
have to specify which faces on the object should change color. Note: you can nd out the number of a par-
ticular face by selecting with the Build/Edit menu/Select Face and looking at the notation just above the tabs
line on the menu interface.
As we discussed in Chapter 7, color is indicated by percentages (0% or 0 to 100% or 1) in a virtual
world. Within this function, to obtain the color primary bright red, we ask for R = 1.0, G = 0, and Blue = 0,
which is indicated between < and > or the pointy brackets, and would look like this <1.0,0,0> or this
<1.0,0.0,0.0>. Leave the extra spaces out between the numbers; the commas will do the separation for
the compiler.
To make sure all the sides of the cube change, we are going to use a constant, which is indicated in
CAPS at the end of the function. ALL _ SIDES indicates that all the sides are chosen. It is important to use
ALL _ SIDES in this little script because various primitives (or objects) will have varying numbers of sides.
This will cover all possibilities from the one-sided sphere to the seven-sided hollow cube that numbers its
faces from 0–6.
Line 12 is blank for clarity purposes.
Line 13 closes the script block that has the llSetColor () function in it with the curly bracket or}.
Line 14 is blank for clarity purposes.
Line 15 closes the rst script block and sends our cube back to the default state.
14.5.4 reVieW of BasiC sCripT elemenTs
Now, to recap what we have seen so far. We have looked at three very basic scripts in LSL. All of these
scripts had a default state and other states enclosed by { and }. These states contained events such as
touch _ start. We also had some LSL functions, such as llSay() and llSetColor(), and these func-
tions asked for integers as well as constants. All of these terms and more are dened in much greater detail
in the Second Life LSL Wiki (http://wiki.secondlife.com/wiki/LSL_Portal).
14.5.5 some neW sCripT elemenTs: ConsTanTs and VariaBles
Let’s introduce a few more new terms that are common to many LSL scripts and how they might have an
impact on your design decisions.
Two of the most common elements in scripts are called Constant and Variable. Constants are values
that never change, and are expressed in ALL CAPS. For example, ALL_SIDES contained in the function
llSetColor(<1.0,0,0>,ALL_SIDES), is a constant.
Variables give you places to store data in the script for use as the server runs it. There are seven kinds of
data that can be contained in a variable: string, integer, oat, list, vector, rotation, and key. A string is a line
of text enclosed in quotes, like “Hello Avatar,” and an integer is a number, only a whole one, not fractions or
decimals. A oat is a number that has decimal places, like 1.0 or 2.5. Lists are special kinds of data enclosed
288 Virtual World Design
in square brackets, [ and ], for example [“this is a list,” 125, 2.34, <1.0,0.0,0.0>,<0.5,0.0,0.1,1.0>] and are
often seen in scripts for texture animations and particle effects. A vector is 3 oats inside of pointy brackets
<and >, such as the number for the color green, <0.0,1.0,0.0>. Rotations are 4 oats also in the pointy
brackets and indicate the object’s relative position to the axes of the virtual space and its angle of banking,
for example <0.0,0.2,0.0,1.0>. A key is a unique number, or UUID (Universally Unique IDentier) given to
every texture, object, sound, avatar, and animation in the virtual environment. These numbers are generated
randomly when the item is created or rezzed from the inventory and allow for the script to nd the particular
item in the simulation, connect with it, and run its code.
Let’s sum up the concepts in LSL scripting. Oberon Onmura, one of Second Life’s master scripters and
art makers, described it this way to me: “I think of LSL as an ‘event driven state machine’ in which func-
tions are nested within events which are nested within states. So a state is a dened environment, events
reect things that happen within that environment, and functions are the things that actually do stuff in
response.” Another way to think about it is to visualize the cause and effect you encounter in the real world.
For instance, let’s suppose you are taking an afternoon nap on the couch. Think of this as the “state” you are
in. Your new puppy decides to jump up on your stomach, which is an “event.” The nerves acting like “event
handlers” in your abdomen feel the impact of canine weight and send signals to your brain which causes you
to enter another “state,” and you wake up. The brain sends signals acting like “functions” to your arms, so
you can steady the bouncing puppy. More events can follow, and more states can be entered, and more func-
tions can be triggered, all dening what happens in your real environment. LSL is designed to help create
real world scenarios in a simulator environment, and that is why it has this specic structure. Now that you
have the basic concepts, you are on your way to learning more about how to enhance the user’s experience
in yourdesigns.
14.6 DO IT YOURSELF OR HIRE A SCRIPTER?
For some folks learning about LSL, scripting is like learning a foreign language. To really get the hang of
it, you need to immerse yourself and do it every day for a few months. Learning LSL can be rewarding, but
you will need to have the time for focused study or already be adept at another programming language like
Java or C#. Making the decision to devote time for training in scripting will most likely be driven by the
parameters of your project and your goals for self-development as a designer.
For instance, if you are designing and building an amphitheater with 50 seats and need a sit script for the
audience in each chair, you might want to take the scripting task on by yourself. There are several tutorials
online that demonstrate how to use this basic script and readily available free sit scripts in the LSL library
that you could probably modify and use. Modifying existing scripts that are available to the community is a
good way to learn about how to manipulate variables and use constants in an LSL script.
Another example of a good do-it-yourself project is particle script work. Just having one good working par-
ticle script can give you the foundation for creating everything from bonres to snowstorms. The best place to
acquire information and pre-written scripts is at the Particle Lab in Second Life, (http://maps.secondlife.com/
secondlife/Teal/191/56/21).
Reach out to the community; there are several groups in Second Life, notably Builders Brewery, College
of Scripting Music Science, and one named Scripts, where you can contact experienced scripters to share
your efforts and ask for support. In OpenSim, many scripters exchange information on the OS Grid Forum
(http://forums.osgrid.org/), and they keep a large script library there for all to use.
The best thing is to try it, see what works for you in the parameters of your skill level, and push a little bit
harder each time to make more scripts for your inventory. It will give you not only more condence as a virtual
builder and designer but also more granular control over the behavior of your designs. The autoscript program
289Scripting Basics for the Designer
generates simple scripts that can be combined, and that also will broaden your LSL understanding. For example,
the llSetTexture () function from one could be combined with the llSetColor () function in our previ-
ous example to create a more dynamic script for your cube. All you need to do is generate another script that
changes the texture on the sides of the cube when touched. Copy and paste in the new lines of script from the
second script into the rst one, making sure that the new function is within the same brackets and state as the
rst one. To keep it simple in this example, both scripts begin with a touch _ start event handler. Table14.4
analyzes the result of these two scripts combined. If you decide to test this inworld, note that the name of the
texture has an underscore in it, “Texture _ 1,” and is exactly how it needs to be named in the object’s contents.
All that considered, nothing is better than working with a talented LSL scripter when you have a complex
project. The creative synergy that can develop when the team is trying to do new things with scripting and
building is well worth the fee that you may have to pay to obtain expert advice.
14.7 HOW TO TALK TO A SCRIPTER ABOUT LSL SCRIPTS YOU NEED
For most of this chapter, we have discussed the parts of some basic LSL scripts and how those parts work
together. This knowledge will come in handy when you sit down with a scripter to design a complex script.
Let’s suppose you have a fancy apartment building in mind, and all the doors will be scripted to open at their
owners’ verbal command. Also, you would like the apartment owners to have the option of adding a guest’s
name to the door when the apartment is being lent. If you try to think about that like a scripter, what elements
of an LSL script do you begin to see? Try to ll in the plain English/right side of the script analysis table
(Table 14.5) rst so you will have a list from which the scripter can work.
TABLE14.4
Combining Two Functions in a Simple Script
Line No. Script What It Means in English
0
//This script was auto-generated by Ann Enigma’s
script autogenerator
Comment: where the script came from.
1
//available at http://www.3greeneggs.com/autoscript/
Comment: how you can get one.
2
//Note: You will need to copy both this script and a
texture (named Texture_1) into your object
Comment: how to use this script.
3
default
“start here”
4
{
New block of code, start of new State.
5 Blank Line.
6
touch_start(integer total_number) {
Event = do something when touched
and start of next block of code.
7 Blank Line.
8
//change color!
Comment: what the next Function does.
9
llSetColor(<1.0,0,0>,ALL_SIDES);
Function = change color to red, all sides.
10
//set the texture
Comment: what the next Function does.
11
llSetTexture(“Texture_1”,ALL_SIDES);
Function = change texture to the one
inside the object’s contents, all sides.
12
}
End of code block.
13 Blank Line.
14
}
End of script, return to default.
290 Virtual World Design
This exercise should have shown you the following two things:
1. This kind of door script is probably beyond the abilities of a novice scripter.
2. There are many factors that can go into creating even the simplest things in a virtual world, especially
if we want them to be interactive.
It is not typical to think of a virtual door as interactive, but in fact, doors most often are to some extent.
A good scripter will make a nice, clean, readable door script with understandable comments on it. A great
scripter will look for and suggest ways the door can be made more interactive and streamline the script to
help the script run faster.
14.8 SCRIPTING AND VARIOUS PERFORMANCE PITFALLS
Every prim or object, every texture on them, every script in them, demands attention from the processor
of the virtual machine that runs your sim. When this is overtaxed, we begin to experience “lag,” which
can manifest in various ways. Our chats and instant messages (IMs) start to show up out of order, making
conversation difcult, or our avatars and their cameras jerk or just freeze in position.
The following is a list of some of the biggest lag producers in the scripting family as well as scripts that
can interfere with the overall rendering of the virtual world on your screen:
1. Listener scripts that are utilizing the llListen() function to scan the region for chat to which they
should respond. If there are a lot of these scripted objects, it will start to have an impact on the server’s
processing time, especially if these objects are all listening and chatting on the same channel.
2. Lots of changing textures or animation of textures on the surfaces of your build will demand signi-
cant processing time from your viewer.
3. Physics-based elements such as vehicles, moving animals, or even physical coconuts falling from a
tree can add work for the physics engine and tax the region’s processing response.
4. Object-embedded software scripts, such as URL givers that open a viewer or seek a database on an
outside server, will add to the load.
TABLE14.5
Setting the Parameters for a New Door Script
Line No. LSL Code What You Want the Script to Do
?
The door has to rotate on its hinge.
?
The door has two States in its script besides the default; they are Open
and Shut.
?
The door knows who the owner is; it has the owner’s identity, called Key
or UUID.
?
The door lets the owner update a list of people with access to the owner’s
place so they can enter.
?
The door needs to open on the owner’s verbal command.
?
The door needs to shut by itself after some time or when the owner or
guest touches it again.
?
The door makes a nice closing and opening sound.
291Scripting Basics for the Designer
When you need to use scripts like these in great quantities, you should keep an eye on the performance
of the sim and check periodically to see if you are running efciently. You can track the impact of your
scripted objects with the performance tools provided in the viewer[1]. You will nd the lag meter and
the sim statistics window under the top bar menu, Advanced/Performance tools in Firestorm viewer.
(Note,ifyour Advanced menu is not showing, it can be activated under the Avatar/Preferences/Advanced
tab on the top bar menu.)
To keep an overview on the server, check the lag meter. The lag meter indicates client, network, and
server lag, with “stoplight”-based graphic indicators for each lag type. Green is good, yellow indicates
some drag on the system, and red is a serious problem with your connection or client.
After you have checked the lag meter, open the statistics window. As you read down the listings on
the statistics window, note the frame rate given in frames per second (fps). A good range for frame rate is
around 15–30 fps for a virtual world. This is much slower than what you would have in an action-based
console game, but it is acceptable for the exploration of a virtual world space. Also look at these three
things in the statistics window: Ping Sim, Packet Loss, and Time Dilation.
The Ping Sim value measures the time (in milliseconds) that it takes for a packet from the viewer
to reach the server. A high number such as 150 milliseconds and above could indicate your network or
Internet connection has a problem or is too slow, or you have just turned your draw distance up too high
and are looking at thousands of objects within that view. Many things affect Ping Sim, and all should be
taken into consideration.
If Packet Loss is greater than zero, there may be a problem with your network or ISP (Internet service
provider) connection.
Time dilation is usually the best indicator for lag; the lower the number is, the better.
Remember, your viewer is doing lots of work, so much of what is considered “lag” may be caused by
your graphics settings and the speed of your graphics card. Try always to have your graphics set for what
is minimally acceptable unless you need to have ultragraphics performance for a snapshot or machinima.
14.9 DEBUGGING AND TESTING AND THE IMPORTANCE OF THOSE TASKS
Eventually, you and your scripter will create that special door or vehicle script that you hope will provide
many useful options for the avatars that use the content you make. Now, how do you test it and add the quali-
ties to make it bulletproof?
You should expect a thorough debugging of all new code from good scripters. They do this in various
ways. They can run the code in test objects under various conditions, such as crowded sims or heavy lag, or
they can utilize the Debug Functions that are available in the viewer to force the system into a demanding
testing mode. Other ways they should test your new script is by running it under other operating systems,
such as the Mac OS and Linux. Scripts that will compile and run in Windows may give error messages in the
Mac OS or not run at all on a Linux-based machine.
Other reasons to test in various systems and conditions are the differences in various LSL editors and
how they will report error messages differently to the script writers. In fact, there is an integer constant
DEBUG _ CHANNEL that is reserved for script debugging and error messages. This is a special chat chan-
nel used for script debugging and error messages. The viewer will display chat on this channel in the script
console to help the scripter nd their errors.
The nal test of good scripting will come when the object and its script are set up by the scripter to be
tested under live conditions, called “play testing.” These sessions are useful, especially if you and your
scripter can have a wide variety of people test the item in question.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.