Änderungen für LSL HTTP, Testregionen im Beta Grid

Quelle: ClipartMax

Gestern haben sowohl Oz Linden im LSL Scripting Forum als auch etwas später Maestro Linden im Second Life Server Forum auf Änderungen hingewiesen, die mit der Migration von Second Life in die Amazon Cloud bei den Skriptfunktionen stattfinden werden.

Zusätzlich diskutiert im erstgenannten Thread auch noch Monty Linden mit. Wenn diese drei Linden Lab Koryphäen sich gemeinsam um ein Thema kümmern, dann ist das schon ziemlich wichtig für Second Life. Zumindest für alle, die mit LSL arbeiten und Produkte anbieten, die Skripte mit den entsprechenden Funktionen enthalten.

Die ausführliche Erklärung zu den Änderungen wurde von Oz hier gegeben. Ich habe heute keine Lust, das komplett zu übersetzen. Wer mit Skripten arbeitet, wird sicher so viel Englisch können, um die Erklärung von Oz zu verstehen. Ich fasse den Inhalt nur einigermaßen verständlich zusammen.

Allgemein

Im Zusammenhang mit HTTP gibt es innerhalb der Linden Script Language (LSL) eine ganze Reihe von Funktionen. Diese werden dazu genutzt, Daten zwischen SL und einem Server im Internet auszutauschen. Oder auch, um mit anderen Skripten in Second Life zu kommunizieren. Die angesprochenen Änderungen betreffen nur den Datenaustausch mit externen Diensten. Oz bittet alle, die solche Skripte verwenden, die Funktionen auf den weiter unten angegebenen Regionen im Beta Grid zu testen und Probleme in der JIRA zu melden.

Betroffen sind die folgenden Funktionen:

llHTTPRequest - Ausgehende HTTP Anfrage

Die Schnittstelle zu dieser Methode ändert sich nicht (abgesehen von einer zusätzlichen Fehlerprüfung), aber einige Verhaltensweisen im Netzwerk ändern sich. HTTP-Anfragen von LSL an externe Systeme wurden bisher über einen HTTP-Proxy weitergeleitet, der jedem Simulator-Host zugeordnet war. In Zukunft befindet sich der Proxy in einem Pool separater Server, wie hier gezeigt:

Das bedeutet:

• Die IP-Adresse des HTTP-Clients vom HTTP-Server stimmt nicht mit der IP-Adresse des Simulators überein, von dem die Anfrage gesendet wurde. Der Hostname, der durch das Auslesen der Client-/Proxy-Adresse zurückgegeben wird, ist nicht der Simulator-Host.
• Einige Timeout-Verhaltensweisen für Server, die nicht schnell genug reagieren, können sich geringfügig ändern.
• Der Aufbau einiger Fehlerantworten der Proxys kann sich ändern, einschließlich des Inhaltstyps.
• Unterschiedliche Anfragen von einem bestimmten Simulator können über verschiedene Proxys geleitet werden und Anfragen von verschiedenen Simulatoren können über denselben Proxy (möglicherweise sogar über dieselbe TCP-Verbindung) geleitet werden.
• Bei Skripten, bei denen mehr als eine HTTP-Anfrage zeitlich überlappt, können sich Änderungen in der Reihenfolge ergeben, in der diese Anfragen beim Server eingehen und/oder in der Reihenfolge, in der die Antworten zurückgegeben werden.

Die IP-Adressen für Simulatoren werden in unterschiedlichen Bereichen liegen und sind nicht vorhersehbar. Deshalb sollten in LSL-Skripten keine Prüfungen mehr enthalten sein, ob die IP-Adresse von einem Simulator aus einem der Linden Lab Rechenzentren kommt. Die Kommunikation zwischen zwei Skripten in SL ist davon nicht betroffen.

Der llHTTPRequest-Parameter HTTP_CUSTOM_HEADER darf nicht zum Festlegen von Werten für die Header "Connection" oder "Host" verwendet werden. Es wird eine Prüfung hinzugefügt, damit jeder Aufruf, der dies versucht, einen Fehler auslöst und die Anforderung abbricht (derzeit sind diese Headernamen zulässig, aber die Werte werden normalerweise nicht verwendet oder an den Remote-Server gesendet, was irreführend ist).

llRequestURL oder llRequestSecureURL

Hier weist Oz noch einmal darauf hin, dass bereits im Juni 2020 die Empfehlung gegeben wurde, keine Prüfung des Domainnamens in einer URL durchzuführen. Eine Suche nach Hostnamen für eine Simulator-IP-Adresse gibt nicht denselben Namen zurück, wie eine der beiden o.a. Methoden. Das heißt, wenn man nach der IP-Adresse für einen Simulatornamen sucht, wird die richtige Adresse zurückgegeben. Wenn man jedoch nach dem Namen für diese Adresse sucht, wird ein anderer Name zurückgegeben. Diese Art von Asymmetrie wird es zukünftig für viele SL-Dienste in der Cloud geben.

Hier die Regionen, auf denen die neuen LSL-Funktionen im Beta Grid bereits getestet werden können (Links nur anklicken, wenn man schon im Beta Grid eingeloggt ist):

• Cloud Sandbox 1
• Cloud Sandbox 2
• Cloud Sandbox 3
• Cloud Sandbox 4
• Morris

Wichtig ist vor allem, dass Händler, die Produkte anbieten, welche mit dem Internet Daten austauschen, ihre Skripte überprüfen und gegebenenfalls anpassen. Zum Beispiel Rental-Boxen, Vendoren, Breedable-Informationen oder Anzeigetafeln, die ihren Inhalt von einer Webseite auslesen.

Links:

• [SL Forum] - LSL HTTP Changes Coming
• [SL Wiki] - Übersicht zu LSL HTTP

Testregionen für LSL-Unterstützung des Materialsystems

Quelle: SL Wiki, Jeremy Linden

Das ging schnell. Am Montag hatte ich noch darüber geschrieben, dass auf den inworld Meetings in letzter Zeit oft gefragt wurde, ob und wann man das neue Materialsystem in SL auch über Skripte steuern könne. Simon und Maestro Linden erwähnten, dass sie sich damit aktuell beschäftigen würden. Beim Server Beta Meeting am 29. Mai (also gestern) wurde jetzt bekanntgegeben, dass ab sofort für die LSL-Unterstützung von Materialtexturen eine Testumgebung im Beta Grid (ADITI) zur Verfügung steht.

Simon Linden hat eine ausführliche Beschreibung der neuen LSL-Funktionen für das Materialsystem auf der Wiki-Seite der Server Beta User Gruppe hinterlegt. Das ist eine lange Liste mit LSL-typischen Fachausdrücken, die ich hier jetzt nicht übersetzen werde. Jeder, der sich mit LSL-Skripten auskennt, wird auch den Originaltext verstehen. Im Grunde kann man mit den Funktionen nun die Normal- und Specular-Map des Materialsystems genauso per Skript beeinflussen, wie das schon vorher mit den üblichen Texturen ging (Diffuse-Map).

Im Beta Grid wurden zwei Regionen mit dem neuen Servercode für Materialskripting ausgestattet. Die Regionen heißen "roller-test102" und "roller-test103". Hier sind die direkten Teleports dorthin. Die sollte man aber nur aufrufen, wenn man mit dem Viewer schon im Beta Grid eingeloggt ist.

Beta Grid SLURLs:

• Teleport zu roller-test102
• Teleport zu roller-test103

Der Servercode auf den Testregionen ist ein erster Entwurf, der selbst von Linden Lab noch getestet wird. Es können also durchaus noch Fehler auftreten. Einer wird auch in der oben genannten Beschreibung aufgeführt (BUG-6187). Den Fehler vermeiden kann man, indem man bei jeder Primfläche, die eine neue Textur ohne Alphakanal erhalten soll, den Parameter "PRIM_ALPHA_MODE_NONE" mit angibt. Ebenfalls sollte man beachten, dass es zur Zeit noch keine Drosselung für exzessive Nutzung der neuen Funktionen gibt. Das bedeutet, man kann damit durchaus auch den Simulator in die Knie zwingen, wenn man Griefer-Techniken anwendet. Allerdings ist das im Beta Grid nicht so tragisch. Später soll natürlich eine Drosselung eingebaut werden.

Simon Linden erwähnt, dass jede Rückmeldung über Testergebnisse willkommen ist. Wer Fehler findet, kann diese in der JIRA einreichen. Es werden bis zur Einführung im SL Main Grid sicher noch Änderungen, Fixes und Erweiterungen in den Code einfließen.

Hier noch einmal der Link zur Wiki-Seite mir den Funktionsbeschreibungen:

• [SL Wiki] - Server Beta User Group / Beschreibung der LSL-Funktionen für Materials

Quelle: [Nalates Urriah] - Scripting Second Life Materials Testing

Mobiles Teleport-Portalsystem auf RLV-Basis

Gestern ist auf New World Notes ein Artikel über ein geskriptetes Portalsystem erschienen, das ich so bisher noch nirgends in Second Life gesehen habe. Im Artikel und in den Kommentaren wird zwar gesagt, dass dies jetzt nicht das erste Gadget dieser Art sei, es würde aber am nächsten an eine Umsetzung des Computerspiels Portal herankommen. Bei diesem Spiel geht es um das Prinzip, mit einer Portalkanone Teleport-Türen zu erzeugen und hindurchzugehen, um an anderen Orten zu erscheinen, die man ohne Teleport sonst nicht erreicht hätte.

Erstellt wurde die SL-Version von Adeon Writer, dessen Name ich vor allem aus vielen Beiträgen im LL-Forum kenne. Das Besondere an diesem System für SL ist, dass man mit der Kanone an beliebiger Stelle ein Wurmloch erzeugen kann und direkt teleportiert wird, wenn man hineinläuft. Diese Wurmlöcher funktionieren nicht nur mit Avataren, sondern auch mit Objekten, wie man im zweiten Video unten sehen kann.

Möglich ist sowas aktuell nur mit den speziellen Funktionen eines RLV-fähigen Viewers. Dort ist bereits im Viewercode die Möglichkeit eines Teleports bei Kontakt mit einem Objekt eingebaut. Das bedeutet aber auch, dass man diese Portalkanone in einem LL-Viewer nicht verwenden könnte. An andere Personen weitergeben will Adeon dieses Spielzeug erstmal nicht, da er und sein Entwicklungspartner Snow Bristol unsicher sind, ob sie evtl. ein Copyright der Firma Valve verletzen. Das ist die Softwarefirma hinter dem Computerspiel Portal 2. Sollten von Valve aber keine Einwände kommen, wollen die Beiden die Portalkanone vielleicht sogar als Freebie herausgeben, wie Adeon in den Kommentaren des Artikels anmerkt.

Das erste Video zeigt den Einsatz der Kanone, die mit Hilfe der relativ neuen Skriptfunktion llCastRay das Rezzen der Portale ermöglicht.

Im zweiten Video kann man sehen, wie ein Objekt zwischen zwei Portalen hin und herspringt.

Quelle: Adeon Writer Builds Working Portal Gun in Second Life!

Sollte Linden Lab demnächst mal, wie angekündigt, ihre Experience Tools von Linden Realms einführen, dann würde ein ähnliches Gadget auch ohne RLV Funktionen in jedem Viewer verwendbar sein. Soweit ich gelesen habe, könnte bereits der dritte Teil von Dranopia diese neuen LL-Tools verwenden.

Pathfinding Beta im Main Grid gestartet

Pathfinding im Beta Grid

Vor zwei Tagen haben Oskar und Maestro Linden eine neue Seite in der LL-Wiki angelegt. Sie kündigt den Start der offenen Beta für Wegfindungsfunktionen (Pathfinding) im Main Grid von Second Life an. Dazu wurden eine Reihe von Regionen vorbereitet, deren komplette Liste auf der Wiki-Seite zu finden ist.

Im Gegensatz zur Beschreibung in der Wiki, ist es jedoch für alle Regionen notwendig, dass man Mitglied in der Gruppe "Second Life Beta" ist und diese aktiviert hat. Desweiteren sind die meisten Regionen der Liste (die ersten 10) nur Premium-Mitgliedern vorbehalten und sie befinden sich zwischen dem Linden Homes Kontinent und den neuen Amazonas Wildnis Regionen. Die letzten fünf Sims der Liste befinden sich jedoch auf dem Mainland und können von allen genutzt werden.

Hier die SLURLs zu den fünf frei zugänglichen Beta-Regionen:
>> Teleport nach Fuchsia
>> Teleport nach Pepin
>> Teleport nach Lime
>> Teleport nach Plum
>> Teleport nach Harvey

Damit man die Pathfinding LSL-Funktionen und die neuen Steuerungs- und Überwachungsfenster des Viewers nutzen kann, muss man entweder den Pathfinding Projekt Viewer, oder den aktuellen Bleeding-Edge Build verwenden.
>> Download Pathfinding Projekt Viewer
>> Download Pathfinding Bleeding Edge

Der Pathfinding Projekt Viewer entspricht dem Beta Viewer 3.3.1, den ich bereits hier im Blog vorgestellt habe. Dort ist auch ein Screenshot mit den neuen Viewer-Fenstern zu sehen.
>> Second Life Beta Viewer 3.3.1 veröffentlicht

Wer beim Testen Fehler entdeckt oder Vorschläge für eine Erweiterung hat, soll sein Anliegen in der Jira im Bereich "Pathbug" einreichen (in Englisch).
>> Jira: Pathfinding External Bugs

Besitzer einer Region können diese ebenfalls für die Pathfinding Funktionen freischalten lassen. Dazu eine Email an pathfinding-beta@lindenlab.com senden und Name von Avatar und Region hinzufügen. Abschicken sollte man es von dem Email-Konto, das auch beim SL-Account hinterlegt ist.

Die freie Testregion "Harvey" auf dem Mainland

Ich habe das gestern kurz angetestet. Der Beitritt zur Beta-Gruppe ist kostenlos und dauert nur ein paar Sekunden. Ich habe nur die Skripte getestet, die ich auch schon auf dem Beta-Grid ausprobiert hatte. Zuerst wurden sie nicht akzeptiert. Die maximale Geschwindigkeit von Wegfindungsobjekten wurde für das Main Grid nämlich auf 20m/s reduziert. Nachdem ich dies in meinen Skripten angepasst hatte, ging es dann. Und es macht wesentlich mehr Spaß, auf den bebauten Regionen des Main Grid einen Würfel zu verfolgen, als im doch sehr kargen Beta Grid.

Auch im Main Grid flüchtet der Würfel vor mir, aber nur noch mit max. 20m/s :-)

Die neuen Fenster im Viewer habe ich noch nicht genauer angeschaut. Im Gegensatz zu normalen Regionen, sind die Menüs und Eingabefelder der Fenster auf den Beta Regionen aber aktiv und können genutzt werden. Wer auch mal im Main Grid ein paar Pathfinding Skripte testen will, der findet in meinem Testbericht vom Beta Grid zwei einfache Beispiele und ein Video, wie das dann aussieht. Die max. erlaubte Geschwindigkeit habe ich in diesen Skripten bereits angepasst:
>> Pathfinding im Beta Grid

Weiter Links (englisch):
>> Pathfinding Tools in the Second Life Viewer
>> Pathfinding LSL functions
>> Pathfinding/Alpha release notes

Quelle: Pathfinding Public Beta

Pathfinding im Beta Grid

Am letzten Donnerstag hat Linden Lab in seinem Blog den Beta Start für die neuen Wegfindungsfunktionen (englisch "Pathfinding") bekannt gegeben. Dazu gab es ein Video und einen Link zur neuen Wiki-Seite, auf der die bis jetzt zur Verfügung stehenden Funktionen zusammengefasst sind.

So richtig habe ich mich damit noch nicht beschäftigt, aber ich war am Montag mal kurz auf den vier Test-Regionen im Beta Grid, die diese neuen Funktionen bereits unterstützen. Dort wuseln einige Prims durch die Gegend und vor allem die Schachbrett-Sandbox ist ganz witzig und hat den Charakter eines echten Testgeländes.

Beta Sandbox "PathTest4"

Gestern habe ich dann mal 2 von den 11 verschiedenen Skriptfunktionen ausprobiert. Einmal llPursue, was ein Objekt dazu bringt, einem anderen Objekt oder Avatar zu folgen. Und zum anderen llEvade, was genau das Gegenteil bewirkt, nämlich vor einem Objekt oder Avatar davonlaufen.

Vor allem die "Flucht"-Funktion verleiht einem stinknormalen Prim den Anschein echter Intelligenz. Da das Ganze auf Fotos nicht richtig rüberkommt, habe ich ein kleines Video erstellt. Darin sieht man ganz gut, wie kinderleicht es ist, die Grundfunktionen des Pathfinding einfach in ein Skriptfenster zu kopieren und es selbst mal zu testen. Unter dem Video habe ich die beiden kleinen Skripte eingefügt, die ich verwendet habe. Wie man sieht, wird für diese Funktion wirklich wenig Code benötigt. Und bitte keine Kommentare zur Kameraführung. Das war eine 10-Minuten Spontanaktion (mit einer Stunde Nacharbeit im Movie Maker). :o)

Maddy und die Pfadfinder:

>> Hier klicken für HD-Auflösung im neuem Fenster

Für alle, denen es im Video zu schnell geht, hier die Schritte als Kurzliste:

• Voraussetzung ist ein Login im Beta Grid (in Gridliste unter "Aditi" geführt)
• Würfel (oder anderes Prim) rezzen
• Unter "Eigenschaften" die "Art der physischen Form" auf "Konvexe Hülle" umstellen
• Unter "Inhalt" ein neues Skript erstellen
• Skript öffnen, vorgegebenen Code löschen und Beispielskript einfügen (siehe unten)
• Skript speichern
• Optional: Eindeutigen Namen für das Prim vergeben
• Optional: Textur und Farbe des Prims ändern, weil Plywood ist langweilig ;-)
• Baufenster schließen
• Einmal das bearbeitete Prim anklicken

Mit diesem Skript lässt sich ein Objekt dazu bringen, dem Avatar zu folgen, der es anklickt.

default
{
    state_entry()
    {
        llCreateCharacter([CHARACTER_DESIRED_SPEED, 20.0]);
    }
 
    touch_start(integer total_number)
    {
        llPursue(llDetectedKey(0), [PURSUIT_OFFSET, 
                 <-2.0, 0.0, 0.0>, PURSUIT_FUZZ_FACTOR, 0.2]);
    }
}

Quelle: LL Wiki - llPursue

Mit diesem Skript lässt sich ein Objekt dazu bringen, sich vor dem Avatar zu verstecken, der es anklickt.

default
{
    state_entry()
    {
        llCreateCharacter([CHARACTER_DESIRED_SPEED, 20.0]);
    }
 
    touch_start(integer total_number)
    {
        llEvade(llDetectedKey(0), []);
    }
}

Quelle: LL Wiki - llEvade

Das sind die vier Testregionen im Beta Grid (Link erst anklicken, wenn man mit dem Viewer bereits eingeloggt ist):

>> Teleport zur Sandbox PathTest1
>> Teleport zur Sandbox PathTest2
>> Teleport zur Sandbox PathTest3
>> Teleport zur Sandbox PathTest4

Die Sandbox mit dem Schachbrettmuster ist die PathTest4. Ich werde mir, wenn ich Zeit habe, auch noch ein paar der anderen Pathfinding Funktionen ansehen. Interessant wird es, wenn man dann mit etwas Code die verschiedenen Möglichkeiten kombiniert. Dann könnte man, je nach Koordinate innerhalb einer Region, das selbe Objekt entweder angreifen oder davonlaufen lassen. Oder ein patrouillierendes Objekt ergreift bei Annäherung zuerst die Flucht, um dann überraschend zurückzukehren.

Es bleibt auf jeden Fall interessant, was intelligente Ersteller damit alles machen werden.

Weitere Links:
>> LL-Wiki: Pathfinding in Second Life - (englisch)
>> LL-Wiki: Pathfinding Alpha - (generelle Information / englisch)
>> Blogpost von LL zur Einführung von Pathfinding

Neues zu den angekündigten Linden Realms Funktionen

Linden Realms Portal Region

Nalates Urriah hat am Montag in ihrem Blog ein kleines Update zu den von Linden Lab geplanten Funktionen für inworld Spiele gepostet. Die Informationen stammen aus Linden Labs Scripting User Group, die sich regelmäßig in SL trifft, um Neuigkeiten zu besprechen. Am Montag kam zu diesem Treffen auch Tiggs Linden und hat erste Details zu den sogenannten Linden Realms Tools verraten. Charlar Linden wies jedoch darauf hin, dass keine der Infos schon in Stein gemeißelt sind und Dinge sich noch ändern könnten.

Zunächst wird es zwei neue LSL-Funktionen geben, mit denen der Auto-Teleport und das automatisch angelegte HUD aus dem Linden Realms Spiel allen zugänglich gemacht wird. Die beiden LSL-Aufrufe für diese Funktionen heißen llTeleportAgent() und llAttachToAvatarTemp(). Hinter dem Link zum ersten Funktionsaufruf verbirgt sich bereits die zugehörige LL-Wiki Seite, auf der die Funktion beschrieben ist. Für den Auto-Teleport soll es in der eingeführten Version auch möglich sein zu bestimmen, in welche Richtung ein Avatar nach dem Teleport schaut. Für Spiele, aber auch für allgemeine Besichtigungs-TPs, eine sehr wichtige Option.

Auto-HUD (oben im Bild)

Die Funktion llAttachToAvatarTemp() entspricht im Grunde der heute schon vorhandenen Funktion llAttachToAvatar(), mit den zwei Unterschieden, dass das angehängte Objekt nicht im Inventar des Avatars sein muss und dass man den Besitz (Owner) des angehängten Objektes temporär auf den nutzenden Avatar übertragen kann. Das Entfernen eines so angelegten Objektes kann entweder per Skript ausgelöst werden, oder durch Teleport aus der Region heraus, oder durch Ausloggen des Nutzers. Gerade bei zweiter Methode ist Nalates der Meinung, dass diese einiges Potential für Produktpräsentationen hätte. So könnten zum Beispiel Demo-Haare wie die original Haare aussehen, sich aber selbst löschen, sobald der Kunde den Sim verlässt.

Landschaft aus Linden Realms

Eine weitere Funktion, die in Planung ist, nennt sich "Experience Permissions". Damit soll es Erstellern möglich sein, Skript-Dialoge und -Abfragen, die normal eine Eingabe des Nutzers erfordern, zu überschreiben und manuelle Aktionen überflüssig zu machen. Dies soll in erster Linie die Immersion des Anwenders erhöhen und Prozesse im (Spiel-)Ablauf vereinfachen. Ein genaues Regelwerk wurde hier jedoch noch nicht definiert.

Im Augenblick sucht Linden Lab schon Beta Tester für die Linden Realms Tools. Einzelheiten dazu wurden im letzten User Group Meeting noch nicht besprochen. Außerdem erwähnte Tiggs Linden noch eine vierte Funktion, die bald erscheinen wird, sagte aber nicht, um was es geht. Somit kann man schonmal etwas zu spekulieren anfangen. (Ich tippe ja auf eine erste kleine KI-Funktion^^).

Quelle: Nalates Urriah: #SL Linden Realm Tools

The Avatar Machine

Gestern habe ich in meinem Wochenrückblick am Ende ein Video gepostet, in dem die Avatar Maschine von Pallina60 Loon zu sehen ist. Heute habe ich dieses Gebilde mal besucht. Leider hatte ich nicht gemerkt, dass ich noch die Benutzeroberfläche für Fotos eingeblendet hatte. Da das Thema aber eh technischer Natur ist, habe ich es so gelassen.

The Avatar Machine

Gebaut wurde diese Maschine, um die neuen Möglichkeiten der LSL-Funktion llSetKeyframedMotion zu demonstrieren. Die Funktion kann Primobjekte auf vielfältige Art in Bewegung versetzen. Und in Zusammenhang mit der Primeigenschaft "Konvexe Hülle", werden Avatare auf solchen Objekten einfach mitgenommen, ganz ohne Poseball (oder Sitzen) auf dem Objekt.

Nach dem Teleport steht man direkt vor dem Eingang der Maschine. Geht man durch den rechten Gang, kommt man zu einer orangenen Scheibe auf dem Boden. Von dort dann einfach über den blauen Pfeil laufen und los gehts.

Hier beginnt die Avatar-Fahrt

Bei der Spirale zu Beginn, sollte man mit der rechten Pfeiltaste die Kamera hinter seinem Avatar halten. Auch wenn es so aussieht, dass man immer nur im Kreis bewegt wird, ist dem nicht so.

In der Spirale

Bis auf eine Stelle in der Maschine, ist es nicht notwendig, mit dem Avatar zu laufen. Man wird automatisch von einer Plattform an die nächste Übergeben. Der einzige Punkt, an dem man ein paar Schritte nach vorne gehen muss, ist vor den Walzen im nächsten Bild.

Hier auf die erste Walze laufen

Am Ende des Durchlaufs landet man wieder auf der orangefarbenen Scheibe, bei der man gestartet ist.

Insgesamt fand ich das ziemlich interessant, wie mein Avatar mittels Primphysik weiterbewegt wurde. Ich hoffe, dass diese Möglichkeiten auch bald für andere Zwecke eingesetzt werden. Denkbar wären Laufbänder durch Ausstellungen, die man jederzeit verlassen und wieder betreten kann. Oder drehende Plattformen bei Modeausstellungen, auf denen die Modells am Publikum vorbei bewegt werden. Selbst ein Paternoster ließe sich in einem mehrstöckigen Haus verwirklichen.

Transferwürfel über der Maschine

Ach ja, wer die Maschine angesehen hat, sollte vor dem Eingang auch den Teleport zum Boden runter nehmen. Der Sim LOL ist ein Versuchsfeld witziger Ideen. Unter anderem experimentiert hier auch Opensource Obscure, ein alter Veteran beim Ausprobieren der Möglichkeiten von SL.

>> Teleport zur Avatar Machine

Link:

• Mein Blogpost zur Funktion llSetKeyframedMotion

llSetKeyframedMotion: Neue LSL-Funktion mit vielen Möglichkeiten

Am 15. November wurde die neue LSL-Funktion llSetKeyframedMotion im gesamten Main Grid von Second Life eingeführt. Dieser Skriptaufruf ermöglicht es, in einer einzigen Skriptzeile ein Objekt so zu bewegen, dass es mehrere Richtungsänderungen durchführt. Aber auch einfache Punkt-zu-Punkt Bewegungen sind damit leicht machbar. Die Bewegungen werden dabei sehr weich berechnet, ganz im Gegensatz zum alten llSetPos und llSetRot.

Als Option können dem llSetKeyframedMotion-Aufruf noch einige Steuerbefehle angehängt werden, wie etwa das Ausführen als Schleife (KFM_LOOP), der Vor- und Zurück-Modus (KFM_PING_PONG), oder in umgekehrter Abfolge (KFM_REVERSE). Die Wegstrecken innerhalb des gleichen Aufrufs, sind auch über Regionsgrenzen hinweg möglich. Das ist zum Beispiel wichtig für Tour-Vehikel, die mehrere Regionen in ihrer Route haben.

Da das hier doch etwas länger wird, geht es weiter nach dem Link: