colorisation de certains prims et pas d'autres

Répondre
 
Partager Rechercher
salut,
j'ai un objet composé de 20 prims, on va dire

je voudrais savoir comment faire pour dire à 10 prims de changer de couleur sans que les autres changent

merci d'avance.
Lien direct vers le message - Vieux 09/06/2007, 15h00
oups oui c'est ma faute j'ai oublié un truc, je recommence


salut,
j'ai un objet composé de 20 prims, on va dire

je voudrais savoir comment faire pour dire à 10 prims de changer de couleur sans que les autres changent , avec un script, en fait je voudrais savoir si il existe une commande du genre:
llSetColor(<0.5, 0.5, 0.5>, ALL_SIDES);

merci d'avance.
Lien direct vers le message - Vieux 09/06/2007, 17h13
tu viens de donner la commande
y a aussi llSetLinkColor(), mais il faut connaître le numéro du prim dont on veut changer la couleur.

Il te faut juste la mettre dans un script, et mettre ce script dans chacune des prims qui doivent changer de couleur

Le choix de comment donner l'ordre de changer de couleur te revient, mais ça passera un script qui va recevoir l'ordre dans le prim 0, et qui le transmettra par llMessageLinked() / link_message() vers les scripts des prims,.

Parce que mettre 20 llListen(), un par script, c'est aussi coûteux en ressources serveur, qu'inélégant.
Lien direct vers le message - Vieux 09/06/2007, 18h11
Citation :
nope, tu as llSetLinkColor() mais faut connaître le numéro des prims concernées, et prier pour que ça ne change pas
Ou alors tu généres ta liste à la volée en utilisant, par exemple le nom de chaque prim qui devra être altéré dans un ensemble.

Petit exemple :
* donner un même nom à tous les prims qui devront être modifiés et seulement eux. Pour l'exemple, je vais mettre "colorA" ;
* mettre le script suivant dans un prim ;
Citation :
integer switch=0;
string name2list="colorA";
list primsList=[];

fonctionColorMe(vector color)
{
integer count;
for(count=0;count<llGetListLength(primsList);count++)
{
llSetLinkColor(llList2Integer(primsList,count),color,ALL_SIDES);
}
}

default
{
state_entry() {
// L'objet est rez, on cree la liste
integer count;
for(count=1;count<=llGetNumberOfPrims();count++)
{
if(llGetLinkName(count) == name2list) {
primsList= [] + primsList + count;
}
}
}

touch_start(integer touched)
{
if(switch!=1) {
fonctionColorMe(<1.00,0.00,0.00>);
switch=1;
}
else {
fonctionColorMe(<0.00,1.00,0.00>);
switch=0;
}
}
}
Je ne l'ai pas testé, mais sur le principe ça marche très bien. Dans le pire des cas, si le link change, il suffit de prendre l'objet et de le rez de nouveau. Il est possible de mettre un évent qui détecte la modification de link mais lorsque l'on travaille c'est assez lourd inutilement car le script travaillera à la moindre modification du build.

[edit] Correction de l'organisation des parenthèses et d'une erreur de variable.
Lien direct vers le message - Vieux 09/06/2007, 23h13
ha vi... pas mal du tout ça, j'y avais pas pensé

Vu que j'ai l'habitude d'utiliser un petit système de scripts, basé aussi sur les noms, et sur les canaux des link_message(), et qui permet de tout changer par script, y compris la forme du prim, les textures etc.
Lien direct vers le message - Vieux 10/06/2007, 14h31
Scripter low-lag
La solution de Llew est plus favorable sur le plan du lag. Elle évite 10 scripts, et il faut savoir une chose: un script qui ne fait rien consomme du CPU. Le scripteur responsable doit se préoccuper de l'impact de son travail sur le lag. 10 scripts c'est peu, mais multiplié par 10 copies de l'objet c'est 100. C'est d'autant plus vrai que le scripter vend ses créations. Certains attachements comptent des centaines de scripts dont la plupart sont inutiles. On arrive ainsi à des sims qui exécutent 5000 scripts et qui rament. Voici en vrac quelques-unes des mesures anti-lag:

- Plutôt que de mettre un script dans chaque prim pour changer la couleur ou la transparence, utiliser les fonctions llSetLinkColor, llSetLinkAlpha, llSetLinkTexture, llSetLinkPrimitiveParams. Vous pouvez gagner des centaines de scripts ainsi et diminuer d'autant l'impact sur le simulateur. J'en sais quelque chose, je suis dragon et j'ai environ 350 scripts inutiles dans mes écailles car mon costume a été réalisé avant que ces fonctions n'existent. En donnant des noms différents aux prims qui constituent un objet, on peut facilement les adresser par programmation.

- Utiliser llMessageLinked au lieu de llSay/llListen partout où c'est possible. Lorsqu'on ne peut pas faire autrement qu'utiliser llListen pour parler à un objet, éviter le canal public (0). Réduire la période d'écoute au strict minimum (llListenControl).

- Effacer les scripts dont le seul effet est de fixer une propriété persistente du prim (llSetText, llSitTarget, llSetTouchText, llTargetOmega). La propriété est mémorisée, ils ne servent à rien.

- Désactiver les scripts qui ne servent à rien (llSetScriptState) et les réactiver lorsqu'on en a besoin. Désactivés, ils ne consomment plus de CPU.

Scripteurs, scripteuses, on vous ment (zut, erreur de texte)... ne contribuons pas au lag. Apprenons à scripter low-lag.
Lien direct vers le message - Vieux 10/06/2007, 16h41
Bonjour,

L'un(e) de vous a-t'il eu l'occasion de tester l'impact des fonctions mail sur le lag ? llGetNextEmail() est-il moins,aussi, plus pénalisant que les llListen() ? Les temps de réponse sont plus longs qu'avec les autres fonctions de communication mais c'est plus lié à la nature de la fonction que relatif au lag il me semble.

Bon script !
Lien direct vers le message - Vieux 10/06/2007, 17h15
Citation :
L'un(e) de vous a-t'il eu l'occasion de tester l'impact des fonctions mail sur le lag ? llGetNextEmail() est-il moins,aussi, plus pénalisant que les llListen() ? Les temps de réponse sont plus longs qu'avec les autres fonctions de communication mais c'est plus lié à la nature de la fonction que relatif au lag il me semble.

Bon script !
Les communications par mails sont plutot destinées à d'autres applications. Déjà il est obligatoire d'avoir la clef de la cible, ce qui est assez pénible (on peut passer un integer lors d'un rez, mais pas une key). Ensuite l'émission provoque un arrêt d'exécution du script durant 20s, obligeant à faire du multithreading pour avoir fonctionnement régulier. La transmition des mails peut être assez lente, donc dans le cas d'une télécommande, mieux vaut encore un listen à première vue, quite à faire un dispatching avec des llMessageLinked() derrière.

En revanche, je suis en train de bosser sur un système de commande inter-SIM avec un serveur et pour certaines applications j'utilise la forte capacité des mails (4096 caractères, tout compris) pour stocker plusieurs instructions et les transmettre en bloc : en gros mes commandes qui ne nécessitent pas une application immédiate (des modifications de configuration par exemple) sont stockées dans une variable tampon et sur validation, le tout est transformé en un unique mail, envoyé, puis redécoupé en commandes exécutées séquentiellement et distribuées entre les scripts via llMessageLinked. Dans ce cas, le mail peut être très pratique et avantageux en nombre d'opérations mais il a des contraintes assez lourdes, dont celle de devoir avoir un système qui teste la réception régulièrement via llSetTimerEvent(), qui lui est un générateur de lag.

Concernant l'apport de lag par les llListen, il faut savoir une chose : ce qui est générateur de lag supplémentaire est leur détection de données entrantes. Pour réduire ça il vaut mieux limiter l'entrée de donnée à un AV donné et fermer un listen qui n'est pas nécessairement actif à plein temps.

Ensuite, choisir un canal négatif, pour les transferts entre scripts et tant qu'à faire un numéro au hasard qu personne ne prendra par affinité : la plage s'étend de 1 à 2.147.483.648, en positif et en négatif, donc tomber sur le même que quelqu'un d'autre est assez ... difficile si on prend un nombre sans aucune connotation.
Lien direct vers le message - Vieux 10/06/2007, 19h16
Citation :
Publié par Jeff Kelley
un script qui ne fait rien consomme du CPU.
un script qui ne fait rien... peux-tu qualifier ne rien faire?
parce que ce que tu as dit est globalement faux.

un script en attente d'événement fait quelque chose, il attend, mais n'occupe pas le CPU, puisqu'il est mis en attente d'événement par le scheduler, et ne sera réveillé que si la condition attendue est effective.
un script qui est endormi par llSleep(), ne fait rien, mais n'occupe pas le CPU, c'est le but de llSleep(), il est mis en pause par le scheduler, et sera réveillé dès que la pause est finie

On peut imaginer des circonstances où un script ne ferait réellement rien, mais utiliserait du CPU, mais c'est très complexe à faire, puisque le but du jeu du scheduler et du noyau, c'est d'éviter tout process qui utiliserait le CPU pour attendre, et donc il faudrait truander sérieusement pour faire croire qu'on fait quelque chose alors qu'on ne fait rien

Citation :
- Plutôt que de mettre un script dans chaque prim pour changer la couleur ou la transparence, utiliser les fonctions llSetLinkColor, llSetLinkAlpha, llSetLinkTexture, llSetLinkPrimitiveParams. Vous pouvez gagner des centaines de scripts ainsi et diminuer d'autant l'impact sur le simulateur. J'en sais quelque chose, je suis dragon et j'ai environ 350 scripts inutiles dans mes écailles car mon costume a été réalisé avant que ces fonctions n'existent. En donnant des noms différents aux prims qui constituent un objet, on peut facilement les adresser par programmation.
Le problème des fonctions link, c'est qu'elles changent les couleurs, et textures, les unes après les autres, et si la sim est chargée, ça peut être lent, si l'effet voulu est un changement progressif de couleur, pourquoi pas.
Si le but c'est de tout changer d'un coup, les 350 scripts individuels, qui seront sur attente de link-Message(), c'est mieux, tout en consommant autant de ressources CPU (petit calcul sur les fonctions appellées et executées, très simple à faire).

Citation :
- Effacer les scripts dont le seul effet est de fixer une propriété persistante du prim (llSetText, llSitTarget, llSetTouchText, llTargetOmega). La propriété est mémorisée, ils ne servent à rien.
Ces scripts étant inactifs une fois exécutés, ils n'ont aucun impact sur la charge CPU, les supprimer ne sert qu'à alléger la mémoire, et encore.

Citation :
- Désactiver les scripts qui ne servent à rien (llSetScriptState) et les réactiver lorsqu'on en a besoin. Désactivés, ils ne consomment plus de CPU.
désactivés, en attente d'événement, en mode sleep, un script ne consomme du CPU que si il fait quelque chose, inutile de désactiver un script qui attend un message_link(), il ne consomme pas de CPU, par exemple.

Citation :
Scripteurs, scripteuses, on vous ment (zut, erreur de texte)... ne contribuons pas au lag. Apprenons à scripter low-lag.
Bonne idée, pour cela, commençons par apprendre comment fonctionne un noyau et un scheduler
Lien direct vers le message - Vieux 11/06/2007, 02h06
Citation :
Publié par Christine Etchegaray
Bonjour,

L'un(e) de vous a-t'il eu l'occasion de tester l'impact des fonctions mail sur le lag ? llGetNextEmail() est-il moins,aussi, plus pénalisant que les llListen() ? Les temps de réponse sont plus longs qu'avec les autres fonctions de communication mais c'est plus lié à la nature de la fonction que relatif au lag il me semble.

Bon script !
Il n'y a pas d'événement 'mail reçu', du coup tu es obligé d'utiliser un timer pour pouvoir vérifier tes messages, et comme tu as des délais intégrés aux fonctions du mail, ça tourne vite à l'usine à gaz, outre les soucis pour avoir des keys d'objets fixes.

J'ai du utiliser les mails pour des communications entre objets, et dès que j'ai un PC qui me permet de remettre les pieds sur SL, je vire l'usine à gaz pour passer à llRegionSay(), le mail ne servira que pour des échanges entre sims

Les vrais scripts bouffeurs de CPU et qui maximisent le lag...
ce sont ces foutus script de pose ball qui apparaissent et disparaissent sur commande vocale sur le canal 0.
Et comme il peut y en avoir des milliers sur une sim...

Y a aussi les scanners en tout genre...
Lien direct vers le message - Vieux 11/06/2007, 02h16
j'en connais une qui m'a un jour appelé pour ça...
toutes ses pose-balls avaient disparu

et y en avait une bonne centaine, c'était juste quelqu'un qui avait du faire un shout, et le temps de capter que c'était ces foutues pose-balls avec listen sur le canal 0...
ça a fait couler de la sueur
Lien direct vers le message - Vieux 11/06/2007, 13h43
En gros d'après le forum SL section script, l'observation pragmatique a montré qu'un script avec juste un évènement state_entry() "running" occupe du CPU (si case runnig décochée non)

Voilà voilà ! ma modeste contribution à un débat d'expert.

Bises.
Lien direct vers le message - Vieux 11/06/2007, 19h45
Citation :
Publié par master71
forum inaccessible si tu n'as pas d'info de CB... essaye encore
Toutes mes excuses, je n'avais pas pensé à ça. Il s'agit d'une longue discussion intitulée

«Les scripts "dormants" ne sont pas aussi dormants que vous le croyez».

Lex Neva y expose ceci: «J'ai fait des tests intensifs et je suis parvenu à cette conclusion: des scripts dormants, totalement inactifs, prennent un temps significatif de processeur.»

Suit un exposé très détaillé. La méthode est discutée, en particulier pas Eloise Pasteur, mais semble tenir la route. Talarus Luan avance une explication plausible (basée sur des supputations puisqu'on ne dispose pas du code source) : Les scripts en attente d'évènement imposent un "overhead" système (charge additionnelle) du à l'algorithme de traversée des files d'attente. Les expériences de Lex sont recoupées par Cenji Neutra et Argent Stonecutter. Même si j'ai une assez grande confiance en des programmeurs comme Lex, Talarus ou Argent, j'ai fait mes expériences, et j'arrive à la même conclusion. Je dispose des estate tools qui me permettent de voir le temps CPU script par script.

Depuis cette discussion, d'autres confirmations ont été apportées et la politique du forum est de conseiller, partout où c'est possible, l'usage de llSetLinkXXXX à la place d'un script par prim. Talarus et Daryth envisagent d'ailleurs une nouvelle version des dragons qui sont des monstres de lag précisément à cause des 300-500 scripts dormants pour changer les couleurs.

Si ce constat est vrai, ce dont je ne doute pas aujourd'hui, il serait irresponsable de recommander de mettre un prim dans chacun de 70 flexis d'une coiffure juste pour changer de teinte une fois par jour.
Lien direct vers le message - Vieux 11/06/2007, 20h02
ça, la charge additionnelle de tri / gestion des files d'attente d'événement, c'est possible si c'est fait comme un pied, et j'aurais du y penser
Mais ce n'est pas le script en lui-même qui bouffe du CPU
Lien direct vers le message - Vieux 11/06/2007, 22h08
Dire qu'un script bouffe du CPU est un raccourci pour dire qu'il en fait bouffer à son environnement d'exécution (overhead). Fin de cette digression de spécialistes. Ce qui me semble important est de faire passer le message dans ce forum: si vous êtes un scripteur responsable, attention à ne pas multiplier inconsidérément vos scripts.
Lien direct vers le message - Vieux 11/06/2007, 23h59
Citation :
Publié par Llew Iredell
Ou alors tu généres ta liste à la volée en utilisant, par exemple le nom de chaque prim qui devra être altéré dans un ensemble.

Petit exemple :
* donner un même nom à tous les prims qui devront être modifiés et seulement eux. Pour l'exemple, je vais mettre "colorA" ;
* mettre le script suivant dans un prim ;


Je ne l'ai pas testé, mais sur le principe ça marche très bien. Dans le pire des cas, si le link change, il suffit de prendre l'objet et de le rez de nouveau. Il est possible de mettre un évent qui détecte la modification de link mais lorsque l'on travaille c'est assez lourd inutilement car le script travaillera à la moindre modification du build.
ça ne marche pas
Lien direct vers le message - Vieux 12/06/2007, 13h29
integer switch;
string name2list="colorA";
list primsList

fonctionColorMe(vector color)
{
integer count;
for(count=0;count<llGetListLength(name2list);count++) {
llSetLinkColor(llList2Integer(primsList,count),color,ALL_SIDES);
}
}

default
{
on_rez(integer rezed) {
// L'objet est rez, on cree la liste
integer count;
for(count=0;count<llGetNumberOfPrims();count++) {
if(llGetLinkName(count) == name2list) {
primsList= [] + primsList + count;
}
touch_start(integer touched)
{
if(switch!=1) {
fonctionColorMe(<1.00,0.00,0.00>);
switch=1;
else {
fonctionColorMe(<1.00,0.00,0.00>);
switch=0;
}
}
}
ça ne marche pas, ça me donne une erreur ici: for(count=0;count<llGetListLength(name2list);count++)
Lien direct vers le message - Vieux 13/06/2007, 10h26
Répondre

Connectés sur ce fil

 
1 connecté (0 membre et 1 invité) Afficher la liste détaillée des connectés
Thème visuel : Fuseau horaire GMT +2. Il est actuellement 17h40.
^^ Haut de page ^^