Hello World

Skripting in Second Life ist überraschenderweise relativ schwierig. Bevor ich nach SL kam, habe ich schon über 10 Jahre lang - zum Teil beruflich - mit den verschiedenartigsten Programmier- und Skriptsprachen zu tun gehabt, und dachte anfangs dass das Schreiben von Skripts in Second Life für mich doch wohl ein Kinderspiel sein müsste.
Ich dachte, dass LSL so ähnlich wie Javascript oder eine der anderen simplen Skriptsprachen funktioniert.
Durch diese Fehlannahmen habe ich erst nach über einem Jahr in SL wirklich angefangen selbst Skripting-Projekte umzusetzen, und habe zum Glück zu Beginn sehr geduldige Kunden gehabt.

Die Skriptsprache von Second Life konzentriert sich sehr auf die speziellen SL-Events und -Funktionen, und ist rund um diese herum konzipiert. Ganz im Gegensatz zu universell einsetzbaren anderen Skriptsprachen wie JS oder VBScript.

Leider hat sie auch viele Macken (fehlerhafte Funktionen, fehlende Funktionalität), die man als professioneller Content-Ersteller kennen muss, oder man muss eben viel Zeit investieren, um das zu verstehen.

LSL (Linden Skripting Language) fällt gleich in drei Kategorien von Programmiersprachen:

• State-driven
  
• Ereignisorientiert
  
• Prozedural (in einem gewissen Maß)
  

State-driven
State-driven bedeutet, dass jeder Code in LSL-Skripts irgend einem Skript-State zugeordnet ist. Mit State (zu Deutsch 'Zustand') ist nicht 'aktiv' oder 'inaktiv' gemeint, sondern jeder State ist im Prinzip ein eigenständiges Skript, und jedes LSL-Skript muss zumindest einen State haben ('default'), kann aber beliebig viele States verwenden, und zwischen diesen hin und her springen.



Jeder State - außer state default - wird aus dem Schlüsselwort 'state', und dem Namen des neuen States gebildet, z.B.: state nearby.

Man kann in obigem Beispiel-Skript erkennen, dass es in dem Beispiel zwei States gibt: state default, und state nearby. Beim "default"-State, der in allen Skripts vorhanden sein muss, wid das Schlüsselwort 'state' weggelassen (vermutlich damit man weniger schreiben muss).
In dem Skript wird geprüft, ob der Besitzer des Objekts anwesend ist, und wenn ja, wird mit dem Befehl 'state nearby;' sofort in den zweiten State gesprungen. Um das zu verdeutlichen, wird in dem State eine Nachricht im Chat ausgegeben.

LSL-Skripts sind case-sensitive, also eine Variable mit dem Namen meinSKRIPT ist verschieden von einer anderen Variable im selben Skript mit der Bezeichnung meinSkript.
Das gleiche gilt für Funktionsbezeichnungen und States.


Die hier blau gekennzeichneten Teile des Skripts sind Events, die rot gekennzeichneten sind LSL-Funktionen.
Events werden immer dann ausgeführt (teils automatisch), wenn gewisse Ereignisse in Second Life eintreten, z.B. wenn ein User an das Objekt anstößt, wird das collision_start() - Event aufgerufen, und der Code innerhalb dieses Event-Blocks ausgeführt.

LSL-Funktionen wie z.B. llSay() führen verschiedene spezielle Aktionen aus, in diesem Fall wird ein Text im Chat ausgegeben.

Events als auch Funktionen haben in ihrer Syntax gemeinsam, dass sie aus einem Funktionsnamen, und anschließenden Klammern (mit Parameter-Listen) bestehen:
llSay(PUBLIC_CHANNEL, "Owner ist anwesend!");
Rot ist der Funktionsname, und in den Klammern dahinter befinden sich die Parameter (oder auch 'Argumente').
Funktionen und Zuweisungen ( integer a = 3; ) müssen außerdem mit einem Semikolon ; beendet werden.

Dieses Beispiel llSay(PUBLIC_CHANNEL, "Owner ist anwesend!"); enthält als Parameter "PUBLIC_CHANNEL", und den Text der ausgegeben wird.
Public-Channel (oder auch dessen literaler Wert '0') ist der Code für den ganz normalen, öffentlichen Chat-Channel.

Dementsprechend gibt das Beispiel den Text "Owner ist anwesend!" im Chat aus.


Ereignisorientiert (Event-driven)
Event-Driven heißt, dass bestimmte Aktionen erst durch das automatische 'Triggern' von Events gestartet werden.
LSL enthält mehrere Events, z.B. enthält praktisch jedes Skript das state_entry() - Event, welches immer sofort dann ausgeführt wird, wenn das Skript (in-world) abgespeichert wird, und läuft.

So kann man mit dem collision-Event eine Meldung ausgeben, wenn ein Avatar das Prim in dem sich ein Skript befindet berührt (durch dagegen-laufen):



Gibt man dieses Skript nun in ein Prim in Second Life, dann wird das Objekt jedes Mal wenn ein Avatar dagegen rempelt, anfangen zu meckern:


Zur Erklärung: der orange-farben hervorgehobene Text in "collision(integer n)" ist der Standard-Parameter des Collision-Events, und überträgt jedes Mal wenn das Event angestoßen ('getriggert') wird, die Anzahl der Avatare und Objekte die gleichzeitig an das Objekt anstoßen.