• Bitte schaltet eure Ad Blocker aus. SLinfo kann nur betrieben werden, wenn es durch Werbung Einnahmen erzielt. Vielen Dank!!
  • Wir freuen uns, wenn du dich in unserem Forum anmeldest. Bitte beachte, dass die Freigabe per Hand durchgeführt wird (Schutz vor Spammer). Damit kann die Freigabe bis zu 24 Stunden dauern.
  • Wir verwenden Cookies, um Inhalte und Anzeigen zu personalisieren, Funktionen für soziale Medien anbieten zu können und die Zugriffe auf unsere Website zu analysieren. Sie geben Einwilligung zu unseren Cookies, wenn Sie unsere Webseite weiterhin nutzen.

Avatarnamen abfragen

Daemonika Nightfire

Forumsgott/göttin
huhu,

Da momentan in mehreren Threads ueber Avatarnamen diskutiert wird, habe ich mal eine kleine Auswahl moeglicher Methoden mittels Script den Avatarnamen abzufragen zusammen gestellt. Ich fange erst ganz leicht an und nach unten hin wird es anspruchsvoller. Der Einfachheit halber verwende ich ausschliesslich den Touch als Ausloeser.

llDetectedName(0)
Diese Funktion kann ausschliesslich in Events verwendet werden, die einen Detect unterstuetzen, zudem ist hierfuer die Anwesenheit des Avatars auf der Region unerlaesslich.
Code:
default
{
    touch_start(integer total_number)
    {
        llSay(0, llDetectedName(0) + " touched me.");
        // Username in Gross und Kleinschreibung inclusive Resident.
    }
}

llKey2Name(key id)
Diese Funktion kann in jedem Event ausgefuehrt werden, sobald der Avatar Key bekannt ist, auch hier ist die Anwesenheit des Avatars zwingend erforderlich.
Code:
default
{
    touch_start(integer total_number)
    {
        key avatar = llDetectedKey(0);
        llSay(0, llKey2Name(avatar) + " touched me.");
        // Username in Gross und Kleinschreibung inclusive Resident.
    }
}
Bleiben wir kurz bei dieser Funktion und versuchen die gleiche Abfrage diesmal ohne Resident in der Ausgabe.
Hier ist es notwendig beide Namen zuerst in einer Liste getrennt aufzulisten. Anschliessend lassen sich bei Bedarf beide Namen separat ausgeben.
Code:
default
{
    touch_start(integer total_number)
    {
        key avatar = llDetectedKey(0);
        
        list parse = llParseString2List(llKey2Name(avatar), [" "], [""]);
        string FirstName = llList2String(parse, 0);
        string LastName = llList2String(parse, 1);
        
        if(LastName == "Resident")
        {
            llSay(0, FirstName + " touched me.");
            // Username in Gross und Kleinschreibung ohne Resident.
        }
        else if(LastName != "Resident")
        {
            llSay(0, FirstName + " " + LastName + " touched me.");
            // Username in Gross und Kleinschreibung inclusive individuellen Nachnamen.
        }
    }
}

llGetUsername(key id)
Folgende Funktion kann ebenfalls in jedem Event ausgefuehrt werden, sobald der Avatar Key bekannt ist, jedoch gilt auch hier das der Avatar Anwesend sein muss.
Code:
default
{
    touch_start(integer total_number)
    {
        key avatar = llDetectedKey(0);
        llSay(0, llGetUsername(avatar) + " touched me.");
        // Username kleingeschrieben, resident entfaellt, User mit Nachnamen erhalten einen Punkt zwischen beide Namen.
    }
}

llGetDisplayName(key id)
Nun kommen wir endlich mal zum Displaynamen. Hier gelten die selben Regeln wie beim vorherigen Beispiel.
Code:
default
{
    touch_start(integer total_number)
    {
        key avatar = llDetectedKey(0);
        llSay(0, llGetDisplayName(avatar) + " touched me.");
        // Displayname
    }
}

Kurz Luft holen...
...kommen wir nun zu Beispielen, bei denen die Anwesenheit des Avatars nicht erforderlich ist.

llRequestUsername(key id)
Dieses ist eine Dataserver Funktion welche in jedem Event ausgeloest werden kann, sobald der Avatar Key bekannt ist. Zusaetzlich ist hier diesmal der Dataserver Event fuer die Ausgabe erforderlich.
Code:
key User_name_query;

default
{
    touch_start(integer total_number)
    {
        key avatar = llDetectedKey(0);
        User_name_query = llRequestUsername(avatar);
    }
    
    dataserver(key queryid, string data)
    {
        if(User_name_query == queryid)
        {
            llSay(0, data + " touched me.");
            // Username kleingeschrieben, resident entfaellt, User mit Nachnamen erhalten einen Punkt zwischen den Namen.
        }
    }
}

llRequestDisplayName(key id)
Natuerlich existiert diese Funktion auch fuer den Displaynamen und unterliegt den selben Regeln.
Code:
key Display_name_query;

default
{
    touch_start(integer total_number)
    {
        key avatar = llDetectedKey(0);
        Display_name_query = llRequestDisplayName(avatar);
    }
    
    dataserver(key queryid, string data)
    {
        if(Display_name_query == queryid)
        {
            llSay(0, data + " touched me.");
            //  Displayname
        }
    }
}

llRequestAgentData(key id, DATA_NAME)
Zu guter Letzt eine Funktion die so alt ist wie Second Life. Diese Abfrage kann wie die llKey2Name Version in einzelne Bestandteile aufgelistet werden, jedoch ist hier die Anwesenheit des Avatars nicht erforderlich.
Code:
key Agent_data_query;

default
{
    touch_start(integer total_number)
    {
        key avatar = llDetectedKey(0);
        Agent_data_query = llRequestAgentData(avatar, DATA_NAME);
    }
    
    dataserver(key queryid, string data)
    {
        if(Agent_data_query == queryid)
        {
            llSay(0, data + " touched me.");
            // Username in Gross und Kleinschreibung inclusive Resident.
        }
    }
}

Ich hoffe die Beispiele sind euch nicht zu trocken, weil ich sie nicht bunt angemalt habe.

LG
Dae
 
Zuletzt bearbeitet:
Da es in LSL keine funktioniernde llName2Key funktion gibt:

Unter
http://w-hat.com/#name2key

Gibts einen Service, mit dem man zu den meisten Avas die zugehörige UUID bekommt, die man dann in diversen anderen Funktionen benutzen kann. Die genaue API ist auf der Webseite erklärt, weitere derartige Services gibts hier:

http://kdc.ethernia.net/sys/name2key.php
http://name2key.haxworx.net/
(letzterer nutzt teilweise die SL-Websuche, die für LSL scripts direkt nicht erreichbar ist, zusätzlich zur W-hat Datenbank)

Der Nachteil der Services von Dritten: Eine Funktion kann nicht zu 100% garantiert werden, ebenso kann die Verfügbarkeit nicht garantiert werden.

[Und um das kurz zu ergänzen, weil das oft von neuen Usern nicht verstanden wird: Der Key/UUID eines Avatars ist nichts geheimes, das sind auch keine "persönlichen Daten". Das ist einfach der system-interne, eigentliche Name des Avatars, der leichter von Maschinen in den Datenbanken verarbeitet werden kann als die von Menschen lesbaren Zeichenfolgen. Dass LL keine llName2Key Funktion anbietet liegt vermutlich daran, dass so eine Abfrage bei vielen Millionen Accounts, die in der Datenbank wohl nur nach den UUID und eben nicht nach den Namen sortiert sind, bisschen dauern und das System ausbremsen kann, vor allem, wenn viele Scripts das nutzen. W-hat sortiert einfach nach Namen und kann daher eben schnell die UUID dazu liefern.]
 
Ergaenzend zu den name2key Services sollte man noch erwaehnen, das sie nicht mit Displaynamen funktionieren und jemals funktionieren koennen.
Also wenn man vor hat die UUID eines Avatars ueber den Namen abzufragen, muss man den Usernamen verwenden. So wie bei den BuyAsGift Funktionen vieler Vendoren.

LG
Dae
 
Aber warum nutzt man nicht einfach zur Abfrage http://world.secondlife.com/resident/ -- da der Key -- also zum beispiel http://world.secondlife.com/resident/26c943ae-6327-4d58-9ffe-07698a010000 Dann muss man nur noch von der Rückgabe den Namen auslesen und fertig.

2 Gründe:

Avatare werden dort nur gefunden, wenn sie im Profil "in Suche anzeigen" aktiviert haben.
Das ist ein bescheidener Schutz privater Daten vor nicht in SL eingeloggte Websurfer/Crawler Bots
Darum muß man zb auch auf secondlife.com eingeloggt sein um Profile über my.secondlife.com/vorname[.nachname]
anzusehn oder diesem User über diese Seite per Web eine IM zu schreiben


Seit der Einführung der Werbung im Kopfteil lassen sich Webrequests mit solchen URLs oder auch von
search.secondlife.com viel schwieriger parsen bzw man knallt ratzfatz an das Limit im Respond body.
Das kann man zwar explizit im Request (unter MONO) aufstocken aber nicht immer ist das auseichend
 
Charline, weil es 7 verschiedene einfache Methoden gibt, die das per Script sehr schnell Inworld erledigen.
Eine Webseite auslesen ist fuer diesen Nutzen unverhaeltnissmaessig aufwendig.

LG
Dae
 
2 Gründe:
Avatare werden dort nur gefunden, wenn sie im Profil "in Suche anzeigen" aktiviert haben.
Das ist ein bescheidener Schutz privater Daten vor nicht in SL eingeloggte Websurfer/Crawler Bots

Ok wenn das so ist hast du natürlich recht.

Seit der Einführung der Werbung im Kopfteil lassen sich Webrequests mit solchen URLs oder auch von
search.secondlife.com viel schwieriger parsen bzw man knallt ratzfatz an das Limit im Respond body.
Das kann man zwar explizit im Request (unter MONO) aufstocken aber nicht immer ist das auseichend

Mit dem Parsen sehe ich kein Problem immerhin kann man sich ja selber mal eben ein php Script bauen was das Parsen übernimmt.
 
Anmerkung

huhu,

bei den Funktionen die ich oben beschrieben habe, gibt es noch etwas wissenswertes auf das man achten sollte.

Folgende Funktionen stellen fuer den Sim-Server ueberhaupt keine Belastung dar, weil der Avatar Name,Displayname und Key bereits bekannt ist. Hierbei hat das Script so zu sagen nichts weiter zu tun als eben mal die Anwesenheitsliste dieser Region abzufragen. Darum muss fuer diese Funktionen der Avatar auch auf der Region anwesend sein.

  • llDetectedName(0)
  • llKey2Name(key id)
  • llGetUsername(key id)
  • llGetDisplayName(key id)

Bei den Dataserver Varianten sieht die Sache schon etwas anders aus. Hier muss der Avatar nicht anwesend sein, weil der Sim-Server dafuer grob gesagt bei den Account-Servern nachfragt welcher Name zum gesendeten key passt. Zudem sind die Dataserver Funktionen in Verbindung mit Key (UUID) abfragen getrottled (zeitlich limitiert). Das bedeutet, sobald man mit einem Dataserver eine UUID abarbeiten will, Bremst der Server diese Funktion automatisch runter, wodurch man lediglich alle 35 Secunden eine Abfrage stellen kann.

  • llRequestUsername(key id)
  • llRequestDisplayName(key id)
  • llRequestAgentData(key id, DATA_NAME)
Aus diesem Grund eignen sich die Dataserver Varianten ueberhaupt nicht als Greeter, Radar, Security oder aehnliches Zeug womit man grosse Listen von keys vergleichen koennte. Bei dem Versuch eine Liste von Keys mit einer for Schleife in Namen umzuwandeln werden alle vorherigen Anfragen dieses Events ignoriert und lediglich der Letzte Key aus der Liste als Name zurueckgegeben.

Das die Datasever Funktionen eine Belastung fuer das System darstellen haben die Lindens auch schon verkuendet, als sie den TPV Entwicklern untersagt haben mittels llRequestAgentData(key id, DATA_ONLINE) den Online Status fremder Avatare automatisiert abzufragen. Eigentlich wollten sie sogar noch einen Schritt weiter gehen und diese Funktion ausschliesslich fuer den Owner des Scripts funktional zu halten, aber bis jetzt ist in dieser Hinsicht noch nichts passiert.

LG
Dae
 
Mit dem Parsen sehe ich kein Problem immerhin kann man sich ja selber mal eben ein php Script bauen was das Parsen übernimmt.

Ein php Script in SL?
Das Problem mit dem Response body tritt in LSL auf, da ist der "Antwortstring" im http_response Event, der auf eine llHTTPRequest() Anfrage ausgelöst wird, erst mal auf 2KB begrenzt, alles nach den 2KB wird einfach abgeschnitten. Dieser Wert lässt sich zwar erweitern - aber eben nur auf 1/4 der maximalen Scriptspeichergröße, also auf maximal 4KB unter LSO und auf maximal 16KB bei Mono Scripts.
Und das reicht wie erwähnt leider nicht um das Ganze in LSL zu parsen. Statt also secondlife.com über einen einfachen proxy abzufragen (direkt über LSL geht das ja nicht) müsstest du einen eigenen Webserver laufen lassen, der diese Abfrage für die macht und für dich die Seite parst (ob nun per php, perl oder python oder wie auch immer ist wurscht) um dir dann den Key in den http_response Event im Script zu liefern damit du ihn in SL verwenden kannst.

Wobei da eben das erste Problem auftritt, das Diana erwähnt hat: Man muss auf der Webseite secondlife.com angemeldet sein um vollen Zugriff auf alle Suchfunktionen zu haben.
 
@ Charline

Du kannst gerne ein Tutorial anhaengen wie so etwas realisiert werden kann.
Dann kann jeder selber entscheiden ob der Aufwand den Nutzen rechtfertigt.

LG
Dae
 
Als Beispiel


Code:
<?php

$avakey = empty( $_GET['avakey'] ) ? '' : $_GET['avakey'];
$file = file_get_contents( 'http://world.secondlife.com/resident/' . $avakey );
$exp = explode( '<h1 class="resident">' , $file );
$exp = explode( '</h1>' , $exp[1] );
$exp = explode( '<span>' , $exp[0] );
$exp = explode( '</span>' , $exp[1] );
echo ( $exp[0] == '' ) ? 'unbekannt' : $exp[0];

?>
 
Zuletzt bearbeitet:
@Charline: Danke für das Beispiel. Schon erstaunlich, wie kurz ein PHP Code sein kann, wenn man's kann. ;-) (bin da etwas PHP blond)

@Sven: Inworld geht halt leider nicht in SL, also entweder auf einem eigenen Webserver coden, oder einen Dienstleister beanspruchen. OpenSim beispielsweise hat die Funktion längst implementiert, da geht es inworld in OSSL.
 
Danke Charline, aber dein PHP Beispiel ist nur die halbe Miete.
Es waere hilfreich, wenn man auch sehen kann wie das dazu passende LSL Script aussieht. ;)

LG
Dae
 
Code:
string SERVER_ADDR = "http://www.meinedomain.de";

default
{
	touch_start(integer total_number)
	{
		key avakey = llDetectedKey(0);
		llHTTPRequest(SERVER_ADDR + avakey, [HTTP_METHOD , "GET", HTTP_BODY_MAXLENGTH, 63 ], "");
	}
	http_response(key request_id, integer status, list metadata, string body)
	{
		if(status == 200) {
			llSay(PUBLIC_CHANNEL, "Deine Name ist -> " + body);
		}
	}
}

So ok? :)

Habe PHP-Code noch etwas verändert.
 
Zuletzt bearbeitet:

Users who are viewing this thread

Zurück
Oben Unten