[Nexus763]

Euh, elles sont belles vos fonctions Fast et llSetLinkPrimitivesParams, mais elles sont fonctionnelles ? J'ai essayé et le compilateur connait pas ces fonctions ....

[Ahuri Serenity]

llSetLinkPrimitivesParams existe depuis très longtemps ... en Fast par contre c'est nouveau et là il faut juste avoir ton simulateur à jour c'est tout. Moi partout où j'ai essayé c'était installé.

[Nexus763]

Je suis là où il faut pas alors.
Merci de l'info

[black cats]

Citation :

Publié par Nexus763

Je suis là où il faut pas alors.

C'est pas implanté sur Zindra

[Nexus763]

Ah, Et c'est quoi Zydra ?

Je suis sur la grid "de base" si on peut la désigner ainsi. J'ai Kirsten s20. J'essaie de compiler le script contenant des fonctions "fast" sur différentes sim et cela ne marche pas.

Où ske cé ke je m'a gouré ?
{cintacse}
{aurtaugrafe}
{qu'on jugue et zon}

[black cats]

Tu peux aussi essayer le mot clé Ursula - la fonction recherche est ton amie.
Mais rassure toi, nul besoin d'avoir entendu parler de Zindra pour faire des scripts qui marchent.

[black cats]

Citation :

Publié par bestmomo

Je suis d'accord avec ça, on est perdant

Finalement, je n’en suis plus si sur que ça.
Je marche un peu sur des œufs à ce niveau là, car c’est vraiment pas mon domaine. Donc à vous les informaticiens de me corriger si je dis une grosse bêtise.
J’ai une idée plus que vague des algorithmes utilisés pour calculer des fonctions non linéaires tels que sinus, arcsinus, racine carrée etc. Mais je pense que ça nécessite un nombre relativement élevé de multiplications et d’additions. Donc, deux opérations non linéaires (2 racines carrées si je compte llVecMag(dprod)) d’un côté, deux de l’autre (sinus et arcsinus).
Bon, de toute façon, je pense qu’on chipote sur pas grand chose.

Le double produit vectoriel dprod = (k1%uz)%uz , dans la mesure où le calcule se fait par les coordonnées, ne nécessite que quleques multiplications et additions.

Citation :

Publié par bestmomo

la simple trigo l'emporte sans problème comme bien souvent. Et même notre bon vieux Pythagore doit encore tenir la route, c'était d'ailleurs mon option lorsque j'ai écrit mon script .

C’était la mienne aussi, au départ.

Une fois qu’on a fait un schéma à peu près propre, on a immédiatement les équations qui donnent les paramètres de position de la bielle, et du piston (voir schéma).
En introduisant le point Q de manière à avoir deux triangles rectangles, on a
Pour le triangle ABQ distance(BQ) = e*sin(alpha) distance(AQ) = e*cos(alpha)
Pour le triangle BCQ distance(BQ) = -L*sin(beta) distance(QC) = L*cos(beta)
(signe « moins » de -L*sin(beta) parce que beta est négatif.)

D’où e*sin(alpha) = -L*sin(beta)
Et distance(AC) = e*cos(alpha) + L*cos(beta)

De plus, cette méthode a l’avantage d’être accessible au plus grand nombre, la seule difficulté étant de poser proprement le probème.

Ce qui m’a incité à chercher une méthode un peu plus élégante, est ta remarque suivante. Pour la beauté de la chose seulement, sans croire à un réel intérêt pratique au départ :

Citation :

Publié par bestmomo

Je pensais pouvoir introduire une notion de contrainte pour éviter les cos et sin (…)

Mais aussi, plus récemment :

Citation :

Publié par bestmomo

En particulier sur la manipulation des vecteurs qui simplifie énormément les calculs.

Finalement, la formulation de ce que tu as appelé « contrainte » par un produit vectoriel, plutôt qu’un produit scalaire, ou la trigonométrie dans le plan, a tout de même un énorme avantage :

Elle est valable dans l’espace, et pas seulement dans le plan

Les instructions

Code PHP:

     vector dprod = (k1%uz)%uz; //double produit vectoriel
     float mu = llSqrt(L*L - e*e*llVecMag(dprod));
     vector k2 = (e/L)*dprod + mu*zu; 

sont indépendantes de la base utilisée pour exprimer les vecteurs k1 et zuz.
Par conséquent, une fois que l’orientation quelconque de la prim racine a été réglée pour les vecteurs k1 et uz, l’expression de k2 ci-dessus reste valable quelque soit l’orientation de la prim racine.

Au bout du compte, on arrive à quelque chose qui fait penser à du calcul formel, et je dirais +1000 à ta remarque sur la « la manipulation des vecteurs qui simplifie énormément les calculs ».

[black cats]

Voilà le script que j'ai utilisé dans la vidéo précédente.

Code PHP:

//bielle-manivelle (18a) solution vectorielle 


//------------ parametres de mouvement -------------
float periode = 7.0;  //periode en secondes
float dt      = 0.05;  //increment temporel 
//--------------------------------------------------
integer N;     //nb de pas par tour

//------------------ dimensions --------------------
vector OA  = <0.4,  0.0, -0.8>;
vector OAv = <0.15, 0.0, -0.8>;

float e = 0.5;   //excentricite
float Zv = 0.2;  //coord du centre du vilebrequin

float L = 1.0;   //longueur de bielle
float Zb;  //coord du centre de bielle

float Zp = 0.2;   //coord du centre du piston
//--------------------------------------------------

vector ux0 = <1.0, 0.0, 0.0>;
vector uz0 = <0.0, 0.0, 1.0>;
vector uz; // en coordonnees 

rotation rootrot;

integer ON;
integer i;

integer VILEBREQUIN = 2;
integer BIELLE      = 3;
integer PISTON      = 4;
integer AXE_B       = 5;
integer AXE_C       = 6;

float delai;
float alpha0;


bouger()
{
   float alpha = i * alpha0;
   rotation rot_alpha = llEuler2Rot(alpha * ux0);
   rotation rot_v = rot_alpha/rootrot;  
   vector k1 = (uz0*rot_v)*rootrot;

   vector dprod = (k1%uz)%uz;
   vector k2 = (e/L)*dprod + llSqrt(L*L - e*e*llVecMag(dprod))*uz;
   rotation rot_b = llRotBetween(uz, k2)/rootrot;

   vector pos_v = OAv + Zv*k1;        //position vilebrequin
   vector OB    = OA  + e *k1;
   vector pos_b = OB  + Zb*k2;        //position bielle
   vector OC    = OB  + L*k2;
   vector pos_p = OC  + Zp*uz; //position piston

   list params_v = [PRIM_POSITION, pos_v, PRIM_ROTATION, rot_v];
   list params_b = [PRIM_POSITION, pos_b, PRIM_ROTATION, rot_b];
   list params_p = [PRIM_POSITION, pos_p ];
   llSetLinkPrimitiveParamsFast(VILEBREQUIN , params_v );
   llSetLinkPrimitiveParamsFast(BIELLE      , params_b );
   llSetLinkPrimitiveParamsFast(PISTON      , params_p );
   llSetLinkPrimitiveParamsFast(AXE_B       , [PRIM_POSITION, OB]);
   llSetLinkPrimitiveParamsFast(AXE_C       , [PRIM_POSITION, OC]);
}


init()
{
   ux0 = llVecNorm(ux0);
   uz0 = llVecNorm(uz0);
   rootrot = llGetRot();
   OA =  (OA*rootrot)/rootrot;  
   OAv = (OAv*rootrot)/rootrot; 
   uz =  (uz0*rootrot)/rootrot; 
   N = (integer)(periode/dt);
   alpha0 = TWO_PI/N;
   Zb = L/2;
}


default
{
   state_entry()
   {
   init();
   bouger();
   }

   touch_start(integer n)
   {
   ON = (!ON);
   if (ON) init();
   llSetTimerEvent(dt*ON);
   }

   timer()
   {
   i = (i+1)%N;
   bouger();
   }
} 

[black cats]

Un autre avantage considérable de la méthode "vectorielle", est qu'avec quelques modifications mineures du script précédent, on peut obtenir des mouvements tridimensionnels tels que ceux que l'on peut voir ci-dessous :

Le mouvement de la bielle est plus complexe. Je ne sais pas si c'est très visible, mais son inclinaison par rapport au plan principal varie au cours du mouvement.

Je vous laisse jouer au jeu des sept erreurs pour trouver les différences avec le script précédent.

Code PHP:

//bielle-manivelle (18) mouvement tridimensionnel de la bielle


//------------ parametres de mouvement -------------
float periode = 7.0;  //periode en secondes
float dt      = 0.05;  //increment temporel 
//--------------------------------------------------
integer N;     //nb de pas par tour

//------------------ dimensions --------------------
vector OA  = <0.4, 0.0, -0.8>;
vector OAv = <0.15, 0.0, -0.8>;

float e = 0.5;   //excentricite
float Zv = 0.2;  //coord du centre du vilebrequin

float L = 1.0;   //longueur de bielle
float Zb;  //coord du centre de bielle

float Zp = 0.2;   //coord du centre du piston
//--------------------------------------------------

vector ux0 = <1.0, 0.0, 0.0>;
vector uz0 = <0.0, 0.0, 1.0>;
vector ut0 = <0.5, 0.0, 1.0>;
vector uz; // en coordonnees 
vector ut; // globales

rotation rootrot;

integer ON;
integer i;

integer VILEBREQUIN = 2;
integer BIELLE      = 3;
integer PISTON      = 4;
integer AXE_B       = 5;
integer AXE_C       = 6;

float delai;
float alpha0;


bouger()
{
   float alpha = i * alpha0;
   rotation rot_alpha = llEuler2Rot(alpha * ux0);
   rotation rot_v = rot_alpha/rootrot;  
   vector k1 = (uz0*rot_v)*rootrot;

   vector dprod = (k1%ut)%ut;
   vector k2 = (e/L)*dprod + llSqrt(L*L - e*e*llVecMag(dprod))*ut;
   rotation rot_b = llRotBetween(uz, k2)/rootrot;

   vector pos_v = OAv + Zv*k1;        //position vilebrequin
   vector OB    = OA  + e *k1;
   vector pos_b = OB  + Zb*k2;        //position bielle
   vector OC    = OB  + L*k2;
   vector pos_p = OC  + Zp*ut;        //position piston

   list params_v = [PRIM_POSITION, pos_v, PRIM_ROTATION, rot_v];
   list params_b = [PRIM_POSITION, pos_b, PRIM_ROTATION, rot_b];
   list params_p = [PRIM_POSITION, pos_p ];
   llSetLinkPrimitiveParamsFast(VILEBREQUIN , params_v );
   llSetLinkPrimitiveParamsFast(BIELLE      , params_b );
   llSetLinkPrimitiveParamsFast(PISTON      , params_p );
   llSetLinkPrimitiveParamsFast(AXE_B       , [PRIM_POSITION, OB]);
   llSetLinkPrimitiveParamsFast(AXE_C       , [PRIM_POSITION, OC]);
}


init()
{
   ux0 = llVecNorm(ux0);
   uz0 = llVecNorm(uz0);
   ut0 = llVecNorm(ut0);
   rootrot = llGetRot();
   OA =  (OA*rootrot)/rootrot;  
   OAv = (OAv*rootrot)/rootrot; 
   uz =  (uz0*rootrot)/rootrot; 
   ut =  (ut0*rootrot)/rootrot;
   N = (integer)(periode/dt);
   alpha0 = TWO_PI/N;
   Zb = L/2;
}


default
{
   state_entry()
   {
   init();
   bouger();
   }

   touch_start(integer n)
   {
   ON = (!ON);
   if (ON) init();
   llSetTimerEvent(dt*ON);
   }

   timer()
   {
   i = (i+1)%N;
   bouger();
   }
} 

[Barbidule McBride]

Citation :

Publié par black cats

J’ai une idée plus que vague des algorithmes utilisés pour calculer des fonctions non linéaires tels que sinus, arcsinus, racine carrée etc. Mais je pense que ça nécessite un nombre relativement élevé de multiplications et d’additions. Donc, deux opérations non linéaires (2 racines carrées si je compte llVecMag(dprod)) d’un côté, deux de l’autre (sinus et arcsinus).
Bon, de toute façon, je pense qu’on chipote sur pas grand chose.

Effectivement, on chipote pour pas grand chose ^^
Ceci dit, les calculs trigo, racines etc, sont réalisés par les processeurs (elle est loin l'époque ou on devait acheter un coprocesseur pour faire les calculs en virgule flottante, ou alors les coder en assembleur!). Les additions, multiplications sont egalemennt faites en virgule flottante, donc par la puce aussi. Je pense plutôt qu'il faut compter le nombre d'opération faites, voire mesurer le temps.
D'après mes souvenirs, la multiplication est plus rapide que l'addition (en réel, pas en entiers, et je soupçonne la racine carrée d'être très rapide...), et rien ne dit qu'un sinus soit plus lent ou plus rapide, on ne sait pas comment c'est optimisé puis cablé. mais on peut raisonnablement supposer que la trigo est plus lente. (En supposant qu'il y a pas d'autres trucs tordus dans l'architecture de SL qui viennent compliquer tout ça...)
Une "vielle" méthode d'optimisation serait de précalculer les sinus dans des tables, si on n'a pas besoin d'une très grande précision (et qu'on fait attention au cumul des erreurs de calculs)

En tout cas, c'est bien du chipotage, l'intérêt ici est d'utiliser la beauté des vecteurs (ce qui dépasse mes capacités neuronales ^^ étant plus habitué aux sinus/cosinus)

[black cats]

Merci pour ces éclaircissements.
En gros, ça confirme ce que je pensais,
A part certaines fonctions , genre rezzer un objet, dont on sait qu'elles sont gourmandes, diffcile de comparer deux calculs.

Il serait vraiment salutaire que LL mette à disposition de tous un outil qui permette de mesurer les ressources consommées par un script. Je crois que les sim owners ont cette possibilité.

Je lance une pétition, avec pour objet : j'ai le droit de savoir moi aussi

[bestmomo]

Citation :

Publié par black cats

Il serait vraiment salutaire que LL mette à disposition de tous un outil qui permette de mesurer les ressources consommées par un script. Je crois que les sim owners ont cette possibilité.

Je lance une pétition, avec pour objet : j'ai le droit de savoir moi aussi

Rien ne nous empêche de mettre des timers pour comparer les performances, il m'arrive de le faire lorsque j'hésite entre deux méthodes pour des scripts où le facteur temps est important. Dans notre histoire de bielle le positionnement des éléments consomme infiniment plus de ressources que nos divers calculs (cos, sin, sqr...).

La comparaison me semble importante par contre au niveau ergonomie du code. Comme tu le soulignes on est toujours dans un espace à trois dimensions et ici les vecteurs judicieusement couplés aux quaternions sont imbattables. C'est pour cette raison que je rechignais à utiliser des éléments de trigo et tu as parfaitement formulé la contrainte à partir de produits vectoriels. Par contre tu n'échappes pas à Pythagore.

Je n'ai pas trop le temps en ce moment de plonger dans tes différents codes, je suis trop pris pas mes vacances

[Elenia Boucher]

Citation :

Publié par bestmomo

...
Je n'ai pas trop le temps en ce moment de plonger dans tes différents codes, je suis trop pris pas mes vacances

Je crois que l'on en a fait le tour et que l'on va te laisser le mot de la fin Best car finalement les vacances c'est ce qui est de plus important Bonne continuation.

[black cats]

Citation :

Publié par bestmomo

Je n'ai pas trop le temps en ce moment de plonger dans tes différents codes, je suis trop pris pas mes vacances

C'est pas plus mal, parce qu'ils comportent une erreur.

Dans l'expression du vecteur k2, il manque une parenthèse, et le llVecMag(dprod) doit être élevé au carré.
Quelque part, l'expression me chiffonnait un peu, au niveau de l'homogénéité.

Dans les scripts précédents, il faut donc remplacer

Code PHP:

   vector k2 = (e/L)*dprod + llSqrt(L*L - e*e*llVecMag(dprod))*uz; 

par

Code PHP:

   vector k2 = (1/L)*(e*dprod + llSqrt(L*L - e*e*dprod*dprod)*uz); 

Le pire c'est que j'ai testé d'autres mécanismes plus tordus encore, avec des modifications mineures du même script, mais toujours avec l'expression erronée de k2. Le mouvement me semblait très bien.

En fait, numériquement, la différence est très faible. Néanmoins, le problème est visible sur les deux vidéos précédentes (à peine sur la dernière, mais un peu plus sur l'avant dernière) :
au point mort bas, le piston sautille un peu avant de repartir.

J'avais pourtant bien remarqué ce sautillement anormal. Mais bon, quand ça marche à peu près, on trouve toujours une excuse aux imperfections, ailleurs que chez soi : le lag, des problèmes d'arrondis, l'âge du conducteur...

[black cats]

Citation :

Publié par bestmomo

les vecteurs judicieusement couplés aux quaternions sont imbattables.
(...)
Par contre tu n'échappes pas à Pythagore.

Formellement si.

Une fois la containte traduite, les calculs que j’ai faits faisaient appel uniquement aux propriétés des produits vectoriels, produits scalaires etc. Même si la trigonométrie est sous-jacente à tout ça, à aucun moment elle n’apparaît de façon explicite dans les calculs.

C’est aussi l’inconviénient de la méthode : plus on est théorique, plus il est difficile de détecter les incohérences dans un résultat.

On peut peut interpréter le résultat a posteriori :

En regardant le terme e*dprod, on peut voir que sa norme est e*sin(alpha), et qu’il est dirigé par uy : il s’agit en fait du vecteur BQ
On constate aussi que le deuxieme terme llSqrt(L*L - e*e*llVecMag(dprod))*uz
n’est autre que le vecteur QC, et que c’est effectivement la traduction du théorème de Pythagore dans le triangle BQC. Ce qui m’a permis de voir qu’il manquait un « carré ».

Il n’y a pas de miracle : chassez Pythagore par la porte, il revient en douce par la fenêtre.

Je suis bien conscient du fait que tout ce que j’ai dit à propos du calcul vectoriel est assez vague. C’étaient plus des pistes de réflexion que de vraies explications. Tout simplement parce que pour être compréhensible, j’aurais eu besoin de moyens d’éditions qu’on n’a pas avec l’éditeur du fofo.
Un schéma par ci par là, et surtout quelques formules. La seule solution que je voyais, c’était une image avec la calcul en pièce jointe. Pas terrible.

Pour conclure.
Je te rejoins sur l’idée qu’il pourrait être utile de faire quelque chose sous une autre forme que du texte sur un forum, un « petit tuto » sous forme de pdf à télécharger, par exemple.

[bestmomo]

Citation :

Publié par black cats

En regardant le terme e*dprod, on peut voir que sa norme est e*sin(alpha), et qu’il est dirigé par uy : il s’agit en fait du vecteur BQ
On constate aussi que le deuxieme terme llSqrt(L*L - e*e*llVecMag(dprod))*uz
n’est autre que le vecteur QC, et que c’est effectivement la traduction du théorème de Pythagore dans le triangle BQC. Ce qui m’a permis de voir qu’il manquait un « carré ».

Il n’y a pas de miracle : chassez Pythagore par la porte, il revient en douce par la fenêtre.

Pas joli de masquer les cos avec des produits scalaires et les sin avec des produits vectoriels

Ceci dit il faudrait trouver une méthodologie simple pour traiter des mécanismes. Je réfléchis au tuto entre deux brasses.

[black cats]

Citation :

Publié par bestmomo

Pas joli de masquer les cos avec des produits scalaires et les sin avec des produits vectoriels

/me sifflote, et se gratte la tête en essayant de se rappeler : quisseki donc avait dit un truc du genre :
"Je pensais pouvoir introduire une notion de contrainte pour éviter les cos et sin"


Ce n'est pas moi qui les masque. Je me drape dans le voile blanc de l'innocence et de la virginité, et rejette toute faute sur ceux qui ont mis en place l'analyse vectorielle.
Le tout était de penser à les démasquer une fois le calcul fini.

Citation :

Publié par bestmomo

Ceci dit il faudrait trouver une méthodologie simple pour traiter des mécanismes.

J'ai quelques idées là-dessus, notamment sur la méthodologie. Outre tout ce qui peut se balader dans l'espace 3D, les pistons, bielles et autre ferraillerie graisseuse font un peu partie de mon lot quotidien.
Mais tout le monde a pu constater la qualité de tes tutos, non seulement du point de vue de la rigueur, mais aussi de la pédagogie. Et je fais partie des nombreux qui en ont bénéficié avec bonheur.
Donc, si tu es déjà partant là-dessus, personne ne s'en plaindra.

Cependant, si jamais une collaboration t'intéresse, contacte moi, ce serait un honneur et un plaisir.

[-.-]

Débat théorique intéressant, mais le mieux reste de trouver une solution optimale pour une animation la plus fluide possible dans SL.

Avec 3 prims sculpt pour l'esthétique et un script optimisé j'obtiens ceci :

2 fonction trigonométriques dans le script : llSin et llAcos.
Pour le reste quelques manipulations de vecteurs.

[black cats]

Sympa les sculpties. C'est sùr qu'avec un peu plus d'attention portée sur le build, ça a une autre gueule (on l'a tous laissé délibérément de côté).
J'aime beaucoup le vilebrequin.
Pour taquiner un peu, du point de vue des proportions, je dirais que la bielle souffre un peu d'anorexie, alors que le piston aurait besoin d'un bon régime .

Citation :

Publié par Mingyar Ishtari

mais le mieux reste de trouver une solution optimale pour une animation la plus fluide possible dans SL.
(...)
et un script optimisé j'obtiens ceci :

De ce point de vue-là, optimisation de la charge du simulateur, et fluidité du mouvement obtenu (ce qui est lié), je pense que toutes les solutions qui ont été, sont, ou seront présentées ici se valent.
D'après les remarques qui ont été faites sur le temps de calcul, la durée d'exécution se résume à peu de chose près à l'exécution des fonctions llSetLinkPrimitiveParamsFast.
Avec les nouvelles fonctions fast, on obtient maintenant des mouvements assez fluides sur SL. C'est surtout sur les vidéos ou le résultat est moins joli.

Citation :

Publié par Mingyar Ishtari

2 fonction trigonométriques dans le script : llSin et llAcos.

Au bout du compte : 0 fonctions trigonométriques, et une seule racine carrée.
Mais on retombe dans le débat théorique.

On commence à avoir une petite collection de mécanismes. Il faudra peut-être songer à ouvrir un musée ( de l'horreur ?) pour les exposer.
Ou encore, une fois que le concours de Bestmomo aura été finalisé, pourra-t-on lancer un nouveau concours, sur le thème du mécanisme le plus tordu, ou le plus foldingue.

J'allais oublier, et à propos de build : quelqu'un a-t-il eu des nouvelles de l'initiateur du sujet ?
Sextan, si tu nous entends....

[black cats]

Pour ne plus parler dans le vague, j'ai finalement rédigé un document dans lequel j'explicite les calculs et raisonnements qui ont été évoqués ici.

J'en ai profité pour y ajouter quelques considérations plus générales.
Ça n'a pas la prétention d'être un vrai tuto, ni un document abouti. J'espère cependant que certains le trouveront utile.

Comme dit la formule consacrée : toutes les remarques, qu'elles soient positives ou négatives, sont les bienvenues, du moment qu'elles font avancer le schmilblick.

Je pars moi aussi faire un stage piscine incessamment sous peu. Mais contrairement à Bestmomo, je n'ai pas de clavier étanche qui me permettrait de tapoter dans ma piscine.
Donc, désolé d'avance si je ne peux répondre à d"éventuelles interventions.

traitement vectoriel du mécanisme bielle-manivelle

[bestmomo]

Citation :

Publié par black cats

...

Je pense que tu as bien mérité ta piscine

Je suis partant pour une collaboration à la rédaction d'un tuto orienté machines, on se contacte quand tu sortiras de ta piscine, en attendant je te souhaite de super vacances

[Sextan Shepherd]

Citation :

Publié par Black Cats

J'allais oublier, et à propos de build : quelqu'un a-t-il eu des nouvelles de l'initiateur du sujet ?
Sextan, si tu nous entends....

Présent

Je vais vous poster une vidéo de la machine en question.. et en mouvement. La machine est une adaptation de l'hélice de Da Vinci couplée à 2 ensembles (piston/bielle/vilebrequin) asynchrones.. 55 mètres de haut! ( ça fait son effet ^^ )

J'ai reçu un script de Maître Mansbridge, 24h00 après avoir posté le sujet. Chaque ensemble (piston/axe-piston-bielle/bielle/axe-bielle-roue/Roue/masse/axe-moteur) s'adapte parfaitement aux redimensionnements et au rotation (une fois lié bien entendu) et même adapté à une machinerie constituée de huge prims (50m) sur une sim peuplée et bien chargée en script, ça tourne comme une petite horloge.

J'ignore la/les fonctions exactes qui ont été utilisées dans le script (je m'évite un mal de crâne pour rien ) mais il y' une fonctionnalité imparable pour les utilisateurs.. c'est l'ajout d'une configuration du moteur par notecard. On drop un script dans les différents objets composant le moteur.. on récupère les données dans le chat .. on colle ça dans la notecard et roule ma poule!

après avoir testé les scripts mis à disposition ici et celui envoyé par Christy, j'ai choisi sa solution, je lui ai donc remis les 5k convenus. Mais je sens une belle émulation autour de ces bricolages de cerveaux fumeux :

Citation :

Publié par Black Cats

On commence à avoir une petite collection de mécanismes. Il faudra peut-être songer à ouvrir un musée ( de l'horreur ?) pour les exposer.
Ou encore, une fois que le concours de Bestmomo aura été finalisé, pourra-t-on lancer un nouveau concours, sur le thème du mécanisme le plus tordu, ou le plus foldingue.

vous pourrez donc compter sur moi pour généreusement doter le concours si il à lieu.. j'ai même une belle salle à disposition pour y exposer les bricolages.

Bonne vacances à tous!

[bestmomo]

Une petite pièce à ajouter au dossier :

Le guide sur les machines est en route et creuse un peu plus ce mouvement. Je publierai à la rentrée