View source for Comment un objet peut répondre a des commandes du clavier

Question de Map McMillan

Sur certaine places, la plupart du temps, les balls sont cachées par un truc du genre « /1 hidden » et visibles avec « /2 shown »

Est il possible de :

1/ choisir un canal personnalisé ? pas « 1 »… mais « /moi » ou » /map » ou « /1map » ou "/n'importe quel autre mot ou chiffre"

La reponse est oui. Pour detected /map il faut ecouter le cannal 0

2/ de faire pareil avec tt les prims? pas uniquement les balls mais aussi des trucs genre les meubles dans 1 maison ?

Oui, tous les prims dans SL sont egaux, pas besoin d'etre une boule.

3/ sinon comment faire pour que les dits « home furnitures » ne soient pas utilisables par le 1er voyageur de passage ?

Voir llGetOwner() plus bas.

----
Je vais répondre a toutes ces questions mais plutot de répondre point par point je vais expliquer les mécanismes sous jacents.

== Les cannaux de chat ==

Second Life a un systeme de chat assez puissant; Il y a 4294967296 canaux numérotés de -2147483648 a +2147483647.
En general quand on parle on utilise le canal 0. 
Par exemple quand on tape 'Hello' ca utilise le canal 0 et ca produit le meme effet que de taper /0 Hello.
Avec le clavier on peut aussi envoyer un message dans un cannal différent.
Par exemple '/123 Hello' envoie le message Hello dans le cannal 123.
Pour peu qu'un script ecoute ce cannal, il peut repondre a cette commande.

== Mais comment est-ce qu'un script peut ecouter un cannal?==

La commande principale est llListen, llListen ecoute un cannal, une personne ou toutes, et un message ou tous.
La syntaxe est
          llListen(integer cannal,string nom,key id, string message);
Souvent on utilise comme ca:
          llListen(123,"","","");
La ca ecoute tout sur le cannal 123.

Notez que l'on peut ecouter le cannal de chat normal.
          llListen(0,"","","");     

Quand un message est détecté, le sim lance l'event listen dans votre script

      listen(integer channel, string name, key id, string msg)

Channel est le channel recu.
Name et id, c'est la personne ou l'objet qui a envoyé le message.
Msg c'est le contenu du message.

== Example ==

Voici un exemple un peu plus complet:
Ce script ecoute le cannal 5, mais uniquement le proprietaire du prim.
Les commandes sont '/5 rouge', '/5 vert', et '/5 bleu'. Je vous laisse deviner ce que ca fait.



  default
  {
      state_entry()
      {
          string name="";      // j'ecoute tous les noms
          key id=llGetOwner(); // mais uniquement mon proprio
          string msg="";       // j'ecoute tous les messages
          llListen(5,name,id,msg);
      }
      
      changed(integer st)
      {
          // ca c'est pour relancer le listen
          // quand l'objet change de proprietaire
          if (st & CHANGED_OWNER)
              llResetScript();
      }
  
      listen(integer channel, string name, key id, string msg)
      {
          // cette ligne n'est pas réellement  nescessaire ici
          // comme on ecoute qu'une personne et qu'un cannal
          if (id==llGetOwner() && channel==5) 
          {    
              if (msg=="rouge") llSetColor(<1,0,0>, ALL_SIDES);
              if (msg=="vert") llSetColor(<0,1,0>, ALL_SIDES);
              if (msg=="bleu") llSetColor(<0,0,1>, ALL_SIDES);
          }
       }
   }

== Détails interessants ==
1 - Les cannaux de SL ne son't pas sécurisés

Particulierement tout cannal entre 0 et 100, est probablement utilisé par d'autres scripts. Si vous faites un frigo qui s'ouvre et se ferme sur commande c'est surement pas tres grave mais soyez vigilant que ce que vous tapez ou faites taper sur un cannal peut etre écouté par quelqu'un d'autre.  

2 - Les commandes llListen se ferment quand vous changez le 'state' d'un script

Je sais pas si beaucoup de gens utilisent les scripts 'state'. Si oui, il faut savoir que toutes les commandes listen sont fermées automatiquement quand vous changez de state, ou que le script est reset.
Dans l'exemple plus haut, le reset a pour effet de fermer le listen pour le proprietaire precedent et reouvre pour le nouveau proprietaire.

3 - Les commandes llSay sont lentes et pas garanties
Envoyer des messages d'un objet a l'autre en utilisant llSay et llListen est la seule facon pour transmettre des messages sur de longues distances.
Ce qu'il faut savoir neanmoins c'est que llSay produit un délai dans le script et aussi le listen event peut prendre beaucoup de temps a traiter la commande.
Quand le listen event prends du temps les commandes sont empilés et traitées une par une plus tard. Néanmoins quand la pile atteinds 30 ou 40, les messages sont perdus.
Ca arrive beaucoup au jeu de Tringo, le tableau mets du temps a raffraichir les scores et parfois certains scores sont perdus de cette facons.


4 - Un script ne s'entends pas 

Je peux me tromper mais je crois qu'un script ne peut pas entendre un message qui provient du meme prim.
Si dans un script vous ecrivez llSay(5,"Rouge"); et que dans le meme script ou autre script du meme prim vous écriver llListen(5,"","",""); les message ne sont pas transmis.
Il y de meilleurs techniques (plus rapides et sécurisées) pour envoyer des messages de scripts en script; voir ((llMessageLinked)). 

5 - Une commande listen peut consommer beaucoup de ressources

Gardez a l'esprit que votre code listen va etre exécuté pour toutes les lignes tapées dans ce cannal.
Si vous avez beaucoup d'objets qui ecoutent un cannal bruyant comme le cannal 0, vous pouvez assez ralentir le sim significativement.
Aussi si vous ecoutez de tres nombreux cannaux (qui n'a pas écrit un Channel Scanner), le simulateur n'aime pas beaucoup ca. A bon entendeur salut.