LSL Protocol/RestrainedLoveAPI/de

/de

/LSL

Restrained Love viewer v2.8.1 Spezifikation

Original von Marine Kelley. Deutsche Übersetzung (ohne Gewähr).

Zielgruppe

Dieses Dokument ist für Leute, die vorhaben ihre eigenen LSL Scripte zu modifizieren oder zu erstellen, um die Vorteile des RestrainedLove viewer zu nutzen. Es erklärt weder die LSL Konzepte wie "messages" oder "events", noch universelle Konzepte wie UUIDs.

Dieses Konzept enthält die Spezifiaktionen für den RestrainedLove Viewer selbst. Wenn Du Informationen zum RestrainedLove viewer relay(RLV relay) benötigst, dann siehe bitte die RLV relay specification an.

Einleitung

Der RestrainedLove Viewer ändert sein Verhalten, wenn er spezielle Nachrichten von Scripten in-world erhält. Diese Nachrichten werden meist durch die llOwnerSay() LSL Funktion übermittelt.

Architektur

Der RestrainedLove Viewer hört alle llOwnerSay Nachrichten an den Viewer ab. Zeilen die mit dem at-Zeichen ('@') beginnen werden als RLV Kommando behandelt. Andere Zeilen werden wie gewohnt im lokalen Chat Fenster an den Benutzer weitergeleitet. Zum Beispiel wird llOwnerSay ("@detach=n") das detach Kommando mit dem Parameter n im Auftrag des Objekt in dem das Script läuft an den Viewer senden.

Die Syntax eine Nachricht ist:

@<command1>[:option1]=<param1>,<command2>[:option2]=<param2>,...,<commandN>[:optionN]=<paramN>

Beachte, dass dort nur ein '@' Zeichen an den Anfang der Nachricht gestellt wurde. Der Viewer interpretiert dieses als "die gesamte llOwnerSay() Nachricht enthält eine oder mehr Kommandos zum ausführen". Aus dokumentarischen Gründen werden hier Kommandos immer mit dem führenden '@' dargestellt. Wie auch immer ist es ein Fehler das '@' vor jedes Kommando innerhalb einer Multi-Kommanod Nachricht zu setzen, denn die nachfolgende Nachricht wird scheitern.

Historischer Hinweis: Vor Version 1.10 erlaubte RLV nur ein Kommando pro Nachricht. Version 1.10 wurde die Möglichkeit hinzugefügt mehrere Kommandos in einer Nachricht zu senden, um zu vermeiden dass Benutzer, die den Viewer nicht benutzen, gespammt werden.

Wenn mindestens ein Kommando scheitert (z.B. ein Schreibfehler) sagt der Viewer "... fails command : ... " und zeigt die gesamte Nachricht. Jedoch werden korrekte Kommandos weiterhin umgewandelt und ausgeführt, nur das Unkorrekte wird ignoriert.

Viele dieser Kommandos legen das nachfolgende Verhalten des Objekt oder Avatars fest. Zum Beispiel wird das @detach=n Kommando das vorhanden Objekt locken und macht es unabnehmbar. Einige Kommandos setzen globale Verhalten, die nicht auf das Objekt beschränkt sind, dass das Kommando sendet. Zum Beispiel wird @sendchat=n den Benutzer daran hindern im lokalen Chat zu sprechen.

Hinweis für Kommandos mit Aunahmen, wie @sendim oder @sendchannel... @(rule):(exception)=n wird aktuell eine Ausnahme hinzufügen für die genannte Regel. @sendchannel:1=n, zum Beispiel, erlaubt Chat auf Kanal 1. Dies ist der Grund für mindestens zwei Scripter Unregelmässigkeiten. =add (was das Gleiche bedeutet wie =n) und =rem (was gleich ist mit =y) existieren für den Zweck um Ausnahmen hinzuzufügen und wieder zu entfernen, Benutze .

	Warning!
	Diese Verhaltensweisen sind nicht beständig zwischen zwei Sessions. Da ein Objekt bei jedem rezzen die UUID wechselt, muss das Objekt den Status erneut im on_rez() Event senden (unabnehmbar, verhindern von IMs...)und auch wann immer es seinen Status ändert.

Liste der Kommandos

Himweis: Diese Kommandos sind nicht case-sensitive, aber leerraum-sensitive. Mit anderen Worten wird "@detach = n" nicht funktionieren.

Darstellungskonvention: Parameter in [eckigen Klammern] sind optionale Parameter und können ausgelassen werden. Der Schlot | und Schrägstrich / trennen Optionen von denen eine genutzt werden muss. <Spitze Klammern> schließen zwingende Parameter ein.