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.

Aufbau und Eigenschaften

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.

Zustände

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.

Variablen

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.175494351E-38 bis 3.402823466E+38).
• 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 32bit-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, ...) u.a..
• 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.

Ereignisse

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 eintreten; damit können keine Kollisionen bei Operationen auf globalen Variablen auftreten.

Funktionen

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

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

Beispiel

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 total_number)
   {
       llSay(0, "Touched.");
   }

}

LSL und Mono

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.

Verweise

http://wiki.secondlife.com/wiki/LSL_Portal Offizielles LSL-Portal von Second Life/Linden Lab.
http://lslwiki.net/lslwiki/wakka.php?wakka=HomePage Inoffizielles LSL-Wiki

Quellen

http://wiki.secondlife.com/wiki/LSL_Portal Offizielles LSL-Portal von Second Life/Linden Lab.
http://lslwiki.net/lslwiki/wakka.php?wakka=memory Speicheraufteilung bei Standard-LSL
http://wiki.secondlife.com/wiki/LlGetFreeMemory Speicheraufteilung mit und ohne Mono