logo
Homepage-Sicherheit

Willkommen Gast! Um alle Funktionen zu aktivieren müssen Sie sich Anmelden oder Registrieren.

Mitteilung

Icon
Error

Einloggen


Beitrag melden
Geschrieben von: MartinRJ Fayray Offline Geschrieben Sonntag, 7. September 2014 07:08:10(UTC)
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.

Zitat:

//--------------------------------------- STATE DEFAULT
default
{
state_entry()
{
if (llListFindList(llGetAgentList(AGENT_LIST_REGION, []), [llGetOwner()]) != -1)
{
state nearby; // Besitzer ist anwesend!
}
}
}

//--------------------------------------- STATE NEARBY
state nearby
{
state_entry()
{
llSay(PUBLIC_CHANNEL, "Owner ist anwesend!");
}
}


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

Zitat:

default
{
state_entry()
{
llSay(PUBLIC_CHANNEL, "Skript wurde gestartet!");
}

collision(integer n)
{
llSay(PUBLIC_CHANNEL, "Stups mich nicht!");
}
}


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:
Zitat:
[01:52] Object: Stups mich nicht!


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.

Hello World
Geben Sie den Meldetext hier ein.
Fett Kursiv Unterstrichen   Hervorheben Zitat Sprachauswahl für Syntax Highlighting Bild einfügen Link einfügen   Unsortierte Liste Sortierte Liste   Linksbündig Zentriert Rechtsbündig   Herausrücken Einrücken   Weitere BBCodes
Schriftfarbe: Schriftgröße:
Melden Abbruch

Powered by YAF.NET | YAF.NET © 2003-2017, Yet Another Forum.NET
Diese Seite wurde in 0.105 Sekunden generiert.

Datenschutzrichtlinie
Haftungsausschluss
Impressum
Datenschutzerklärung
AGB, ToS
Kontakt