[Ma-ya]

Bonjour,

J'ai une question relative aux prims fantômes.

Comment faire pour intégrer des prims fantômes à une structure liée ?

Faut il un script ?

Merci

[-.-]

Un artifice permet de le faire, à condition que la (les) prims qui doivent être fantômes soient des prims child (pas la prim root).
Le processus est le suivant :

1. Délier les prims qui doivent être fantôme de l'objet.
2. Glisser le script suivant dans les prims à passer en fantôme.
   
   Code:

   default
   {
       state_entry()
       {
           llSetStatus( STATUS_PHANTOM, FALSE );
           llVolumeDetect( TRUE );
           llRemoveInventory( llGetScriptName() );
       }
   }

3. Relier l'ensemble. J'insiste, aucune des prims fantômes ne doit être root, sinon tout l'objet sera fantôme.

Il s'agit là d'une astuce dont la pérennité n'est pas garantie à long terme.
J'avais trouvé cette information sur le site du groupe Constructeurs & Scripteurs.
Le lien donné ci-dessus propose une nouvelle solution. Suivez le, ce groupe mérite votre attention.

[Ma-ya]

Merci

[Magic Cat]

ca serait pas mal à wikiser ca

[Ma-ya]

Bonjour,

Je reviens sur ce sujet, car après essai, le script ne fonctionne malheureusement pas.
En effet, une fois l'élément lié, tous les prims deviennent fantômes....
Dommage

[Ma-ya]

J'ai trouvé cet autre script dans la SL Library, mais il ne fonctionne pas non plus.
Les nouveaux viewers ne semblent pas les supporter.

Code:

default {
    state_entry() {
        llSetPrimitiveParams([PRIM_TYPE, PRIM_TYPE_BOX,
            0, <0,1,0>, 0, <0,0,0>, <1,1,0>, <0,0,0>,
            PRIM_FLEXIBLE, TRUE, 0, 0, 0, 0, 0, <0,0,0>,
            PRIM_TYPE] + llGetPrimitiveParams([PRIM_TYPE]));
    }
 
    on_rez(integer s) {
        llResetScript();
    }
 
    //-- This event/test will reset the script on sim restart.
    changed (integer vBitChanges){
        if (CHANGED_REGION_START & vBitChanges){
            llResetScript();
        }
    }
    collision_start(integer num_detected){
        llResetScript();
 
    }
}

http://wiki.secondlife.com/wiki/Phantom_Child

[-.-]

Citation :

Publié par Ma-ya

Bonjour,

Je reviens sur ce sujet, car après essai, le script ne fonctionne malheureusement pas.
En effet, une fois l'élément lié, tous les prims deviennent fantômes....
Dommage

Si ça ne fonctionne pas c'est que tu mal fais l'une des étapes !
J'ai décrit, point par point, la méthode dans mon message un peu plus haut et surtout, j'insiste bien à la fin sur le fait que les prims mise en fantôme par le script donné doivent être liées à l'ensemble en tant que prims child.
Je suppose que tu as mis en root (racine, contour jaune à l'édition) la ou une des prims mise en fantôme. Dans ce cas, il est normal que tout l'objet le devienne.

[Polo Slok]

Bonjour,
Après un essai sur le dernier viewer 2.0, ça marche parfaitement , il suffit de suivre à la lettre les indications données par Mingyar Ishtari !

[Ma-ya]

Citation :

Publié par Mingyar Ishtari

Si ça ne fonctionne pas c'est que tu mal fais l'une des étapes !
J'ai décrit, point par point, la méthode dans mon message un peu plus haut et surtout, j'insiste bien à la fin sur le fait que les prims mise en fantôme par le script donné doivent être liées à l'ensemble en tant que prims child.
Je suppose que tu as mis en root (racine, contour jaune à l'édition) la ou une des prims mise en fantôme. Dans ce cas, il est normal que tout l'objet le devienne.

........

Oui. J'avais compris ton message.

J'ai bien mis le prim fantôme en child (contour bleu).

ps : je tourne sur le 1.22.11 car ma carte graphique ne gère pas les versions ultérieures.

[Ma-ya]

Rectificatif :

Je viens de procéder à de nouveaux essais.

Lors des premiers tests, j'ai travaillé sur une plateforme à 3000 mètres de hauteur.
Cette fois ci, j'ai travaillé au sol, et ça a marché.

Peut il y avoir un lien de cause à effet ?

Les scripts sont ils impactés selon que l'on se trouve très haut dans le ciel ou pas ?

[Nibb]

Dis-toi bien que la fonction que tu essaies d'exploiter est un bug. Il n'est donc pas étonnant que le bug soit buggué et que dans certaines conditions, il ne marche plus.

En principe, on ne devrait pas pouvoir lier des prims fantomes avec des prims non-fantimes, et le bug risque un jour d'être corrigé. Si tu mets ça dans un build que tu veux distribuer, il faut en être conscient.

[Polo Slok]

Citation :

Publié par Nibb

Dis-toi bien que la fonction que tu essaies d'exploiter est un bug. Il n'est donc pas étonnant que le bug soit buggué et que dans certaines conditions, il ne marche plus.

En principe, on ne devrait pas pouvoir lier des prims fantomes avec des prims non-fantimes, et le bug risque un jour d'être corrigé. Si tu mets ça dans un build que tu veux distribuer, il faut en être conscient.

Ou bien LL en fera une fonction officielle !

[caterina]

hello,je déterre ce post, car j'ai utilisé ce "nouveau" script pour rendre des childs fantômes (trouvé là : http://wiki.secondlife.com/wiki/Phantom_Child) :

New Functions
New functions brought in with MESH now make setting a child prim to phantom very simple. This can be applied to any number of prims in the linkset, but not the root prim.
default{ state_entry() { llSetLinkPrimitiveParamsFast(LINK_THIS,[ PRIM_PHYSICS_SHAPE_TYPE,PRIM_PHYSICS_SHAPE_NONE]); }}

bon, mais voilà, ce script qui semble idéal car non plus basé sur un bug comme son "ancêtre" semble se comporter de façon bizarre. Je l'ai utilisé pour rendre fantômes des tours de porte (intégrés dans une maison) sculpts de 1 prim chacun(sinon je passais plus la porte ). Avant "intégration" du script dans le premier sculpt la baraque faisait 121prims, après, elle en faisait..135 !!!
bon, pas trop grave, car après "traitement" de 10 tours de porte la maison s'est retrouvée à 135 prims après des hauts et des bas..mais, en bref, ce script "détraque" le comptage de prims..mais enfin, c'est bizarre......

y a t-il une explication dans sa syntaxe ? qu'en pensez-vous, l'utiliseriez-vous néanmoins les yeux fermés dans vos builds ? Je vais tenter, mais ça m'inquiète un peu .

(PS : pour info, ceux que ça intéresse, il faut avec ce script lier d'abord l'élément qui doit devenir fantôme sans le script au reste du build, puis intégrer le script dans son contenu une fois cet élément lié au reste du build.)

caterina

[redpurple]

J ai ma petite idée mais peux tu tester avec ce script .

Code PHP:

reporting()
{
        key key_root = llGetLinkKey(LINK_THIS);
        list results = llGetObjectDetails( key_root, [ OBJECT_PRIM_EQUIVALENCE, OBJECT_SERVER_COST, OBJECT_STREAMING_COST, OBJECT_PHYSICS_COST ]);
        llOwnerSay(llList2CSV(
        [
            "\n",
            "Nombre de prims (suppose non attache ou de personnes assises)", llGetNumberOfPrims(), "\n",
            "Nombre prims equivalents", llList2Integer(results,0), "\n",
            "Nombre cout serveur", llList2Float(results,1), "\n",
            "Nombre cout telechargement", llList2Float(results,2), "\n",
            "Nombre cout physique", llList2Float(results,3)
            ]));    
}
default{ 
    state_entry() 
    { 
        reporting();                
    }
    changed(integer c)
    {
        if ( c & CHANGED_SHAPE )
        {
        reporting();              
        }
        if ( c & CHANGED_SCALE )
        {
        reporting();              
        }        
        if ( c & CHANGED_LINK )
        {
        reporting();              
        }        
    }
    
} 

Normalement , ces attributs avaient été rajoutés plus pour utilisation avec les meshs

Je pense que
lorsque ton objet lié a l ensemble des prims en SHAPE_PRIM ( le type par défaut ) , ton coût affiché est celui du coût serveur .
Le cout serveur est généralement de 1 par prims pour les prims régulières , et de 0.5 par mesh si les meshs ne sont pas scriptées
http://wiki.secondlife.com/wiki/Mesh/Mesh_Server_Weight

En revanche , dès que tu changes le PRIM_PHYSICS_SHAPE_TYPE pour une autre valeur , ton coût affiché est le maximum entre le coût serveur et le coût téléchargement et le coût physique
Or, parmi les prims "classiques" , le coût téléchargement est le plus important pour les prims sculpties et surtout il est très souvent supérieur à 1 qui est le coût serveur ( perso , je n ai jamais vu le coût de téléchargement d un sculptie < 1.8 )
De plus , contrairement à certaines prims comme les cubes , le coût du téléchargement des sculpties peut augmenter rapidement avec la taille.


Exemple :
Dans un ensemble de 9 prims liées étant toutes des cubes , je change la shape d une seule prim :


cout téléchargement pour un cube de 1mx1mx1m = 0.54
cout téléchargement pour un sculptie de 1mx1mx1m = 1.98 ( soit 4 fois plus )
cout serveur = 9 * 1 = 9

cout téléchargement pour un cube de 10mx10mx10m = 0.54
cout téléchargement pour un cube de 10mx10mx10m avec un twist debut -180 , fin 180, et avec un creux = 8.46
cout téléchargement pour un tore torturé avec un twist debut -360, fin 360, et avec un creux en carré et 4 révolutions = 242
cout téléchargement pour un sculptie de 10mx10mx10m = 13.10 ( soit 25 fois plus )
cout serveur = 9 * 1 = 9

( biseautages , et inclinaisons ne semblent pas avoir d impacts sur le coût du téléchargement ; les découpes simplifient la shape , donc ont un impact positif et non négatif sur le coût du téléchargement )
Evidemment , cela peut être très variable suivant la forme de ton sculptie ,

Du coup , ton coût téléchargement devient supérieur à ton coût serveur, et ton coût affiché devient le coût du téléchargement

Solution de contournement si tu veux changer l attribut type de forme physique :
soit faire une approximation du sculptie en une shape plus simple , comme un cube , si possible non twisté
soit changer le sculptie en mesh afin d optimiser le nombre de triangles

[caterina]

Merci Red je teste ce nouveau script dès ce soir ! Merci aussi pour l'explication.

c'est vrai que j'ai fait du bidouillage, vu que j'ai utilisé un truc fait pour les meshes avec des sculpts.

compte-rendu à venir après le test.

edit à 22:25 :

alors effectivement, quand j'insère le script ci-dessus dans un sculpt child lié au build, j'obtiens ceci dans le chat :

", Nombre de prims (suppose non attache ou de personnes assises), 131,
, Nombre prims equivalents, 135,
, Nombre cout serveur, 131.000000,
, Nombre cout telechargement, 103.979286,
, Nombre cout physique, 134.603668"

si je l'insère dans un autre sculpt child lié au buid, itou. ce qui est bizarre, c'est que au final je n'obtienne pas le coût téléchargement pour le build, mais le coût physique..intéressant.

Cela dit, pour le moment je "perds" 4 prims, car avec 10 portes sculptées à 1 prim ajoutées, j'aurais dû avoir au final 131 prims, et pas 135..j'ai bien essayé de transformer le tour de porte sculpt en boite, je me suis retrouvée avec une pyramide...!!quant au meshes je n'ai même pas idée du mode de fabrication. !!! Ce script devrait si j'ai bien compris rester stable dans la durée (pas comme son prédecesseur) alors il me semble préférable de l'utiliser plutôt que "l'ancêtre" reposant sur un bug.

merci Red Purple en tout cas car j'étais loin d'être consciente de ces calculs de prims..je serais plus vigilante à l'avenir concernant les sculpts à intégrer, et leurs dimensions

caterina

[redpurple]

Oh . c est donc le cout physique et non le cout de téléchargement qui fait augmenter ton cout final .

Dans ce cas , soit tu positionnes d autres prims que celle de ton sculptie et de ta prim root en attribut PRIM_PHYSICS_SHAPE_TYPE = PRIM_PHYSICS_SHAPE_NONE , soit en attribut PRIM_PHYSICS_SHAPE_TYPE = PRIM_PHYSICS_SHAPE_CONVEX
C est aussi positionnable dans l onglet attribut de la fenetre d edition de la prim .

Si tu positionnes une prim en PRIM_PHYSICS_SHAPE_NONE , cela va faire automatiquement baisser son cout physique . Donc la somme totale du cout physique de l objet lié va baisser aussi .
Mais , ta prim laissera passer les gens à travers . Cela tu le savais déjà

Si tu positionnes une prim en PRIM_PHYSICS_SHAPE_CONVEX , cela peut faire baisser son cout physique, mais pas toujours. Fais le par exemple sur les objets twistés , ou creux . Il faut tester pour savoir si cela le fait .
En revanche , cela empêche de passer à travers .

Etant donné que ton cout de téléchargment , li , n est qu a 100 , il peut être un peu augmenté sans que cela fasse augmenter le cout total


Exemple :
tu as 10 prims sculpties , 10 prims en cube . ( testé avec des prims de 0.5*0.5*0.5 par défaut )
L un des cube est twisté ( debut 180 , fin 180 )

Le cout sans aucune modificatation est de 20 prims . 1 par prim

Mais tu désires mettre un sculptie en phantome de la facon dont tu as décrite .
Dans ce cas , c est le cout max des 3 couts qui sera affiché
on a par exemple
cout téléchagement 14.4
cout physique 25.5
cout serveur 10.0
Donc cout affiché = 26

Si tu passes toutes les prix en PRIM_PHYSICS_SHAPE_CONVEX , sauf ton sculptie que tu laisses a PRIM_PHYSICS_SHAPE_NONE tu as
cout téléchagement 14.4
cout physique 18.1
cout serveur 10.0
Donc cout affiché = 18

Non seulement tu ne perds pas plus , mais tu as gagné 2 prims par rapport à l existant

En tout cas , ces calculs de prims ne sont nécessaires uniquement quand tu modifies l attribut PRIM_PHYSICS_SHAPE_TYPE d une des prims de ton objet lié

[caterina]

Alors tout ça m'amène aux conclusions suivantes :

eh ben non justement, je ne connaissais pas le coût des attributs, je ne connaissait pas ce menu de changement de "shape" ! Du coup, l'utilité de ce script que j'avais utilisé pour ne mettre que certains prims (les 10 sculpts) en fantômes m'a parue remise en question.....puisqu'il suffirait de mettre la shape en none du prim pour pouvoir passer à travers !

alors voici ce que j'ai fait :

1/j'ai ôté le script partout où je l'avais mis et passé un coup de scrubber,

2/ j'ai mis la maison entière en shape CONVEX;

là, ton script compteur m'a indiqué ceci (entre temps le nombre de prims en cliquant sur la maison était descendu à 104, donc le coût de téléchargement):

[11:34] tour de porte fp:
, Nombre de prims (suppose non attache ou de personnes assises), 131,
, Nombre prims equivalents, 131,
, Nombre cout serveur, 131.000000,
, Nombre cout telechargement, 103.979286,
, Nombre cout physique, 57.279884

3/ Ensuite, j'ai remis un par un les 10 sculpts en shape NONE

là, le script compteur a indiqué ceci (le nombre de prims en cliquant sur la maison était alors passé à 131 !):

[11:39] tour de porte fp:
, Nombre de prims (suppose non attache ou de personnes assises), 131,
, Nombre prims equivalents, 131,
, Nombre cout serveur, 131.000000,
, Nombre cout telechargement, 103.979286,
, Nombre cout physique, 40.719959

(c'est tout de même bizarre que dans les 2 cas ont ait les 4 premières lignes identiques, et le nombre global de prims qui changent tout de même quand on clique sur le build...)

Je m'estime satisfaite par cette dernière "configuration", car elle m'a permis de revenir au nombre "normal" de prims attendus soit 121 avant sculpties + 10 prims de sculpties = 131.

Et, en prime, j'ai évacué l'option d'emploi du script (mais dans ce cas pourquoi les gens se sont évertués à écrire des scripts pour passer à travers certains prims d'un build, alors qu'il suffit de mettre la shape en NONE ??? )

un grand merci pour toutes ces infos, RedPurple

caterina

[billouSlade]

Bonjour, justement l'inverse, j'aimerais que le fantôme soit le root et pas les autres ... comment faire ?

[redpurple]

Je ne vois bien ton besoin , peux tu détailler ?
J ai plus l impression que tu te fais des noeuds au cerveau inutilement : tu delinkes l objet , tu le relinkes en changeant l ordre du linkage donc la prim root
Si ce n est pas ce que tu veux , peux tu expliquer davantage le contexte ?

[billouSlade]

j’explique plus clairement ...
1 - un prim en forme de cône : fantôme, un script dedans de collision qui le rend glow
2 - un prim plat décalé : non fantôme,
Lier les deux fait que le prim 2 fait office de déclencheur.

heuuu est ce plus clair ?

[redpurple]

Pas franchement .
D une part , une prim phantom ne déclenche pas de collisions .
En revanche tu peux avoir une prim qui laisse passer des objets et qui déclenchera des collisions en jouant avec la fonction llvolumedetect
et cela ne détectera que les collision_start et collision_end , pas les collision
Mais tout ton objet laissera passer les objets ( de la même facon que si il etait phantome ) si tu mets le script positionnant llvolumedetect dans la prim root

Donc qu est ce qui t empêche que ce soit ton cone qui soit la prim child et ta prim plate qui soit la prim root ?


Exemple :

tes 2 objets sont déliés

puis
dans ta prim plate rentrer le script

Code PHP:

default
{
    state_entry()
    {
        llSetStatus( STATUS_PHANTOM, FALSE );
        llVolumeDetect( FALSE );
    }

    collision_start(integer n)
    {
        llOwnerSay(llList2CSV(
        [ 
           "link" ,llDetectedLinkNumber(0)
           
        ]));
    }
} 

dans ton cone

Code PHP:

default
{
    state_entry()
    {
        llSetStatus( STATUS_PHANTOM, FALSE );
        llVolumeDetect( TRUE );
        llPassCollisions(FALSE);
    }
} 

Lier ton cone puis ta prim plate ( donc ta prim plate est la root )


SI tu as besoin de svaoir qui a été touché , llDetectedLinkNumber renverra 0 si c est la prim child ( c est la valeur qui est retournée pour toutes les prims qui sont en llvolumedetect , indépendamment de son numéro de link)
et renverra 1 si c est la prim root

Penser à délier puis relier a chaque fois que llSetStatus est ré -exécuté , sinon le comportement de collision se comportera uniformément sur tout l objet .

Ceci dit , c est une faiblesse de design de lier ensemble des prims qui ont un gestionnaire de collisions différent au sein du même objet .

As tu vraiment intéret à lier ces deux objets ? Surtout qu a ce que tu me diis , la prim plate ne fait strictement rien , ne réagit pas à des évenements ..
En quoi elle fait office de "déclencheur" ?

[billouSlade]

je te contacte par MP ^^

[billouSlade]

Je vais essayer d’être plus précis dans ma demande :

Ma recherche :
Allumer un prim en glow au passage d'un avatar pour mettre en valeur un objet. Dans votre boutique, vous avez un superbe fauteuil et vous aimeriez qu'il soit en lumière, mais juste au passage d'un visiteur ...

Contrainte :
Le prim glow dois être fantôme pour laisser le libre passage.

-j'étais parti sur un script collision, il me semble avoir lu que les script sensor donnais du lag ... maintenant je suis positivement nul en script ^^-

Est ce plus précis ?

[Elenia Boucher]

Je n'ai malheureusement plus de sim pour faire les tests, mais je suis sure qu'un sensor toutes les 5 secondes sera moins laggy qu'un détecteur de collision.

En effet, un détecteur à collision scanne en permanence lui. Enfin pas vraiment, mais à la fréquence maximale que permet le système, disons toutes les 0.01 secondes par exemple.

Les sensors ont la réputation d'être laggy parce qu'on en a abusé à fréquence haute (scan toutes les 0.04 secondes par exemple), en particulier dans les radars personnels d'avatar.