Linden Scripting Language

Die Linden Scripting Language (oder kurz LSL) ist eine von Linden Lab entwickelte imperative Skriptsprache, die der Steuerung von Objekten in der virtuellen 3D-Welt Second Life dient.

LSL ist eine ereignisgesteuerte Sprache, die in Anlehnung an endliche Automaten entwickelt wurde. Jedes Skript besteht dabei aus mindestens einem Standardzustand mit der Bezeichnung default, welcher zugleich den Anfangszustand des Automaten darstellt.

Wie bei deterministischen endlichen Automaten hat jedes LSL-Skript eine feste, endliche Anzahl von eindeutig benannten Zuständen, allen voran der default-Zustand, welcher den Initialzustand darstellt und zwingend vorhanden sein muss. Zustandswechsel werden mit der state-Anweisung vollzogen, welche den Namen des Zielzustands als Parameter erwartet.

LSL kennt lokale und globale Variablen. Variablen können folgende Datentypen haben:

• integer: vorzeichenbehaftete 32bit-Ganzzahlen im Wertebereich von −2³¹ bis 2³¹−1 (also von −2.147.483.648 bis +2.147.483.647, oder 0x80000000 bis 0x7FFFFFFF hexadezimal).
• float: 32bit-Fließkommazahlen im IEEE-754-Format (also absolut von 1,175494351·10⁻³⁸ bis 3,402823466 10 ⁺³⁸).
• string: Zeichenketten. Die Länge von Zeichenketten ist theoretisch unbegrenzt, praktisch jedoch durch die Größe des für das Programm reservierten Speichers beschränkt. Da sich der Bytecode, Heap sowie Stack diesen Speicherbereich teilen, kann die maximale Länge für Zeichenketten – je nach Skript – zur Ausführung beliebig klein werden.
• key: UUID (Universally Unique ID), welche zeitlich sowie räumlich eindeutige 16-byte-Schlüssel im Second Life-Universum darstellen. Sie dienen der Identifikation von Objekten, Avataren, Texturen, Audiodateien sowie logischen Konstrukten/Anbindungen (HTTP- und RPC-Verbindungen, Listener, …) und anderen.
• vector: Tripel aus jeweils drei benannten float-Komponenten 'x', 'y' und 'z'; sie dienen primär der Darstellung von Vektoren im naiven dreidimensionalen Sinne, der Farbdarstellung im RGB-Farbraum, teilweise auch als Offset- und Positionsvektoren zur Ausrichtung von Texturen.
• rotation: Quaternion als Typ zur Darstellung komplexer Rotationen.
• list: ein Typ zur Darstellung linearer Listen. LSL-Listen können als Arrays aufgefasst werden, d. h., sie stellen Folgen der festen Länge n von LSL-Werten dar, deren Komponenten von 0 bis n−1 adressiert sind. LSL-Listen können keine weiteren Listen enthalten.

In jedem Zustand eines LSL-Skripts können Ereignisse (events) deklariert werden. Die Menge der definierten Ereignisse wird von Linden Lab vorgegeben, wie etwa state_entry() (das Skript nimmt den benannten Zustand an), touch_start( integer num ) ('num' Avatare haben das enthaltende Objekt berührt, also angeklickt) oder http_response( key id, integer status, list metaData, string body ) (ein HTTP-Server hat seine Antwort gesendet).

Mit jedem Ereignis ist ein Anweisungsblock assoziiert, welcher beim Eintreten des Ereignisses ausgeführt wird und vom Programmierer frei definierbar ist. LSL-Skripte sind derart synchronisiert, dass nie mehr als ein Ereignis zeitgleich eintritt; damit können keine Kollisionen bei Operationen auf globalen Variablen auftreten.

Linden Lab bietet eine relativ umfangreiche Funktionsbibliothek, die vom Programmierer frei verwendet werden kann. Dabei gibt es sowohl reine Funktionen nach klassischer Auffassung (zum Beispiel llSin(float x) zur Berechnung der Sinusfunktion) wie auch Funktionen mit Prozedurcharkteristik (zum Beispiel llTargetOmega(…), welche zum Starten einer autarken Objektrotation genutzt werden kann).

Des Weiteren ist es möglich, eigene Funktionen zu definieren, welche auch Mischformen aus Funktion und Prozedur sein können und auf globalen Variablen des Skripts operieren dürfen.

Anbei folgt das Standard-Beispielskript von Linden Lab, welches dem üblichen Hallo-Welt-Programm entspricht.

 default
 {
    state_entry()
    {
        llSay(0, "Hello, Avatar!");
    }

    touch_start(integer num_detected)
    {
        llSay(0, "Touched.");
    }
 }

Im Herbst 2008 begann Linden Lab damit, die bis dato verwendete LSL-Implementierung durch die Open-Source-Software Mono zu ersetzen, welche eine .NET-kompatible Laufzeitumgebung darstellt und durch die erhebliche Laufzeitverbesserungen verzeichnet wurden. Des Weiteren vervierfachte sich damit der für jedes Skript verfügbare Speicher von 16 KiB auf 64 KiB. Etwa gleichzeitig begann der Mono-basierte Nachbau von LSL für OpenSimulator, dem Open-Source-Pendant von Second Life.

• wiki.secondlife.com Offizielles LSL-Portal von Second Life/Linden Lab
• lslwiki.net Inoffizielles LSL-Wiki (Nicht mehr aktuell, Offline)
• Speicheraufteilung bei Standard-LSL lslwiki.net (Nicht mehr aktuell, Offline)
• Speicheraufteilung mit und ohne Mono wiki.secondlife.com
• Second Life: Mono Wiki wiki.secondlife.com