Introduction to Linden Scripting Language 139
prostoalex writes "Dr. Dobb's Journal runs a lengthy introduction to Linden Scripting Language, the language behind avatars and their interaction in Second Life: "LSL is a scripting language that runs server-side, on a piece of software called the simulator. The simulator does just what it's name implies — it simulates the virtual world of Second Life. Each simulator runs everything for 16 acres of virtual land — buildings, physics, and of course, scripts. While you manipulate the script text in a form that is somewhat easy to read, the actual code that runs on the simulator is compiled. A compiler is a piece of software that takes the text version of the script and converts it into something that can actually run. In the case of LSL, the compiler exists within the Second Life viewer itself. In the future, it is likely that the compiler will move from the viewer into the Second Life simulators, but where the code is compiled isn't very important. What matters is that the text is converted into a form that can run on the simulators.""
Re:A Way For Closed Source Scripts? (Score:2, Informative)
Re:what a strange summary (Score:5, Informative)
Re:What happened to Mono? (Score:2, Informative)
I do a pretty good bit of LSL... (Score:3, Informative)
Re:I do a pretty good bit of LSL... (Score:1, Informative)
Re:Credit where credit is due (Score:5, Informative)
All that is easy to find is sex.
There is a lot more out there, it is just hard to find. I've spent a lot of time sailboat racing in SL. I no longer have access to a boat and I really missed it. It it the same? Certainly not. Is it better, than nothing. You bet! When I raced sailboats I was on a big boat with others, now I'm at the helm. I couldn't afford to do that in the real world.
I hate to sound like spam but if you think sex is all that there is to SecondLife, just check out my web site, you might find something to do there that interests you. (Note, the site is supported by AdSense ads, if that offends you, please don't visit, or at least don't click on the ads!)
Paul aka Seeker Gray
Re:What happened to Mono? (Score:4, Informative)
Re:I do a pretty good bit of LSL... (Score:3, Informative)
Actually, LSL's lists do have efficient random access. The main catches are that they're immutable, which means that every time you want to change anything you have to copy the list (which is, of course, limited by LSL's 16Kb memory limit), and that you can't have lists of lists. (Also, their implementation of lists isn't particularly space efficient - each entry has to have its own heap entry, complete with a 7-byte header, and the list is an array of 4-byte pointers to the heap, giving 13 bytes/entry total overhead.)
Re:what a strange summary (Score:4, Informative)
The compiler sucks. For example, when you define a vector, it generates three "float literal" instructions rather than one "vector literal" instruction. This means that 2 instructions and 2 bytes more code than necessary are generated for each vector literal in the code (similarly with quaternons/rotations). (Remember, there's a 16Kb per script limit for code+data.) As a second example, there are two types of instruction for transferring data from the stack to local/global variables - store and pop (which is equivalent to a store, followed by a drop). For one, the compiler only ever seems to use the "pop" variant, whilst for the other it always uses a "store; pop" pair (despite this being inefficient) - I've never seen a lone "store".
Also, the goto is broken - due to a compiler bug/design error, only the last jump to a particualr label actually does anything. (The code for matching gotos to labels can only track one goto for each label.) This is a long-standing and well-known bug which I doubt would be difficult to fix, yet no-one's bothered.
There are also other useful instructions which are never used (such as various dups, an instruction for setting the instruction pointer directly - making jump tables/efficient switch statements possible - and an instruction for freeing arbitrary amounts of stack quickly). The compiler never optimises anything, either. It's why I don't hold out much hope for speed improvements from Mono (and indeed, the predicted improvements mostly vanished when they started running actual LSL scripts with it.)