llSesor en Link

Répondre
Partager Rechercher
Bonjour a tous

mon système de Metro disparaissant de temps en temps, j'ai décider de le modifier.

mais voila, la fonction du sensor.
llSensor( guide, NULL_KEY, PASSIVE , 40.0, PI/3);

lorsque le sensor est en root, tout marche correctement surtout au moment des traversées de sims . il détecte bien les guides de la sim suivante.

or j'ai besoin de faire un Aller/retour pour le metro, et vu que l'on ne peux pas scanner a -PI/3 ^^ .. j'ai du placer 2 scanners en linkset, 1 pour l'aller et l'autre pour retour.
ces scanners étant dans des links. l'un en rotation 0,0,0 et l'autre a 0,0,180

ce système marche bien sauf qu'il ne détecte pas les guides lors de la traverse des sims
j'ai tenter de rapprocher, d’éloigner, de réduire l'angle, etc . mais rien n'y fait.

le Wiki me dis bien :
Citation :
llSensor does not detect objects or agents across region boundaries
hors il les détecte bien , tous mes systèmes de sensor traversent bien les sims, le tramways marche très bien etc ..

je présume qu'il s'agit donc d'un problème de linkset ? !!

ma question est donc :
PU**** pourquoi !!! non** *de **** ? // ( pardon) mais plutôt
une idée pour détecter des guides a reculons ?
ou alors un astuce pour contourner ce stupide blocage sur le link set.

P.S pour ceux qui comme moi aurait l'idée de stocker le chemin dans une liste, et de la refaire en sens inverse ! oui ca marche c'est mon métro actuel.. mais on le retrouve souvent planté dans un mur des catacombes ou alors disparaitre corps et ames dans les lymbes de SL.. voir même s'amuser a faire des aller/retour sur 40 metres ^^.
pour cela que je change le système ^^.
__________________
Paris 1900
http://www.paris1900.net
J'imagine que le sensor te sert à détecter la position du guide le plus proche, pour ensuite diriger le tram vers cette position.

Si le sensor à travers sim ne marche pas avec des scripts dans un linkset, peut être que la fonction llGetObjectDetails pourrait te dépanner ?

Certes, tu as besoin des UUID des guides.
Cliquez ce bouton ou survolez le contenu pour afficher le spoiler
Que tu peux stocker dans une liste

Cela dit, j'ai du mal à comprendre pourquoi le stockage des positions dans une liste pose des problèmes.
Merci Black

oui pour l'objet detail je l'utilise, mais une fois que l'objet a été detecté

meme si je place llSensor("",NULL_KEY, PASSIVE , 40.0, PI/3) , il ne me detecte aucun objet,
c'est l'événement no_sensor() qui est donc declenché.

je suis bien d'accord avec toi pour le stockage dans une liste, cela me paraissait être une bonne idée mais le metro disparait :

- lorsqu'il y a un restart de sim et que le metro est justement en mode "retour", il suit donc les infos de la liste et arrivé a un bord de sim qui n'existe plus, il disparait avec "out_off wend" ,ca encore, ca peux etre gérable et c'est "normal"

- sans raison apparente (vu de mes yeux) le metro part de travers a un changement de sim et va se planter dans un coin (toujours le meme) dans les catacombes de Paris ^^. j'ai beau avoir strocker et mis un traceur, la liste était bonne et contenait les bonnes informations. pour info il se plante pas au coordonnées 0,0,0

- Sans raison apparente, ni durée, ni information ni retour. le métro disparait a un changement de sim. cela peu durer 2 jours sans problème, comme 2 a 3 fois par jours, difficile de mettre un traceur a part un truc qui m'indiquerait tous les mouvements en continue... ( ca pourrait durer des jours )

- a retour, c'est a dire au moment ou il suit les donner de la liste, il fait 3 déplacements environ , et repart dans l'autre sens pour suivre les guides.
je dirais que cela peux s'expliquer a moitié, car une fois arriver au terminus, il repart suivre les guide et stocker les nouvelles donnée. donc il restocke les 3 ou 4 guides. mais cela ne me dis pas pourquoi il n'a suivi que 3 coordonnées au retour, alors que la liste est bonne.

- et c'est arriver 2 ou 3 fois, le metro a disparu sans raison. et au restart du mardi, 2 metros ont reapparus, 1 planter dans les catacombes, et l'autre qui continuais sa course comme si de rien n'etait

j'en déduit que la fonction llSetKeyFrame... n'est pas fiable du tout lorsqu'il suit les données de la liste de parcours
pour cela que j'ai décider de passer par un scanner aller et un scanner retour.
__________________
Paris 1900
http://www.paris1900.net
Ah ça... la sim sur laquelle on essaie d'envoyer le tram, mais qui est offline... C'est radical
Mais comme tu dis, normal et gérable.

Pour la fonction llSetKeyFrame...
Pour des mouvements à vitesse variable, tels que des ascenseurs, j'utilise fréquemment des listes que je génère avant de lancer le mouvement (la liste des déplacements élémentaires fournie à la fonction). Je ne sais pas combien elle comporte d'éléments, mais une cinquantaine sûrement. Et je n'ai jamais eu de problèmes.
Mais je finis toujours par un llSetLink... PRIM_POSITION pour éviter la dérive.

Le problème de llSetKeyFrame c'est que ce sont des mouvements relatifs. Et si on perd le fil lors de la traversée de la frontière intersim... D'autant plus qu'il faut transférer le script, ainsi que les valeurs actuelles de ses variables, à la sim sur laquelle on entre...

Que penses tu de faire un déplacement prudent par llSetLinkPrimitiveParamsFast, juste sur une dizaine de mètres ou moins, le temps de franchir la sim, et de repasser en llSetKeyFrame ensuite ?
Citation :
Publié par black cats
Mais je finis toujours par un llSetLink... PRIM_POSITION pour éviter la dérive.
Oui je le fait qu'au terminus, mais pas dans les intermédiaire, cela donne des a coups désagréable au metro et perd de la fluidité .
sans le repositionnement au terminus, il perdrais petit a petit sa position initiale


Citation :
Publié par black cats
Que penses tu de faire un déplacement prudent par llSetLinkPrimitiveParamsFast, juste sur une dizaine de mètres ou moins, le temps de franchir la sim, et de repasser en llSetKeyFrame ensuite ?
c'est une idée. j'imagine bien le métro tenant ses roues et soulevant sa jupe et avancer prudemment dans l'eau ^^. (faut que j’arrête les Tex avery) .
__________________
Paris 1900
http://www.paris1900.net
Citation :
Publié par Netpat
c'est une idée. j'imagine bien le métro tenant ses roues et soulevant sa jupe et avancer prudemment dans l'eau ^^. (faut que j’arrête les Tex avery) .
J'imagine bien la scène par Tex Avery.
Penché en arrière, et tendant prudemment la pointe du pied (ou de la roue) en avant...
C'est une belle image.

Tiens, je viens de penser à autre chose.
Citation :
Publié par Netpat
(...)mais voila, la fonction du sensor. llSensor( guide, NULL_KEY, PASSIVE , 40.0, PI/3);
(...)
et vu que l'on ne peux pas scanner a -PI/3
(...)
lorsque le sensor est en root, tout marche correctement surtout au moment des traversées de sims
(...)
une idée pour détecter des guides a reculons ?
Si tu n'as pas de problèmes de détection quand le sensor est dans le root, tu n'as qu'à scanner dans toutes les directions, c'est à dire avec un angle d'ouverture de PI et non PI/3.
Tu récupères alors toutes les balises, qu'elles soient à l'avant, à l'arrière, ou même sur le côté.
Pour distinguer les balises que tu cherches de celles que tu veux ignorer, il suffit de faire la chose suivante :

- tu prends le vecteur ux1, qui est le vecteur unitaire x qui oriente ton root prim.
- pour chaque balise détectée, tu calcules le vecteur ux2, qui est le vecteur unitaire qui pointe du centre du tram vers la balise.
Si tu appelles alpha l'angle entre ux1 et ux2, le produit scalaire ux1*ux2 te donne le cosinus de cet angle.
En marche avant, ce cosinus doit être supérieur à +cos(PI/3) pour que la balise soit valide.
En marche arrière, il doit être inférieur à -cos(PI/3).

Si c'est pas clair, je ferai un schéma.

Dernière modification par black cats ; 30/03/2015 à 14h08.
Citation :
Publié par black cats
Si c'est pas clair, je ferai un schéma.
Si si c'est tres claire, d'autant plus qu'au départ j'etait partie sur une idée similaire.
Scanner a 2*PI, ainsi j'aurais les 3 guides, devant, dessous, derrieres.
Apres il suffit de connaitre notre rotation et on peux trier le bon guide.

c'est une solution mais j'avoue avoir la "flemme" de lancer ce calcul et je me dis que tout calcul et opération prennent un temps et donc bloque le metro pendant cette durée ( TRES courtes)
mais surtout je trouvais plus "propre" de ne scanner qu'un guide a la fois avec un angle etroit .

mais j'ai une idée que je vais tester..
apres tout il ne detecte pas de guide sur la sim en face. dans ce cas je le fait avancer de la meme valeur qu'avant pour traverser la sim.. et il reprendra sa detection une fois le passage fait.
si la sim est off ligne, ben j'aurais un "out of went " mais au moins je saurais que mon metro a disparue normalement

si cette solution ne marche pas ou mal, je reviendrais sur la tienne.
__________________
Paris 1900
http://www.paris1900.net
Quel est l'intérêt d'avoir des guides par rapport à un balisage virtuel ? Le métro sait en permanence où il se trouve, il peut posséder son itinéraire en mémoire et le respecter. J'y vois surtout tout un tas d'inconvénients : des objets disséminés, une gestion de sensor...
Citation :
Publié par bestmomo
Quel est l'intérêt d'avoir des guides par rapport à un balisage virtuel ? Le métro sait en permanence où il se trouve, il peut posséder son itinéraire en mémoire et le respecter. J'y vois surtout tout un tas d'inconvénients : des objets disséminés, une gestion de sensor...
oui tout a fait, sauf que justement cette liste me pose plus de problème que de solution. disparition du métro aléatoirement.
et puis j'avais opté pour les guides car je modifie Paris frequenment .. et me refaire les parcours a chaque fois ca deviens lassant;
deja que je doit le faire pour les caleches, les taxis .
maintenant j'opte pour les guides. plus facile a déplacer .
et le sensor je ne l'utilise que lorsque j'en ai besoin, avec un rayon étroit et un courte distance.

je viens de modifier l'histoire du sensor , lorsqu'il arrive en bordure de sim il n'y a donc plus de détection depuis le linkset. je continue donc a avancer de la meme valeur/2 et rotation
une fois la sim traversées il retrouve son guide et peu donc continuer.

finalement je vais pouvoir alléger les guides avec cette technique, ne placer des guides que lorsqu'il y a changement de direction (rotation) ou station ou terminus.
mais je vais attendre un peu pour voir si le métro ne redisparait pas.
__________________
Paris 1900
http://www.paris1900.net
Il suffit de faire un système qui lit les guides s'ils sont présents et qui suit sa liste s'il n'en trouve pas, ou auquel tu demandes de lire les guides avec une option. De façon à régénérer la liste au besoin.

Pour la prochaine fois où tu le perds :

metro.jpg

Dernière modification par bestmomo ; 31/03/2015 à 11h35.
Répondre

Connectés sur ce fil

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