Artikelformat

PHP und SecondLife

Das ehemals hochgelobte virtuelle Leben in Form von Second Life ™ ist in der Presse inzwischen eher untergegangen, aber genau wie Asterix und Obelix gibt es immer noch eine Menge Leute, die diese Welt nutzen. Viele Neulinge nehmen am Leben im Second Life passiv Teil. Dies kann man aber auch sehr aktiv gestalten und im Gegensatz zu einem 3D-Spiel (wie bspw. einem MMORPG) kann man neue Dinge selbst erstellen. Diese Dinge möchte man manchmal aus der abgeschirmten Welt von SL ausbrechen lassen. Kommunikation über die Grenzen von Second Life heraus ist daher heute das Thema.

Als Beispiel möchten wir die Systemlast eines Servers im SecondLife Chat-Fenster ausgegeben. Hierfür benötigt man auf Serverseite ein kleines PHP Script, das die Systemlast vorformatiert zurückliefert. Dieser Code sieht bspw so aus:

1
2
3
4
5
6
function myNF($key) {
	return number_format($key,2);
}
 
$load = sys_getloadavg();
echo join('|',array_map("myNF",$load));

Es wird die sys_getloadavg-Funktion benutzt, um an die Systemlast zu gelangen. Diese wird noch ordentlich formatiert und in einem String zusammengefasst, wobei das „Pipe“-Symbol als Separator dient. Auf der anderen Seite möchten wir die einzelnen Strings ja auch wieder trennen und dabei noch etwas lernen; namlich wie man ein explode in LSL realisiert.

Im SecondLife benötigt man neben einem Benutzerkonto auch einen Platz, auf dem man Objekte generieren kann. Die Rechteverwaltung lässt dies nämlich nicht überall zu. Am einfachsten nutzt man für solche Tests die dafür vorgesehenen Sandboxen, die man über die Suche von SL sehr leicht finden kann.

Man generiert sich hier nun ein 3D-Objekt, mit dem man anschließen das eigentliche Skript verknüpft. Das Skript, das die Anfrage an den Server stellt, ist in LSL geschrieben. LSL steht für Linden Scripting Language und ist die Skriptsprache, die innerhalb von SL dem Benutzer zugänglich gemacht wird.

Im Content des 3D-Objekts legt man nun ein neues Skript an und ersetzt den Beispielquelltext durch den folgenden Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
key    httpd_id;
 
default 
{
    on_rez(integer param)
    {
        llResetScript();
    }
 
    touch_start(integer num)
    {
        if(llDetectedKey(0)==llGetOwner())
        {
            // URL anpassen !
            httpd_id = llHTTPRequest("http://www.example.de/test.php",[HTTP_METHOD,"GET"],"");
        }
    }
 
    http_response(key id, integer status, list metadata, string body) 
    {
        if ( id == httpd_id )
        { 
            list myList = llParseString2List(body,["|"],[]);
            integer i = llGetListLength(myList);
            integer j = 0;
            for(; i>0 && j<i;j++) {
                llSay(0,llList2String(myList,j));   
            }    
        }
    }
}

Sobald dieser Code gespeichert wurde, wird durch Berühren des Objekt die Systemlast im Chat in 3 Zeilen ausgegeben. Zu beachten ist hierbei, dass nur der Besitzer des Objekts diese Aktion anstoßen kann. Somit ist in gewissem Maß ein Mißbrauch ausgeschlossen.

Im default-Block kann man 3 Eventhandler sehen on_rez, touch_start und http_response.

on_rez:
In diesem Handler wird das aktuelle Skript zurückgesetzt. Der Status des Skripts wird auf default gesetzt und die EventQueue geleert. Variablen werden auch neu initialisiert. Das on_rez Event wird beim Ablegen eines Objekts auf dem Boden gefeuert. Somit wird hier sichergestellt, dass man von einem wohldefinierten Zustand des Objekts ausgehen kann, wenn man es neu benutzen möchte.

touch_start:
Dieses Event wird gefeuert, wenn ein Avatar ein Objekt berührt. Genauer, wenn er damit beginnt es zu berühren. Im Gegensatz dazu steht touch_stop, was gefeurt wird, wenn der Avatar das Berühren beendet. Dazwischen wird beliebig oft das touch-Event gefeuert, dass besagt, dass ein Avatar das Objekt gerade berührt. Ein Avatar kann ein Objekt in SecondLife längere Zeit berühren, daher werden diese 3 Events notwendig. Im Beispiel-Skript wird auf das touch_start reagiert und in unserem Fall ein http-Request ausgeführt, der ein Beispielskript auf einem entfernten Webserver aufruft und dies per HTTP-GET erledigt.

http_response:
In diesem Handler erledigen wir endlich etwas mehr und können an LSL und dessen Funktionsumfang etwas mehr kratzen. Zuerst wird der String, der im http-Body zu finden ist, in eine Liste konvertiert, wobei das „Pipe“-Symbol als Separator identifiziert wird. Somit haben wir nun eine Liste mit den einzelnen Systemlast-Werten.
Anschließend laufen wir in einer For-Schleife über dieses Liste, wandeln die einzelnen Listenelemente in Strings (llList2String) um und schreiben diese in den Chat (llSay).

Wichtig zu wissen ist, dass Skripte einen Größenlimitierung haben, die im kompilierten Zustand greift. Diese liegt aktuell bei 64kb.

Man kann sich nun vorstellen, dass man ein PHP-Skript nutzen kann, um an weitere Informationen zu kommen oder um Informationen zu speichern. Sehr vorteilhaft ist dabei, dass man ein Webinterface erstellen kann, um diese Daten zu verwalten. Bspw. bei einem Lizenz-System. Ein externes System ist im Übrigen die einzige Möglichkeit um größere Datenmengen (mehr als 255 Zeichen) permanent zu speichern.

Zum Schluß dieses Beitrags noch einen Dank an Peter, der mich zu diesem Beitrag motiviert und mit seiner SL-Expertise unterstützt hat.

2 Kommentare

    • Nein, kennt es leider nicht. Man kann das sicher nachprogrammieren. Dann spart man sich auf PHP Seite etwas Arbeit. Aber da die LSL-Skripte größenbeschränkt sind, will man diesen Platz nicht unbedingt mit einem json-Parser verschwenden.

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.