LSL Protocol/RestrainedLoveAPI/de

/de

/LSL

Restrained Love Viewer v2.8.1 Spezifikation

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

Um Mithilfe bei der Übersetzung wird gebeten. Bitte in-world Laura Eun kontaktieren!

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.

Versions Prüfung

• Automatische Versions Prüfung : "@version=<channel_number>"

Eingeführt in v1.0b Lässt den Viewer automatisch die verwendete Version der RLV API auf der Chat Kanal Nummer <channel_number> sagen, die das Script abhört. Benutze immer eine positive Zahl. Bedenke, dass reguläre Viewer nie etwas antworten also entferne den Listener nach einem Timeout.

Warnung : beim einloggen geschieht das on_rez Event lang bevor der Avatar Nachrichten versenden kann (ungefähr bei der Hälfte der Login Bar). Das bedeutet, dass der Timeout lang genug sein sollte, zwischen 30 Sekunden und 1 Minute lang um die automtische Antwort vom Viewer zu erhalten.

Warnung 2 : Am 02/22/2010, hat Linden Lab ihre Third Party Viewer Policy veröffentlicht, die es verbietet den Begriff "Life" im Namen eines Third Party Viewers zu verwenden. Deswegen musste "Restrained Life" in "Restrained Love" umbenannt werden. Aus Kompabilitätsgründen wird @version trotzdem auch weiterhin funktionieren, jedoch solltest Du es nicht in neuen Scripten verwenden und nirgendwo den Begriff "Restrained Life" dem User anzeigen. Für neue Scripte solltest Du stattdessen @versionnew verwenden.

• Automatische Versions Prüfung : "@versionnew=<channel_number>"

Eingeführt in v1.23 Lässt den Viewer automatisch die verwendete Version der RLV API auf der Chat Kanal Nummer <channel_number> sagen, die das Script abhört. Benutze immer eine positive Zahl. Bedenke, dass reguläre Viewer nie etwas antworten also entferne den Listener nach einem Timeout.

Dieses Kommando ist der Nachfolger von @version und ersetzt es, obwohl @version für die Aufwärtskompabilität bestehen bleibt. Es gibt "RestrainedLove viewer v... (SL ...)" ("RestrainedLove" ist ein Wort) zurück.

Warnung : beim einloggen geschieht das on_rez Event lang bevor der Avatar Nachrichten versenden kann (ungefähr bei der Hälfte der Login Bar). Das bedeutet, dass der Timeout lang genug sein sollte, zwischen 30 Sekunden und 1 Minute lang um die automtische Antwort vom Viewer zu erhalten.

• Automatische Versions Nummer Prüfung : "@versionnum=<channel_number>"

Eingeführt in v1.21 Lässt den Viewer automatisch die verwendete Version Nummer der RLV API (bitte beachte, das dies unterschiedlich ist zur Version vom Viewer, aber das Script sollte sich nicht drum kümmern) auf der Chat Kanal Nummer <channel_number> sagen, die das Script abhört. Benutze immer eine positive Zahl. Bedenke, dass reguläre Viewer nie etwas antworten also entferne den Listener nach einem Timeout. Dieses Kommando ist weniger schwerfällig als @version, weil das Script nicht erst die Antwort verarbeiten muss, es erhält die Nummer sofort.

Die Versions Nummer ist bloss eine Zahl, die die Version der API darstellt. Wenn die Version X.Y.Z.P ist, dann ist die Nummer X.10^6 + Y.10^4 + Z.10^2 + P. Als Beispiel, 1.21.1 würde 1210100 sein.

• Automatische Versions Prüfung, zweiter Weg : llGetAgentLanguage (key id) ÜBERHOLT: NICHT BENUTZEN !

Eingeführt in v1.16 Wenn man diese LSL Funktion aufruft, bekommt man das Ergebnis sofort (es wird kein listener oder timer benötigt), es ist exakt gleich zu dem Ergebnis von "@version" und kann vom Benutzer nicht ausgeblendet werden. Dieser String übernimmt den Platz der Sprache die vom normalen Viewer zurück kommt, der Werte wie "en-us", "fr", "ko" etc zurückgeben könnte. Oder auch nichts, falls der Benutzer sich entschieden hat seine Spracheinstellung zu verstecken. Es ist optional im normalen Viewer und kann nicht von Scripten sicher verwendet werden, also macht das "entführen" dieses Features für die viel nützlichere und synchrone Versions Prüfung im RLV Sinn. WICHTIGER HINWEIS: dieses Feature kann nicht in Viewern vor v1.21 verwendet werden, selbst wenn diese RestrainedLove 1.16 verwenden. Also stelle sicher, dass Du auf die @version Methode zurück fällst wann immer llGetAgentLanguage() einen leeren String zurückgibt. BEACHTE AUCH: In RestrainedLove 1.16, llGetAgentLanguage() wird während des Logins bei on_rez einen leeren String zurückgeben, solange der Aufruf nicht um mehrere Sekunden verzögert wird (wie viele Sekunden kann unterschiedlich sein). ABSCHLIESSENDER HINWEIS: Dieses Feature wurde in v1.16.1 entfernt (und v1.16b, für den Cool SL Viewer).

• Manuelle Versions Prüfung : "@version"

Eingeführt in v1.0a Dieses Kommando muss in IM vom Avatar zu einem Benutzer gesendet werden (wird nicht von einem Objekt funktionieren). Der Viewer antwortet sofort mit seiner Version an den Sender der IM, aber weder die Nachricht noch die Antwort erscheint im IM Fenster des Benutzers, also ist es absolut unsichtbar.

Blacklist Handhabung

Die Blacklist (eingeführt in v2.8) ist eine Liste von RLV Kommandos die der Viewer ignorieren soll. Es ist jederzeit modifizierbar, aber ein Neustart ist notwendig um die Änderungen zu übernehmen. Wenn ein Kommando ausgegeben wird und Teil der Blacklist it, wird es einfach ignoriert. Bearbeiten der Blacklist wird nicht bestehende Restriktionen aufheben wenn sie einmal ausgeführt wurden. Ein Neustart ist notwendig. Wenn ein Kommando erhalten wird, wird eine positive Bestätigung an das Script gesendet ob das Kommando aktuell angenommen wurde oder nicht. Auf diese Weise würden Scripte, die auf Benachrichtigungen warten, nicht anhalten wenn sie eine Ablehnung nicht händeln können.

• Automatische Versionsnummer Prüfung, gefolgt von der Blacklist : "@versionnumbl=<channel_number>"

Eingeführt in v2.8 Lässt den Viewer automatisch die Versionsnummer der integrierten RLV API auf der Chat Kanal Nummer <channel_number> sagen, die das Script abhört (bitte beachte, das dies unterschiedlich ist zur Version vom Viewer, aber das Script sollte sich nicht drum kümmern), gefolgt von einem Komma (",") und dem Inhalt der Blacklist. Benutze immer eine positive Zahl. Bedenke, dass reguläre Viewer nie etwas antworten also entferne den Listener nach einem Timeout. Dieses Kommando ist weniger schwerfällig als @version gefolgt von @getblacklist, weil das Script nicht erst die Antwort verarbeiten muss, es erhält die Versionsnummer sofort und es muss keine zweite asynchrone Anfrage gesendet werden, wenn die erste beantwortet wurde.

Als Beispiel "@versionnumbl=2222" wird "2080000,sendim,recvim" antworten, wenn die Blacklist aktuell "sendim,recvim" ist. LSL erlaubt so einen String ohne Probleme als Zahl auszugeben. Es wird 2080000 zurückgeben und das erste Komma und alles danach entfernen.

• Den Inhalt der Blacklist mit einem Filter erhalten : "@getblacklist[:filter]=<channel_number>"

Eingeführt in v2.8 Lässt den Viewer automatisch mit dem Inhalt der Blacklist (wenn ein Filter gesetzt ist, dann sind nur die Kommandos die diesen Text enthalten Teil der Antwort) auf der Chat Kanal Nummer <channel_number> antworten auf die das Script hört. Benutze immer eine positive Zahl. Bedenke, dass reguläre Viewer nie etwas antworten also entferne den Listener nach einem Timeout.

• Manuelle Blacklist Prüfung : "@getblacklist"

Eingeführt in v2.8 Dieses Kommando muss in IM von einem Avatar an den Benutzer gesendet werden (funktioniert nicht von einem Objekt). Der Viewer antwortet automatisch mit dem Inhalt der Blacklist an den Sender der IM, aber weder die Nachricht noch die Antwort erscheint im IM Fenster des Benutzer, es ist also vollkommen unsichtbar.

Verschiedenes

• Start/stop Benachrichtigungen auf einem privaten Kanal : "@notify:<channel_number>[;word]=<rem/add>"

Eingeführt in v1.20, verbessert in v2.2 (und v1.24) Lässt den Viewer automatisch jede Restriktion auf dem genannten Kanal wiederholen, die er hinzufügt oder entfernt, oder nur die Restriktionen dessen Name das Wort enthält, das nach dem Semikolon (";") genannt ist. Der Antwort auf dem privaten Kanal <channel_number> ist ein Slash ("/") vorangestellt, um zu vermeiden, dass der Avatar Kommandos an andere Scripte sendet ohne dass er es weiss und wird gefolgt von einem Gleichheitszeichen ("=") und "n" oder "y" abhängig davon ob die Restriktion gesetzt oder aufgehoben wurde. Das "@clear" Kommando wird kein Gleichheitszeichen hinzufügen. Es gibt keine Möglichkeit zu wissen welches Objekt die Restriktion gesetzt oder aufgehoben hat, um die Weitergabe von zu vielen Informationen von anderen Scripten zu vermeiden. Es wiederholt auch nicht Einmal-Kommandos. Zum Beispiel bei "@notify:2222;detach=add" wird "/detach=n" wenn das Objekt gelockt ist und "/detach=y" wenn das Objekt entlockt ist auf dem Kanal 2222 gesendet auf das das Script hört.

Hinweis : Seit v2.2 (und v1.24) kannst Du auch Benachrichtigungen für Inventarangebote setzen. Wenn Dein Objekt ein Teil oder Ordner übergibt und der Avatar benutzt RLV v2.2 (and v1.24) oder höher wird automatisch eine der folgenden Antworten auf dem gesetzten Kanal gesendet :

- /accepted_in_rlv inv_offer <folder> : Der Ordner wurde akzeptiert und ist nun unter #RLV verfügbar
                                        (vergiss nicht, dass der Viewer es umbenennt und den Prefix "#RLV/" entfernt).

- /accepted_in_inv inv_offer <folder> : Der Ordner wurde akzeptiert ist aber nicht geteilt.

- /declined inv_offer <folder> : Der Ordner wurde abgelehnt und/oder der Benutzer hat "Block" gedrückt (früher "Mute").

Wobei <folder> der volle Pfad des Ordners oder des gegebenen Teils ist. Als Beispiel #RLV/~MyCuffs. Es ist eine Leerstelle vor "inv_offer" welches als Zeichen gewählt wurde um dort eine Benachrichtigung zu setzen. Wenn Du wissen willst ob der Ordner mit dem Namen #RLV/~MyCuffs im #RLV Ordner akzeptiert wurde, sende ein "@notify:2222;accepted_in_rlv inv_offer #RLV/~MyCuffs=add" Kommando. Wenn Du nur wissen willst ob der Avatar irgendwas empfangen hat sende ein einfaches "@notify:2222;inv_offer=add" Kommando.

Hinweis 2 : Seit v2.5 sendet der Viewer ebenso Benachrichtigungen wenn Outfits angezogen werden :

- /worn legally <layer> : Der Avatar hat gerade ein Stück Kleidung an dem indizierten Layer angezogen.

- /unworn legally <layer> : Der Avatar hat gerade ein Stück Kleidung von dem indizierten Layer ausgezogen.

- /attached legally <attach_point_name> : Der Avatar hat gerade ein Objekt am indizierten Attachmentpunkt angehängt.

- /attached illegally <attach_point_name> : Der Avatar hat gerade ein Objekt an dem indizierten Attachmentpunkt angehängt, aber es war nicht erlaubt
                                      (möglicherweise hat ein Script es automatisch angehängt) und es wird in wenigen Sekunden wieder abgenommen.

- /detached legally <attach_point_name> : Der Avatar hat gerade ein Objekt vom indizierten Attachmentpunkt abgenommen.

- /detached illegally <attach_point_name> : Der Avatar hat gerade ein Objekt vom indizierten Attachmentpunkt abgenommen, aber es war nicht erlaubt
                                            (möglicherweise hat ein Script es gekickt) und es wird in wenigen Sekunden wieder angehängt.

• Erlauben/verbieten Ausnahmen zuzulassen : "@permissive=<y/n>"

Eingeführt in v1.21 Wenn verboten werden alle Restriktionen in ihr "sicheres" Gegenstück (soweit vorhanden) gewandelt. Das bedeutet, dass eine Ausnahme von einer Restriktion ignoriert wird, wenn es nicht vom gleichen Objekt gesetzt wird wie die Restriktion. Die Benutzung von nicht-sicheren Restriktionen (die Originalen, wie @sendim, @recvim etc) ohne die Benutzung von @permissive erlaubt dem Avatar von Ausnahmen aus anderen Objekten zu profitieren.

Warnung : Die Benutzung dieses Kommandos (oder andere sichere Versionen des Original Kommandos) könnte stillschweigend Ausnhamen von anderen Objekten verwerfen (es ist sogar der Hauptzweck), daher können einige Produkte erscheinen, dass sie nicht arbeiten wenn diese Restriktion dies beeinflusst. Als Beispiel ein produkt, dass dem Avatar erlaubt einem bestimmtem Freund immer IMs zu senden, wird nicht in der Lage sein ein @semdim_secoder ein @permissive Kommando von einem anderem Objekt zu überwinden und sieht aus wie kaputt. Deshalb benutze es mit Vorsicht und weise den Benutzer darauf hin wie sicher Dein Produkt ist !

• Löschen aller Regeln die an ein Objekt gebunden sind : "@clear"

Eingeführt in v1.0a, aber funktioniert erst seit v1.04a Dieses Kommando löscht alle Restriktionen und Ausnahmen die an eine bestimmte UUID gebunden sind.

Warnung : wenn es standardmässig beim Abnehmen ausgeführt wird, kann es das automatische wieder anlegen verhindern wenn @defaultwear aktiv ist, weil @clear ebenso @detach=n aufhebt, deshalb denkt der Viewer dass das Teil, welches unabsichtlich durch eine default-wear-aktion abgelegt wurde, entlockt ist und wird es nicht wieder anhängen.

Mögliche Workarounds:

• hebe exakt nur die Restriktionen von Dir mit @clear=<pattern> auf
• verwende @clear nur beim Abnehmen wenn Du sicher bist, dass das Attachment nicht gelockt ist
• verwende nie @clear und warte auf den Viewer, dass die Restriktionen aufgehoben werden

• Löschen von ausgewählten Regeln von einem Objekt : "@clear=<string>"

Eingeführt in v1.0a, aber funktioniert erst seit v1.04a Dieses Kommando löscht alle Restriktionen und Ausnahmen von einer bestimmten UUID, das den Namen <string> enthält. Ein gutes Beispiel wäre "@clear=tp" was alle teleport Restriktionen und Ausnahmen von diesem Objekt aufhebt, während "@clear=tplure:" nur die Ausnahmen für die "teleport-by-friend" Restriktionen aufhebt

• Liste der Restriktionen erhalten, die beim Avatar aktuell gesetzt sind : @getstatus[:<part_of_rule>[;<custom_separator>]]=<channel>

Eingeführt in v1.10, leicht angepasst in v1.16 und v2.8 Lässt den Viewer automatisch die Liste der Regeln, die der Avatar gerade untersteht, auf der Chat Kanal Nummer die das Script abhört antworten. Dies wird nur die Restriktionen enthalten, die durch das Objekt gesetzt wurden, das das Kommando sendet. Benutze immer eine positive Zahl. Bedenke, dass reguläre Viewer nie etwas antworten also entferne den Listener nach einem Timeout. Die Antwort ist eine Liste mit Regeln getrennt mit Slashes ("/") oder anderen Unterteilern wenn definiert. Achtung: seit v1.16 ist dem String ein Slash vorgestellt. Dies stört nicht llParseString2List() Aufrufe jedoch llParseStringKeepNulls() Aufrufe!

Seit v2.8 wird, wenn <custom_separator> spezifiziert ist, es den Slash("/") mit dem bestimmten Trenner ersetzt. Achtung, der options Teil muss vorhanden sein, dafür muss ein Doppelpunkt (":") vor dem Semikolon (";") sein selbst wenn <part_of_rule> nicht vorhanden ist.

Dieses Kommando ist nützlich für Leute die Scripte schreiben, die mit anderen Scripten im gleichen Objekt kollidieren könnten (zum Beispiel : Drittanbieter Plugins). Konflikte passieren nicht verschiedenen Objekten, darum antwortet dieses Kommando nur mit den Restriktionen von dem Objekt wo es aufgerufen wird.

<part_of_rule> ist der Name der Regel oder ein Teil davon, nützlich wenn das Script nur von bestimmten Restriktionen wissen muss.

Beispiel : Wenn der Avatar unter tploc, tplure, tplm and sittp ist, ist hier was das Script kriegen würde :
@getstatus=2222  =>  /tploc/tplure/tplm/sittp
@getstatus:sittp=2222  =>  /sittp
@getstatus:tpl=2222  =>  /tploc/tplure/tplm  (weil "tpl" ist Teil von "tploc", "tplure" und "tplm" aber nicht "sittp")
@getstatus:tpl;#=2222  =>  #tploc#tplure#tplm  (weil "tpl" ist Teil von "tploc", "tplure" und "tplm" aber nicht "sittp" und der gesetzte Trenner ist "#")
@getstatus:;#=2222  =>  #tploc#tplure#tplm#sittp  (weil der gesetzte Trenner "#" ist)
@getstatus:;=2222  =>  /tploc/tplure/tplm/sittp  (weil der gesetzte Trenner leer ist so ist es standardmässig "/")

• Liste von allen Restriktionen erhalten, die beim Avatar aktuell gesetzt sind : @getstatusall[:<part_of_rule>[;<custom_separator>]]=<channel>

Eingeführt in v1.15, leicht angepasst in v1.16 und v2.8 Lässt den Viewer automatisch die Liste der Regeln, die der Avatar gerade untersteht, auf der Chat Kanal Nummer die das Script abhört antworte. Im Gegensatz zu @getstatus für alle Objekte unabhängig von deren UUID. Benutze immer eine positive Zahl. Bedenke, dass reguläre Viewer nie etwas antworten also entferne den Listener nach einem Timeout. Die Antwort ist eine Liste mit Regeln getrennt mit Slashes ("/") oder anderen Unterteilern wenn definiert. Achtung: seit v1.16 ist dem String ein Slash vorgestellt. Dies stört nicht llParseString2List() Aufrufe jedoch llParseStringKeepNulls() Aufrufe!

Seit v2.8 wird, wenn <custom_separator> spezifiziert ist, es den Slash("/") mit dem bestimmten Trenner ersetzt. Achtung, der options Teil muss vorhanden sein, dafür muss ein Doppelpunkt (":") vor dem Semikolon (";") sein selbst wenn <part_of_rule> nicht vorhanden ist.

Bewegung

• Erlauben/verbieten zu fliegen : @fly=<y/n>

Eingeführt in v1.12.2 Wenn unterbunden, dann ist der Benutzer nicht in der Lage zu fliegen.

• Erlauben/verbieten rennen durch doppel-drücken einer Pfeiltaste : @temprun=<y/n>

Eingeführt in v2.7 Wenn unterbunden, dann ist der Benutzer nicht in der Lage durch doppel-drücken der Pfeiltaste zu rennen. Wenn Du den User insgesamt am Rennen hindern willst musst Du auch @alwaysrun benutzen

• Erlauben/verbieten von immer rennen : @alwaysrun=<y/n>

Eingeführt in v2.7 Wenn unterbunden, dann ist der Benutzer nicht in der Lage durch drücken von STRG+R in den Rennen Modus zu wechselnWhen prevented, the user is unable to switch running mode on by pressing Ctrl-R. Wenn Du den User insgesamt am Rennen hindern willst musst Du auch @temprun benutzen. Dieses Kommando ist nützlich wenn Du den Benutzer zwingen willst erst zu beschleunigen anstatt ständig zu rennen. Zum Beispiel während Kampf oder Sportspielen.

• Erzwingen den Avatar in eine bestimmte Richtung zu drehen : @setrot:<angle_in_radians>=force

Eingeführt in v1.17 Zwingt den Avatar in eine Richtung um einen Winkel im Bogenmaß aus dem Norden gesetzt zu drehen. Beachte, dass dieses Kommando nicht sehr präzise ist, noch dass es irgendwas tun wird, wenn die Aktion versucht den Avatar um weniger als 10° zu drehen (Versuchswert, es wurde irgendwo erwähnt, dass 6° das Minimale ist). Mit anderen Worten macht es Sinn erst mit llGetRot() zu prüfen der den Avatar zweimal zu drehen. Erst 180° plus dem gewünschten Winkel und dann den Winkel den wir brauchen. Es ist nicht sehr elegant aber es funktiniert.

• Ändern der Höhe vom Avatar : @adjustheight:<distance_pelvis_to_foot_in_meters>;<factor>[;delta_in_meters]=force

Eingeführt in v2.5 Zwingt den Avatar seine "Z-Offset" zu ändern, mit anderen Worten dessen Flughöhe. Dieser Wert kann mittlerweile durch eine Debug Einstellung in den meisten Third-Party Viewern geändert werden. Dieses Kommando erlaubt den automatischen Wechsel passend zur Animation.

Anstatt es hier komplett zu erklären, gehe zu diesem Link für weitere Info : [1]

Chat, Emotes und Instant Messages

Chat

• Erlauben/verbieten Chat Nachrichten zu senden : "@sendchat=<y/n>"

Eingeführt in v1.0b Wenn unterbunden, wird alles verworfen was auf Kanal 0 geschrieben wird. Jedoch werden Emotes und Nachrichten mit einem Slash ("/") am Anfang durchgelassen aber gekürzt auf Strings von 30 und 15 Buchstaben (ändert sich wahrscheinlich später). Nachrichten mit speziellen Zeichen wie ()"-*=_^ sind verboten und werden verworfen. Wenn ein Punkt (".") vorhanden ist wird der Rest der Nachricht verworfen.

• Erlauben/verbieten zu rufen : "@chatshout=<y/n>"

Eingeführt in v1.15 Wenn unterbunden wird der Avatar normal chatten slebst wenn der Benutzer versucht zu rufen. Dies verändert die Nachricht in keiner Weise nur die Reichweite.

• Erlauben/verbieten zu chatten in normaler Lautstärke : "@chatnormal=<y/n>"

Eingeführt in v1.15 Wenn unterbunden wird der Avatar flüstern selbst wenn der Benutzer versucht zu rufen oder normal zu chatten. Dies verändert die Nachricht in keiner Weise nur die Reichweite.

• Erlauben/verbieten zu flüstern : "@chatwhisper=<y/n>"

Eingeführt in v1.15 Wenn unterbunden wird der Avatar normal chatten selbst wenn der Benutzer versucht zu flüstern. Dies verändert die Nachricht in keiner Weise nur die Reichweite.

• Umleiten von öffentlichen Chat auf einen privaten Kanal : "@redirchat:<channel_number>=<rem/add>"

Eingeführt in v1.16 Wenn aktiv leitet diese Restriktion alles was der Benutzer auf dem öffentlichen Kanal ("/0") sagt auf den privaten Kanal um, der im Optionsfeld angegeben ist. Wenn mehrere Umleitungen gesetzt sind wird die Chat Nachricht an jeden Kanal geleitet. Es gilt nicht für Emotes und es wird keine Animationen starten (tippen starten, tippen stoppen, nicken) beim reden. Diese Restriktion ersetzt nicht @sendchannel. HINWEIS: Seit RLV v1.22.1 / RLVa 1.1.0, gab es einen Bug, wo qredirchat ebenso Emotes auf Kanal 0 gekürzt hat. Ein zusätzlicher @emote=add behebt diesen Effekt. Dieser Bug wirde im Cool SL Viewer ab v1.22g (allerdings hatte Marine's v1.23 immer noch den Bug) und RLV 2.0 gefixt (man kann sicher annehmen dass es in allen Viewern ab v1.24 und v2.0 behoben wurde).