Scripting Overview

I’ve become fascinated by Second Life scripting, and I think I’m getting fairly good at it. This blog isn’t intended so much as an introduction to scripting, as an exploration of how to do scripting well. There are some introductory articles as well. I hope you find all of them helpful.

Introductions to LSL Concepts

This section contains articles introducing the ideas and statements used in Linden Scripting Language.

Introduction to Events

An introductory article on events, probably the most unique aspect of Linden Scripting Language, and one of the most important.

Introduction to States

An introduction to states, another unique and important aspect of LSL.

More Comments on Comments

This article on comments is also a nice little discussion of states, another unusual and important aspect of Linden Scripting Language.

Style in Scripting

I’ve been lucky enough to have some good teachers, who tried to pound some good ideas about programming as communication into my head. I’ve been trying to apply those ideas here in Second Life, and I’ll write about what I’ve learned.

Many of these ideas will seem strange to people who have been programming for a while. Maybe they are strange. Still, I find them very useful, and people who have read my scripts say that they are very easy to understand and to change.  So … read, think, and maybe give these ideas a try. I’ll be interested to hear what you experience if you try them.

Intention: 1

I have been taught to make my code say what I mean. This is called “Programming by Intention” or “Intentional Programming”. Give it a look: I think you’ll find it interesting and maybe even useful.

Intention and Code Improvement

Working on the Piano of Damocles, I find a problem and while fixing it, improve the code a bit. This article presages the much longer series on refactoring.

Comments on Comments

Let’s face it, we put comments into our programs because they’re not easy to understand. Can we make them easier to understand so as to need fewer comments?

More Comments on Comments

It often happens that after we let a program rest for a while, we can see ways to do better. It’s worth doing because it makes the program better, and it prepares us to do better work next time.


I’d like to grow up to be a craftsperson in scripting. So I pay attention to how things go, and try to learn lessons from it. Here are the lessons so far:

Pressure, Even Here

Too much pressure makes bad things happen.

Single Builder

Second Life makes it very hard to collaborate. Centralize changes with a single person?

Code Repository

As we change code rapidly, especially as a team, we need to save our changes consistently.

Tiny Modules

It’s hard to write small modules in Linden Scripting Language, but it pays off.

Shared Code View

We really need a way to work together on code sometimes. It’s hard in SL. Pastebin is one way.


Refactoring is a process of improving the design of a script by making small reversible changes. To be certain that we don’t make a mistake and break the program, we need to use tests, called “characterization tests”. I’ve written a long series of articles on a refactoring example.

An Experiment in Refactoring

I start out innocently enough, with a large working program of Dizzi’s, that animates the legs of a horse by making different prims visible and invisible. The first thing to do is understand the script a bit, then start writing tests.

Refactoring Experiment Continues

Here I talk a little bit about the approach I’ll take, which is to work in very small steps and always be willing to step back if something doesn’t look good. Then I add more tests to be sure I don’t break something.

Refactoring III: Tests in Place

I thought I’d get to improving the code in this article but as we talked about it, you and I, I realized that I was about to change something without tests protecting me. So I invent a new test and make it work. I’m writing these little blurbs after completing the series, so I happen to know that we’ll decide to change this test way down in article nine. Can you see why?

Refactoring IV: Let’s Improve the Code

Here, I start to improve the code. As I often do, I look for duplication of code, which usually offers a change to make things more compact and therefore, usually, better.

Refactoring V: Will This Never End?

In this article, I discover that the original code isn’t quite consistent. Sometimes it makes new leg positions visible and then makes the others invisible, and sometimes the other way around. I decide to make the new version consistent, and adjust the tests accordingly.

Refactoring VI: How Many Roman Numerals Do I Know?

I discover in this article that one of my tests is wrong and so the code is wrong as well. In addition, we’ve encountered a new situation in the original code, where it turns off more things than it turns on. We improve the tests and make the code perform this new function.

Refactoring VII: This Series Has Legs!

The script is now using the new “changeVisibility” idea, and I begin to look for a way to put in the idea of a “leg” abstraction. It turns out that I find a leg position abstraction, which looks pretty nice.

Refactoring VIII: Real Close Now …

With the leg position idea in the code, I try a change that will reduce all the constant definitions at the front of the program. It doesn’t make the code better, and I back it out. Lesson learned? Nothing profound. Try little things, and if we don’t like them, undo them. When changes are small, we don’t mind learning that way.

The series is done as far as I’m concerned, and I summarize key ideas: tests, tiny steps, removing duplication, improving clarity.

Refactoring IX: Wait! This Just In!

Arrgh! Dizzi, in reviewing what was done, decides that it’s better to make the new leg position visible first, and then make the old one invisible. When I resolved the inconsistency in the original, I went the other way! Now we have to change everything!

This change really was a surprise to me: I thought I was done. How hard was it? Well, if refactoring improved the code, it should be easier than it would have been. Take a look!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at

Up ↑

%d bloggers like this: