[ACTU] Lancement du premier set d'outils avancés pour les créateurs.

Répondre
Partager Rechercher
Linden Lab annonce sur le blog officiel le lancement du premier ensemble d'outils avancés pour les créateurs, qui comprend l'agent teleportet la fixation temporaire.

L'agent teleport est un nouvel appel LSL qui permet aux scripts de téléporter des agents à une SLURL donnée ou une position locale. On peut désormais créer des "portails" ou même des objets qui provoquent un teleport instantané après avoir été touchés, comme c'était le cas pour les montres de Linden Realms qui provoquaient un TP lorsqu’ils vous touchaient. Mais cet outil peut aussi être utilisé dans les chasses au trésor, pour TP directement un participant au prochain indice lorsqu'il a trouvé un objet caché, par exemple.

La fixation temporaire permet de créer des objets temporaires tels que des attachements de démonstration ou des équipements de "région spécifique", sans créer de stock inutile à gérer dans l'inventaire. Pour les shopping addicts, vous pourrez désormais essayer des tenues ou des accessoires avant de les acheter, sans encombrer votre inventaire de multiples démos.

D'après Damien Fate sur New World Note, les fonctionnalités sont bien, mais elles sont malheureusement limitées par rapport aux versions du code qui semble être en place pour Linden Realms. Par exemple, le script agent teleport semble ne téléporter que les propriétaires de l'objet...

Que pensez-vous de ces nouveaux outils ?
Vous leur voyez d'autres application possibles et utiles ?


Moi, c'est surtout l'outil de fixation temporaire qui me ravi : Enfin une solution aux démos qui encombrent toujours plus mon inventaire parce que je n'aime pas jeter et je me dis toujours que ça peut servir...



Je suis d'accord avec toi et avec Damien Fate : le port temporaire d'objet c'est super pratique, ça va faire du bien au commerce. Comme Damien Fate, je pense que ça devrait marcher sur beaucoup plus de type de truc à porter.

Sinon la limitation actuelle de l'agent teleport en enlève l'intérêt : ça ne marche que pour le propriétaire de l'objet.
Oui c'est dommage pour l'agent teleport: le RLV fait mieux.

La fixation temporaire ça a l'air intéressant: il faut voir si il est possible d'attacher temporairement un objet qui n'est pas à soi mais qu'une fois attaché (et je ne vois pas comment c'est possible autrement) serait considéré avoir l'avatar comme owner. Auquel cas on pourait s'en servir comme relais pour un tas de chose, dont l'agent teleport
J'ai testé et ça fonctionne pas:
- l'agent teleport effectivement ne fonctionne que pour le owner. Et puis Phoenix ne fonctionne pas aussi.
- Un attachement temporaire ne peut pas téléporter grrrrrrrrr.

Bref pour l'agent teleport LL nous a encore pondu une fonction qui ne sert pas à grand chose.
Je trouve ça bien
actuellement libérer "un portail de téléportation" sans autre changement serait un problème
on aurait des cube invisible partout de gens pas net d'ou la seule possibilité de propriétaire
Citation :
Publié par Milky
Je trouve ça bien
actuellement libérer "un portail de téléportation" sans autre changement serait un problème
on aurait des cube invisible partout de gens pas net d'ou la seule possibilité de propriétaire
Le tp demande une autorisation, comme pour les animations, les débit d'argent, la prise de contrôle des déplacements... C'est exactement le même niveau de sécurite que ces opérations courantes sur lesquelles on constate rarement des abus. Cette sécurité que LL s'est donné la peine de mettre en place est incompréhensible pour le owner (elle pourrait être implicite comme pour l'autorisation d'animer à partir d'un attachement) et rend incompréhensible puisque sécurité il y a que cela ne fonctionne pas pour les non owner.
Citation :
Publié par Elenia B.
Cette sécurité que LL s'est donné la peine de mettre en place est incompréhensible pour le owner (elle pourrait être implicite comme pour l'autorisation d'animer à partir d'un attachement) et rend incompréhensible puisque sécurité il y a que cela ne fonctionne pas pour les non owner.
Donc vraiment inutile et comme tu le dit dans ton post précédent, le RLV fait mieux. Je me souvient des Stargate RLV, où il suffisait de passer au travers du portail juste en portant un HUD rlv.
Citation :
Publié par Elenia B.
Le tp demande une autorisation, comme pour les animations, les débit d'argent, la prise de contrôle des déplacements... C'est exactement le même niveau de sécurite que ces opérations courantes sur lesquelles on constate rarement des abus. Cette sécurité que LL s'est donné la peine de mettre en place est incompréhensible pour le owner (elle pourrait être implicite comme pour l'autorisation d'animer à partir d'un attachement) et rend incompréhensible puisque sécurité il y a que cela ne fonctionne pas pour les non owner.
Daccord
Citation :
Publié par Ryou Yiyuan
Donc vraiment inutile et comme tu le dit dans ton post précédent, le RLV fait mieux. Je me souvient des Stargate RLV, où il suffisait de passer au travers du portail juste en portant un HUD rlv.
Huh ? en quoi c est mieux ?
En RLV , tu as besoin d un viewer compilé avec RLV + une activation de RLV par l utilisateur + un HUD + être owner du HUD qui parlera au owner des messages interprétés par le viewer comme des actions RLV + un listener dans le HUD qui écoute le portail stargate émettre des des messages

1er cas : l utilisateur porte un attachement capable d écouter les messages en provenance des prims sur une sim
sous cas 1 : l utilisateur utilise rlv . il se fait tp comme tu le dis sans confirmation .
sous cas 2 : l utilisateur utilise llTeleportAGent et llTeleportAgentGlobalCoords . Il se fait tp aussi sans confirmation sauf pour la première utilisation du hud . Ensuite , pour les téléportations suivantes , l est inutile de les redemander puisque les permissions n auront pas eu besoin d être changées.. Il est possible de savoir par script si les permissions ont besoin d être changées par llGetPermissionsKey et llGetPermissions
Donc une demande de confirmation pour pouvoir se tp 10000 fois , ce n est pas très cher payé

2ème cas : l utilisateur ne porte pas un attachement capable d écouter les messages en provenance des prims sur une sim
sous cas 1 : comme RLV se base sur l interpretation des messages parlant au owner et préfixées par @ , et comme la prim sur la sim n appartient pas forcément au owner , elle ne peut pas téléporter l agent .
Comme le relai RLV n est pas porté par l agent , rien ne se passe
sous cas 2 llTeleportAGent et llTeleportAgentGlobalCoords peuvent le faire au prix d une demande de permission .

Dsl mais RLV est pire

Que llTeleportAGent et llTeleportAgentGlobalCoordsne nous satisfassent pas autant qu on l ait voulu, cela peut se comprendre . Mais pour l instant il n y a pas mieux

Dernière modification par redpurple ; 02/08/2012 à 23h32.
Citation :
Publié par redpurple
Huh ? en quoi c est mieux ?
En RLV , tu as besoin d un viewer compilé avec RLV + une activation de RLV par l utilisateur + un HUD + être owner du HUD qui parlera au owner des messages interprétés par le viewer comme des actions RLV + un listener dans le HUD qui écoute le portail stargate émettre des des messages

1er cas : l utilisateur porte un attachement capable d écouter les messages en provenance des prims sur une sim
sous cas 1 : l utilisateur utilise rlv . il se fait tp comme tu le dis sans confirmation .
sous cas 2 : l utilisateur utilise llTeleportAGent et llTeleportAgentGlobalCoords . Il se fait tp aussi sans confirmation sauf pour la première utilisation du hud . Ensuite , pour les téléportations suivantes , l est inutile de les redemander puisque les permissions n auront pas eu besoin d être changées.. Il est possible de savoir par script si les permissions ont besoin d être changées par llGetPermissionsKey et llGetPermissions
Donc une demande de confirmation pour pouvoir se tp 10000 fois , ce n est pas très cher payé

2ème cas : l utilisateur ne porte pas un attachement capable d écouter les messages en provenance des prims sur une sim
sous cas 1 : comme RLV se base sur l interpretation des messages parlant au owner et préfixées par @ , et comme la prim sur la sim n appartient pas forcément au owner , elle ne peut pas téléporter l agent .
Comme le relai RLV n est pas porté par l agent , rien ne se passe
sous cas 2 llTeleportAGent et llTeleportAgentGlobalCoords peuvent le faire au prix d une demande de permission .

Dsl mais RLV est pire

Que llTeleportAGent et llTeleportAgentGlobalCoordsne nous satisfassent pas autant qu on l ait voulu, cela peut se comprendre . Mais pour l instant il n y a pas mieux
Sauf que le teleport agent uniquement l'owner l'utilise point barre donc mettre un tp pour soit même bof bof. Je ne me base que sur mon expérience d'utilisatrice pas de scripteuse. Donc si l'utilisateur active le RLV dans le viewer et porte le HUD, c'est que pour moi, il donne l'autorisation. Si tout le monde avait accés au teleport agent, ok ce serait mieux.
Citation :
Publié par Ryou Yiyuan
Sauf que le teleport agent uniquement l'owner (...) mettre un tp pour soit même bof bof.
Le problème est exactement le même :
que l'on passe par le RLV, ou que l'on utilise la fonction llTeleport, l'objet qui contient le script qui te téléporte ne peut téléporter que le propriétaire de cet objet , et personne d'autre.

Or, ce que l'on veut généralement est la chose suivante :
un objet objA (genre stargate) appartenant à un avatar avA, contient un script avec les coordonnées d'une destination donnée, est censé téléporter un avatar avB .

La seule solution (dans les deux cas, RLV ou nouvelle fonction llTeleport ) est alors la suivante :
l'objet objA envoie un message à l'objet objB (hud récepteur porté par l'avatar avB que l'on veut téléporter), lui indiquant les coordonnées de la destination. Le hud récepteur objB peut alors téléporter la personne qui le porte.

Ce que j'écris là est exactement ce qu'écrit redpurple plus haut, en d'autres termes.

Le problème qui se pose est la communication entre l'objet émetteur objA, et le récepteur du message, qui est le hud objB. Le message est formulé d'une certaine façon, par celui qui écrit le script émetteur. Le récepteur objB doit donc être conçu pour pouvoir entendre ce message, et pour pouvoir l'interpréter correctement.
Se pose alors le problème : pour que ça marche, il faut que le stargate (l'émetteur du message) et le récepteur soient faits par le même scripteur.

C'est là que le RLV a (pour l'instant) une longueur d'avance : il existe une convention de communication.
http://wiki.secondlife.com/wiki/LSL_.../Specification
C'est ce qui permet de faire des récepteurs universels dans le cas du RLV (connus sous le nom de "relay"), capables d'interpréter les messages émis par n'importe quel objet (généralement du mobilier BDSM) utilisant ce protocole de communication conventionnel.

Ce sont des résidents, et non LL qui sont à l'origine de cette convention.
Ce qu'il faudrait, c'est mettre en place une convention analogue destinée aux objets utilisant les fonctions llTeleport.
Oui je ne suis pas d'accord avec toi RedPurple le RLV est nettement mieux.

Bien sur, il y a 2 préalables: que le RLV soit activé dans le viewer (et bien sur que ce soit un viewer compatible) et que l'on porte un relay activé.

Ce sont des actions volontaires qui dépendent de chaque utilisateur: moi, c'est le cas en permanence. C'est plus drôle comme ça.

N'importe quelle porte peut tp n'importe quel utilisateur avec ces 2 préalables remplis, sans aucune demande d'autorisation.

A coté de ça nous avons un agent teleport qui ne sait tp que l'owner, et avec en prime une demande d'autorisation, comme si ça servait à quelque chose dans le cas du owner! Cela ne tient pas la route, sauf si on ne veut absolument pas du RLV bien sur, sauf si on veut utiliser absolument le viewer Linden, sauf si on a la trouille de porter un relay ouvert en permanence. Alors oui dans ces cas là l'agent teleport est mieux que rien c'est sur. Mais ça marchera que pour un hud ou un portail à soi et ça c'est l'énorme défaut que je lui reproche.

Mais black cat a raison: ce qui manque c'est un protocole de com qui permettrait d'activer un hud qui lui ferait le tp. Mhhhhhh on pourrait utiliser le protocole RLV, et faire un relais TP universel. Bien sur. Génial! Dommage je n'aurais pas le temps de faire ça ce week end.
Répondre

Connectés sur ce fil

 
1 connecté (0 membre et 1 invité) Afficher la liste détaillée des connectés