Slashdot Mirror

← Back to Stories (view on slashdot.org)

Introduction to Linden Scripting Language

Posted by ryuzaki0 on from the fad-or-fantastic dept.

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.""

9 of 139 comments (clear)

  1. Re:A Way For Closed Source Scripts? by Yetihehe · · Score: 2, Informative

    Yes. No. Well, sort of. You can just sell or give someone an object with compiled script. If he doesn't have rights to modify script, he don't see source code.

    --
    Extreme Programming - Redundant Array of Inexpensive Developers
  2. Re:what a strange summary by jfengel · · Score: 5, Informative

    The article isn't much better. It spends a lot of time going over what most Slashdotters already know, like what an "integer" is, and very little on what's novel about a scripting language for an interactive world (or whatever you want to call Second Life.)

  3. Re:What happened to Mono? by 0xDAVE · · Score: 2, Informative

    http://techconf.thepodcastnetwork.com/2006/09/19/t he-tech-conference-show-a-bit-about-second-life-eu rooscon-2006/

  4. I do a pretty good bit of LSL... by FishWithAHammer · · Score: 3, Informative

    ...or have done, really. The language is a bastard child of C, basically. Its major problem is its lack of arrays; you have a strange construct called a list that sort of does the same thing, but I really don't know why it's there instead of arrays. LSL is fairly underpowered. What I've taken to doing is using its HTTP system, though, to ping my web server, do something, and feed it back into the game. To do anything really impressive with LSL, it does seem to take an outside server to do the heavy lifting. It's kind of fun, though...

    --
    "You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time."
    1. Re:I do a pretty good bit of LSL... by Anonymous Coward · · Score: 1, Informative

      Also: Python arrays have both random access and arbitrary addition.
      You don't get both for O(1) though. The interface can have both but you're paying for one of them. Lists you pay O(n) for random access and arrays you pay O(n) for arbitrary insertion since you need to copy the whole thing.
    2. Re:I do a pretty good bit of LSL... by makomk · · Score: 2, Informative

      You crazy fool, they're both linear data structures that have similar interfaces. You lose random access with lists, but you gain the ability to add an arbitrary number of elements.

      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.)

  5. Re:Credit where credit is due by notthepainter · · Score: 4, Informative

    it's funny, i just checked out 2nd life last night -- first time since a year or two ago -- and i was pretty amazed -- the place is one big car lot or sex club. really. i guess there are two kinds of people in 2nd life now -- the people selling "sex", and the people trying to sell their objects to buy the "sex".
    This is why I started my web site http://www.secondseeker.com/. The parent poster is mostly right and completely wrong.

    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

  6. Re:What happened to Mono? by Erbo · · Score: 3, Informative

    It's still being worked on, and, in fact, there have been some recent developments that have moved this work forward significantly. See this entry by Babbage Linden on the Official Linden Blog from last month for more details. It involved finding a memory leak in the Mono runtime which would have caused memory usage in the simulator code to grow unacceptably over time. LL personnel like Babbage worked closely with Mono team members to resolve this.

    --
    Be who you are...and be it in style!
  7. Re:what a strange summary by makomk · · Score: 3, Informative

    The summary quote uses 108 words to explain that there exists a compiler for this language.

    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.)