[Gregleens Merlin]

Pour info il est possible d'appeler une image dans les paramètres média (vidéo) d'un terrain. A la place d'une url type stream vidéo ou simple vidéo, il suffit de mettre l'url vers l'image.

Ensuite un petit script qui change régulièrement l'url media du terrain et l'affaire est joué.

Cependant, il faut avoir le droit de changer l'url media du terrain et ça c'est une autre paire de manches !

[Soffoh]

Citation :

Publié par Jideuze

Tu récupèreras les UUID des textures à afficher dans la liste "liste_textures" et tu pourras les utiliser avec llSetTexture

Le timer sera déclenché régulièrement et ira voir sur le site web si la liste des textures à afficher est toujours la même.

PS: j'ai pas testé, il peut y avoir des erreurs dans les scripts mais l'idée est là

Je pense qu'il vaut mieux faire l'inverse, en passant par XML-RPC et éviter des requettes inutile SL vers le serveur web.

La page PHP envoyant la requette vers SL quand y'a un changement dans la liste ou autre.


Aussi via la video il est possible de faire en sorte d'afficher des textures sans avoir a les uploader mais cela suppose que la personne fasse Play video sur son client, que ca fonctionne chez lui et ca ce n'est pas gagné.

[Jideuze]

Citation :

Publié par Soffoh

Je pense qu'il vaut mieux faire l'inverse, en passant par XML-RPC et éviter des requettes inutile SL vers le serveur web.

Il faudrait que je vois ça un jour... Mais est-ce que ce n'est pas plus compliqué ? Il De plus il n'est pas nécessaire de faire des requêtes très fréquentes, 1 toutes les 5mn ça suffit largement ce qui est bien en deça de la limite de 20 requêtes / 100s.

[Soffoh]

Citation :

Publié par Jideuze

Il faudrait que je vois ça un jour... Mais est-ce que ce n'est pas plus compliqué ? Il De plus il n'est pas nécessaire de faire des requêtes très fréquentes, 1 toutes les 5mn ça suffit largement ce qui est bien en deça de la limite de 20 requêtes / 100s.

non vraiment pas plus compliqué*, j'utilise les requettes XML-RPC très souvent et je dirais que c'est bien mieux car c'est la page PHP sur un evenement (click ou formulaire envoyé/rempli) qui dis à l'objet qu'il y as eu un changement plutot qu'il aille voir si y'a eu du changement ou non pour rien.

*enfin c'est un peu plus de codage (comparé a une ligne Httprequest c'est clair mais bon ca nécessite pas 100 lignes de code non plus.

[bigbass]

Bonjour à vous,

Déjà merci pour vos aides.

Pourrais-je avoir des infos(tuto?) sur ce XML-RPC

[Soffoh]

Citation :

Publié par bigbass

Bonjour à vous,

Déjà merci pour vos aides.

Pourrais-je avoir des infos(tuto?) sur ce XML-RPC

Tout est dans le wiki avec un exemple PHP/PERL (Envoyeur) et LSL (Objet Receveur) et les contraintes (3 seconde de delai par exemple) et les + par rapport au HTTPRequest: (plus de données).

http://wiki.secondlife.com/wiki/Category:LSL_XML-RPC

Mais bon si tu ne fait une requette HTTPRequest que toutes les 5 minutes ou toutes les heures ça vaut peut-être pas la peine de le faire.

J'avais répondue surtout car dans son exemple il faisait une requette toutes les 10 secondes ou 30 secondes je ne sais plus. Bien qu'il y ai un avantage: moins de ressource serveur (car pas de connexion si aucun changement dans la liste des pubs à afficher) et couplé à la réception d'un formulaire ou autre : changement de suite visible sur Second Life (pas la peine d'attendre que le timer se fasse)

[bigbass]

la requête doit ce faire toutes les 10 à 15 Secondes maxi

Donc je vais voir du coté de XML-RPC

[bigbass]

re

cette doc existe elle en français ?

[Soffoh]

Citation :

Publié par bigbass

re

cette doc existe elle en français ?

Heu je ne sasi pas mais met les exemple dasn une page PHP et dasn un Objet in-World tet tu devrasi comprendre comment ca marche.

Sinon je ne vois pas pourquoi tu fait une requette toutes les 10 ou 15 secondes ?

tu n'as pas besoin de recuperer la liste des textures toutes les 10 ou 15 secondes mais seulement d'afficher l'image suivante de la liste et de faire une requette que toutes les 5 minutes,voir toutes les heures pour regarder si la liste à pas changée.

[Jideuze]

Une question que je me pose pour ce qui concerne le XML-RPC, qu'est ce qui se passe si au moment de la requête, c'est à dire quand une texture est modifiée, l'objet receveur n'est pas en mesure de recevoir la requête ? Si la sim où il se trouve est arrêtée par exemple, ou si l'objet est provisoirement dans l'inventaire de son proprio ? Ce sont des situations à gérer, mes tests rapides me font plutôt penser que les requêtes se perdent dans la nature.

L'objet receveur doit de plus commencer par envoyer son "channel" au serveur web qui doit conserver tous les channel des objets pour pouvoir leur envoyer des demandes, ce qui se fait à priori par un HTTPRequest, pas compliqué mais tout de même quelque chose en plus. Par ce moyen le serveur web peut il afficher la liste des objets SL avec qui il communique et qui sont effectivement actifs sur SL ? Comment sait-il qu'ils n'ont pas été supprimés ?

Je gère des réseaux de panneaux, bornes de distribution, etc.. uniquement par le biais du HTTPRequest, toutes les 2mn les objets font un seul llHTTPRequest et envoient leur caractéristiques au serveur web (proprio, position, etc...) et en retour reçoivent les infos qui les intéressent comme la texture à afficher. C'est peut être moins satisfaisant intellectuellement parce que beaucoup de requêtes ne servent apparemment à rien, mais dans les faits c'est simple, efficace et surtout très fiable.
A noter qu'avec ce système le serveur web peut parfaitement connaitre la liste des objets actifs, il suffit qu'il considère comme actif les objets qui ont envoyé un llHTTPRequest depuis peu de temps (par exemple dans les 5mn si la fréquence du llHTTPRequest est de 2mn), et si un objet est désactivé puis réactivé (même 2 jours après), il réapparaît comme actif.

[Soffoh]

Citation :

Publié par Jideuze

Une question que je me pose pour ce qui concerne le XML-RPC, qu'est ce qui se passe si au moment de la requête, c'est à dire quand une texture est modifiée, l'objet receveur n'est pas en mesure de recevoir la requête ? Si la sim où il se trouve est arrêtée par exemple, ou si l'objet est provisoirement dans l'inventaire de son proprio ? Ce sont des situations à gérer, mes tests rapides me font plutôt penser que les requêtes se perdent dans la nature.

La requête n'est pas faite dans ce cas la, mais tout comme avec HTTPRequest si le serveur web réponds pas ou autre tu reçois des données fausses qu'il suffit de tester.

Il faut voir ça comme l'inverse du HTTPRequest:

HTPPRequest => Page PHP => Réponse de la Page PHP à l'Objet.

XML-RPC:
Page PHP => Channel de l'objet => Réponse de l'Objet a la page PHP

(*Page PHP,ASP,Perl ou autre bien sur)
Donc ta page Web sais si oui ou non via la réponse de l'objet si cela as bien été recu et sinon quel erreur à été trouvée.

Citation :

L'objet receveur doit de plus commencer par envoyer son "channel" au serveur web qui doit conserver tous les channel des objets pour pouvoir leur envoyer des demandes, ce qui se fait à priori par un HTTPRequest, pas compliqué mais tout de même quelque chose en plus. Par ce moyen le serveur web peut il afficher la liste des objets SL avec qui il communique et qui sont effectivement actifs sur SL ? Comment sait-il qu'ils n'ont pas été supprimés ?

Il ne peux pas le savoir car aucune réponse (enfin si : objet non trouvé est renvoyé), donc liste a mettre a jour manuellement ou en faisant un menu "suppression a l'objet" et une condition genre ça fait 10 jours de suite qu'il me réponds "objets non trouvé" ou autre pour eviter les oublis. Sinon effectivement le channel dois être connu par le serveur web donc envoyé.

Citation :

Je gère des réseaux de panneaux, bornes de distribution, etc.. uniquement par le biais du HTTPRequest, toutes les 2mn les objets font un seul llHTTPRequest et envoient leur caractéristiques au serveur web (proprio, position, etc...) et en retour reçoivent les infos qui les intéressent comme la texture à afficher. C'est peut être moins satisfaisant intellectuellement parce que beaucoup de requêtes ne servent apparemment à rien, mais dans les faits c'est simple, efficace et surtout très fiable.
A noter qu'avec ce système le serveur web peut parfaitement connaitre la liste des objets actifs, il suffit qu'il considère comme actif les objets qui ont envoyé un llHTTPRequest depuis peu de temps (par exemple dans les 5mn si la fréquence du llHTTPRequest est de 2mn), et si un objet est désactivé puis réactivé (même 2 jours après), il réapparaît comme actif.

A chacun midi à sa porte, et chaque besoin à sa fonction LSL privilégié. Il n'y as pas besoin de faire du HTTPRequest partout comme il n'y pas pas besoin de faire du XML-RPC tout le temps mais les deux sont très complémentaire. Pour ma part je trouve les HTTPRequest pas assez fiable (mais bon ça dépends aussi du site web surchargé, HS ou autre certainement).

[Jideuze]

Citation :

et une condition genre ça fait 10 jours de suite qu'il me réponds "objets non trouvé"

Et si au bout de 10 jours l'objet est réactivé ? Et puis ça marcherait comment ? Tous les jours tu fais manuellement appel à un page web qui va envoyer les infos aux objets SL ?

Pour ne pas dire que je suis convaincu que le XML-RPC est une solution foireuse dans le cas qui nous intéresse j'aimerais bien voir l'ensemble du code équivalent à celui que j'ai proposé mais en XML-RPC et en prenant en compte le fait qu'un objet SL peut très bien être désactivé au moment où on lui signale un changement de texture.

[Soffoh]

Citation :

Publié par Jideuze

Et si au bout de 10 jours l'objet est réactivé ? Et puis ça marcherait comment ? Tous les jours tu fais manuellement appel à un page web qui va envoyer les infos aux objets SL ?

Pour ne pas dire que je suis convaincu que le XML-RPC est une solution foireuse dans le cas qui nous intéresse ...

heu je suis venue en réponse au code (ci-dessous) fait en réponse a sa demande parce que je voyais gros que la personne allais mettre xx panneaux faisant chacun sa requête web toute les 10 secondes et non pas pour te develloper un systeme en xml-rpc pour ton usage (ou alors faudras payer ).

Code PHP:

list liste_textures;
key requete;
 
default
{
  state_entry()
  {
    llSetTimerEvent(10.0);
  }
  timer()
  {
    llSetTexture(llList2Key(liste_textures,(integer)llFrand(llGetListLength(liste_textures))),ALL_SIDES); 
    requete=llHTTPRequest("http://www.monserveur.com/mapage.php", [HTTP_METHOD, "POST"],"");
  }
 
  http_response(key request_id, integer status, list metadata, string body)
  {
    if (request_id==requete)
    {
      liste_textures=llParseString2List(body, ["<br>"], []);
    }
  } 

Citation :

j'aimerais bien voir l'ensemble du code équivalent à celui que j'ai proposé mais en XML-RPC et en prenant en compte le fait qu'un objet SL peut très bien être désactivé au moment où on lui signale un changement de texture

Heu tu peux me dire ce qui se passe quand le serveur web n'as pas pu répondre pour une raison ou pour une autre ou a mal recu son texte dans ton code ?


Sinon :

Comme je l'ai dis dans le post precedent, la page PHP recois "Tout vas bien" avec en plus un message par exemple la position de l'objet sur la sim et autre ou "Channel Inexistant" ensuite y'a plus qu'a le gerer en PHP

La réactivation d'un objet apres avoir été desactivé (ou son activation a son premier rez) se gere par un HTTPrequest vers le serveur web lui disant tel Objet UUID (qui ne change pas normalement) est de nouveau opérationnel ou viens d'etre rezzer et écoute sur le Channel xxx.

Je fini juste par ca qui ne m'as pas plus :

Citation :

Pour ne pas dire que je suis convaincu que le XML-RPC est une solution foireuse dans le cas qui nous intéresse

C'est de ton cas que l'on parle ou de ce que la personne demandais au départ ?

Parce que franchement je viens proposer une solution alternative au HTTPRequest : L'envoie de données que quand c'est nécessaire et non pas pour rien ou quand il n'y en as pas besoin et tu pars sur ton cas qui necessite plus de devellopement. Comme je l'ai dis (au risque de repeter mon dernier post encore) XML-RPC et HTTPRequest sont complémentaires, ils ne sont pas à opposer.

[Jideuze]

Citation :

Publié par Soffoh

heu je suis venue en réponse au code (ci-dessous) fait en réponse a sa demande parce que je voyais gros que la personne allais mettre xx panneaux faisant chacun sa requête web toute les 10 secondes

Pas besoin de le faire toutes les 10s, on est d'accord sur ce point.

Citation :

et non pas pour te develloper un systeme en xml-rpc pour ton usage (ou alors faudras payer ).

J'ai donné une solution avec simplement llHTTPRequest, maintenant si tu préfères garder pour toi une solution avec XML-RPC et nous dire que cette solution existe et est meilleure on veut bien te croire, mais on a tout aussi le droit d'en douter. C'est dommage d'ailleurs, on aurait peut réfléchir aux inconvénients et avantages des 2 façons de faire.

Citation :

Heu tu peux me dire ce qui se passe quand le serveur web n'as pas pu répondre pour une raison ou pour une autre ou a mal recu son texte dans ton code ?

Il est vrai que je ne gère pas ce cas dans l'exemple de code qui n'était là que pour montrer le principe (j'ai même précisé qu'il n'était pas testé) mais il n'y a rien de plus simple. Une solution simple prenant en compte les différentes erreurs possibles : ton code php te renvoi par exemple :

ok<br>3f126ead-285f-2851-711d-e94299c93357<br>2cf7d98a-670f-bd7b-dab4-ac451b3cf159<br>40cb848b-9157-132a-173b-0f5181643397

Et ton objet SL teste si le premier élément est "ok" pour savoir si ce qu'il reçoit est bien une liste de texture ou autre chose comme un message d'erreur.

Citation :

La réactivation d'un objet apres avoir été desactivé (ou son activation a son premier rez) se gere par un HTTPrequest vers le serveur web lui disant tel Objet UUID (qui ne change pas normalement) est de nouveau opérationnel ou viens d'etre rezzer et écoute sur le Channel xxx.

Si ton objet est sur une sim désactivitée puis réactivée (et il doit y avoir d'autres situations similaires) tu n'auras pas d'évènement qui va permettre à l'objet de redemander si les textures n'ont pas été modifiées.

Citation :

C'est de ton cas que l'on parle ou de ce que la personne demandais au départ ?

De ce qu'elle demandait au départ il me semble...

Citation :

Parce que franchement je viens proposer une solution alternative au HTTPRequest : L'envoie de données que quand c'est nécessaire et non pas pour rien ou quand il n'y en as pas besoin et tu pars sur ton cas qui necessite plus de devellopement.

Ma solution nécessite sensiblement moins de développement au contraire.

Citation :

Comme je l'ai dis (au risque de repeter mon dernier post encore) XML-RPC et HTTPRequest sont complémentaires, ils ne sont pas à opposer.

XML-RPC me semble sensiblement plus délicate à fiabiliser, ne serait-ce que parce qu'elle fait appel à http://xmlrpc.secondlife.com/cgi-bin/xmlrpc.cgi qui semble saturé et renvoi régulièrement des messages d'erreur du type :
<pre><br />
<b>Warning</b>: fsockopen() [<a href='/function.fsockopen'>function.fsockopen</a>]: unable to connect to xmlrpc.secondlife.com:80 in <b>/mnt/152/sda/1/7/www.amq/testxml.php</b> on line <b>12</b><br />
Connection timed out (110)<br />
</pre>

[Soffoh]

Citation :

J'ai donné une solution avec simplement llHTTPRequest, maintenant si tu préfères garder pour toi une solution avec XML-RPC et nous dire que cette solution existe et est meilleure on veut bien te croire, mais on a tout aussi le droit d'en douter. C'est dommage d'ailleurs, on aurait peut réfléchir aux inconvénients et avantages des 2 façons de faire.

la solution est l'exemple WIKI, faut que je les recopie ici ?

Citation :

Il est vrai que je ne gère pas ce cas dans l'exemple de code qui n'était là ......

C'est pourquoi je t'ai répondu ce que je t'ai répondu

Citation :

Si ton objet est sur une sim désactivitée puis réactivée (et il doit y avoir d'autres situations similaires) tu n'auras pas d'évènement qui va permettre à l'objet de redemander si les textures n'ont pas été modifiées.

La Page Web, base de donnée le sauras au vu de la réponse recue à toi de le gerer par l'affichage de l'evenement, d e son envoie par mail, de l'activation d'un cron de l'insertion de pauses ou autre pour lui renvoyer a un autre moment et au pire couplé à un petit HTTPRequest fait toutes les heures le soucis se réglerais même tout seul.

Citation :

Ma solution nécessite sensiblement moins de développement au contraire.

Heu c'est ce que je disais relis bien

Citation :

XML-RPC me semble sensiblement plus délicate à fiabiliser, ne serait-ce que parce qu'elle fait appel à http://xmlrpc.secondlife.com/cgi-bin/xmlrpc.cgi qui semble saturé et renvoi régulièrement des messages d'erreur du type :
<pre><br />
<b>Warning</b>: fsockopen() [<a href='/function.fsockopen'>function.fsockopen</a>]: unable to connect to xmlrpc.secondlife.com:80 in <b>/mnt/152/sda/1/7/www.amq/testxml.php</b> on line <b>12</b><br />
Connection timed out (110)<br />
</pre>

Normal regarde ton url

Mis à part cela, je n'ai eue pour le moment aucun soucis avec mais ce genre d'erreur se gere tres bien.

[Jideuze]

Citation :

Publié par Soffoh

la solution est l'exemple WIKI, faut que je les recopie ici ?

L'exemple wiki n'est qu'un exemple de communication, il ne gère évidement pas le pb dont on parle (les textures sur l'objet), et ne s'inquiète pas des éventuelles erreurs.

Citation :

Normal regarde ton url

Mon URL va très bien, j'ai juste ce message de temps en temps, assez souvent même.
C'est une copie du wiki que j'ai utilisé (avec évidement mon propre serveur web, pour la page php)

[Soffoh]

Je laisse tomber si tu écoute pas et que tu est aussi borné que moi sinon ça vas partir en couille cette histoire et apres tout j'en ai rien a foutre

Pour Bigass :

Ne fait pas une requête Web toutes les 10 secondes pour avoir la liste des textures à afficher, dans le timer met une condition pour ne faire la requête que toutes les 5 minutes par exemple :

Code PHP:

list liste_textures;
key requete;
integer compte;

defaut {
             ...
            llSetTimerEvent(10);
            ...
timer {
          compte++
          if (compte==30) //30 = 5 minutes (10sec. x 30timer executés = 300 secondes = 5 minutes)
                   {
                    llHTTPRequest...;
                    compte=0;
                    }
          llSetTexture...

         } 

Voila pour la solution simple.
Sinon il existe (plus compliqué donc) la possibilité de n'envoyer les données que quand il y as eu un appel sur une page php via xml-rpc.

Bonne soirée à vous.

[Jideuze]

Citation :

Publié par Soffoh

Ne fait pas une requête Web toutes les 10 secondes pour avoir la liste des textures à afficher, dans le timer met une condition pour ne faire la requête que toutes les 5 minutes par exemple :

...

Sinon il existe (plus compliqué donc) la possibilité de n'envoyer les données que quand il y as eu un appel sur une page php via xml-rpc.

Donc finalement on est d'accord, j'aurais d'ailleurs fait exactement comme toi pour ne pas avoir de requête à chaque fois que tu changes la texture de l'objet.