Salut tous le monde; cela ne fais pas longtemps que je parcours les forums mais je dois dire qu'avec comme jeux favoris NWN je n'ai pas trop le choix. Bref j'adore ce jeu j'ai des tonnes de raisons pour ca mais je ne suis pas pour autant un as de la programmation, il est vrai qu'Aurora est un logiciel vraiment exellent et facile d'accès mais pour les scripts c'est autres chose or pour creer son propre module je dirais que pour certaines choses savoir écrire des scripts deviens nécéssaire:
Bon je ne vais pas trop m'attarder sur ma vie moi je voudrais juste que quelqu'un m'aide un peu: Voila si il y a bien une chose que je déteste c'est que mes compagnons (PNJ, et familier) foncent dans le tas jusqu'à ce que mort s'en suive, il y aurais une commande permettant de leur faire prendre leur distance par apport au combat ca ne serais franchement pas du luxe. Du cou je fais appel a tous ceux qui connaisse assez bien les scripts pour me bidouiller un truc (pour moi!!!!! naaaaan pour tous les joueurs). S'il vous plait j'ai du mal à comprandre comment fonctionnent les scripts aussi si vous pouviez me dire exactement comment faire et aussi à quoi s'applique le script perso objet etc... ca serais vraiment sympas.
Pour finir je dirais que sur ce genre de forum je suis quasi obligé d'obtenir une réponse mais ce qui serais bien (merci) c'est qu'elles ne soient pas hors sujets (je dis ca parce que j'ai déjà essayé d'autres forum).

Si tu es patient, je te ferai une réponse digne de ce nom. Mais ça va me prendre du temps, alors patiente un peu (quelques jours au plus, je suis pas très dispo en ce moment).
_________________
Lendraste de Loreval
Qui cherche la Vérité cherche celui qui la détient, car elle n'existe pas à l'état naturel.
La cité des mensonges - 1

Merci Lendrast,

Je ne compte pas répondre sur les compagnons d'armes et autres familiers, mais sur une explication basique concernant les scripts, qui, je l'espère, sera utile à tous ceux qui débutent.

Quelques généralités
Les scripts NWN s'articulent autour d'un principe de base et d'un langage. Je ne vais pas m'étendre de trop sur l'aspect langage. Le langage de programmation utilisé est une sous-famille du langage C, empruntant sa syntaxe et ses structures (fonctions, procédures, déclarations, types, conditions, boucles, etc...). En s'imprégnant de la manière de programmer en C (bon nombre de bouquins existent à ce sujet), et en disposant d'une documentation sur les fonctions disponibles, il est aisé de concevoir un script. Ce qui nous intéresse davantage pour répondre à la question posée est "quand et comment utiliser un script", autrement dit, comprendre le principe et le contexte dans lequel on créé un script.
Pour prendre des termes profanes, NWN se comporte comme un agenda électronique et nous, dépositaires de l'agenda, sommes les scripts. Lorsque nous organisons notre emploi du temps et que nous posons des rendez-vous ou des évènements sur un agenda, nous mettons en place une alerte, une information qui nous indique ce que nous devons faire à telle ou à telle date/heure. Lorsque cette alerte se déclenche, nous accomplissons alors ce que nous avions prévu de faire (je parle bien sur du meilleur des cas, nous ne sommes pas aussi infaillible qu'un programme informatique ). Donc, lorsque nous envisageons de "scripter" dans NWN, nous prévoyons de faire quelque chose en réaction à un évènement se produisant dans le jeu, et NWN, mais je parle là du "moteur", de la mécanique interne du jeu, est en quelque sorte l'agenda qui déclenche nos "réactions programmées".

La programmation évènementielle
J'ai simplifié l'image à l'extrême. Il faut se mettre dans la tête que NWN peut déclencher énormément d'évènements quasi-simultannément. Il ne faut pas se perdre en conjecture sur ce que pourrait être le mouvement d'ensemble d'un module et essayer de raisonner en découpant un module en composants plus petits sans quoi il est impossible de projeter efficacement ce que l'on veux faire. Aurora (qui est le nom du moteur du jeu) nous facilite grandement les choses. Pour chaque composant que nous plaçons dans un module, Aurora nous propose de déclencher automatiquement un certains nombre d'évènements le concernant. C'est la base de la programmation évènementielle.
Du point de vue d'Aurora, le PJ (le personnage joué par un joueur) est le seul composant qu'il ne contrôle pas. C'est ce qui a le plus de chance d'interagir avec ce qui est présent dans le module. Le PJ est un peu notre doigt dans cet engrenage qu'est Aurora et nous le déplaçons au coeur du système. Mais il n'existe à la base aucune action spontanée de la part du moteur du jeu. Tant que nous n'entrons pas en contact avec les éléments dont il a le contrôle, il ne se passe rien de spécial. Attention car cette affirmation est discutable. On peut demander à Aurora de faire des actions régulières qui paraîtront spontanées. Ce que je veux dire c'est que si nous ne programmons rien de spécial allant dans ce sens, Aurora n'est qu'une grosse machine qui ne fait rien jusqu'à ce que "nous", joueurs, entreprenions quelque chose. Le système est réactif et non pas actif.
A toute fin utile, je précise que tout ce que font les monstres, les plaçables et autres composants du jeu que nous pouvons mettre en place dans un module répondent à cette règle, à ceci prêt que Bioware a déjà mis en place un certains nombres de scripts qui leur permet d'avoir un comportement "de base", nous épargnant ainsi le devoir d'écrire des scripts pour "animer" la moindre parcelle de nos modules. Ces scripts peuvent être supprimés ou remplacés. On les appelle les "scripts par défaut".
Nous pouvons appeler "objet" tout élément d'un module sur lequel Aurora nous propose d'effectuer un contrôle et de déclencher des évènements. Par exemple, une "créature" est un objet. Un "plaçable" également. Les objets ne disposent pas tous des mêmes évènements, mais beaucoup en ont en communs. Les "évènements" dont Aurora s'occupe ont été nommé pour plus de facilité. Aurora les déclenche quand un certains nombre de conditions sont réunies. Lorsqu'un évènements se déclenche, Aurora vérifie si un script a été écrit pour y répondre. Si ce n'est pas le cas, il ne fera rien. Si c'est le cas, il exécutera le script.

Exemple de conception évènementielle
Pour bien comprendre le processus d'Aurora, d'une part, et la manière d'en tirer partie, d'autre part, mettons en place un exemple fictif. Imaginons que nous souhaitions créer un chien ayant un comportement assez "réaliste" (toute proportion gardée) et supposons que nous n'ayons pas de scripts par défaut à notre disposition. Listons d'abord ce que nous appellons "comportement réaliste" :
- Un chien aboie quand il entend du bruit sauf s'il reconnaît la source du bruit.
- Il vient renifler les personnes qu'il ne connaît pas.
- Il prend ce qu'on lui donne à manger et remue la queue en conséquence.
- Il aime parfois suivre les personnes qu'il connaît.
- Il obéit à son maître.
- Il obéit parfois aux inconnus.
- Il ressent instinctivement les personnes menaçantes et aboie après ou les attaque.*
- Si on l'attaque, il se défendra.
- Quand il ne fait rien de spécial, il dort ou se ballade.
On va arrêter là pour le moment. Il est possible d'affiner cet exemple, mais pour le moment nous avons assez de matière pour comprendre ce que nous devons faire. Un chien conçu dans l'éditeur devient un élément du moteur Aurora. Il convient de regarder les évènements à notre disposition pour le faire se comporter comme nous le souhaitons.
Prenons le premier cas. Lorsque le chien entend du bruit dont il ne connait pas la source, il aboie. Il y a un évènement géré par Aurora qui déclenche un script lorsque une créature perçoit quelque chose. Cet évènement s'appelle OnPerception. Bien entendu, cet évènement se déclenche à chaque fois que la créature perçoit quelque chose. Notre script devra donc traiter différents cas de figure. Il obéit à son maître ou parfois à des inconnus. On dira que cela dépend des ordres, mais il existe un évènement spécifique pour capter les paroles, et cet évènement s'appelle OnConversation. Si on l'attaque, notre chien se défend. Une tentative de le blesser et non pas seulement une blessure, le fait réagir. L'évènement OnPhysicalAttacked se déclenche lorsqu'une créature est assaillie et qu'elle n'est pas déjà en combat.
Sans aller plus loin, on sait déjà sur quels évènements il va falloir associer nos scripts. A noter que créer un script se fait indépendamment de l'élément avec lequel on souhaite faire fonctionner un script. Il est possible qu'un même script soit valable pour plusieurs créature. En l'occurrence, il est très fréquent qu'une créature se défende si elle est attaquée et pas seulement les chiens. Si notre script est bien fait, il pourra donc s'appliquer à plusieurs créatures différentes.


Autres type d'évènements
Les évènements évoqués ici sont des évènements courants. Ils correspondent à quelque chose que nous pourrions vivre dans la vie réelle. Le moteur Aurora propose de déclencher des évènements complètement différents que l'on peut appeler les évènements techniques. Ceux-ci sont OnSpawn, OnDeath, OnHeartbeat, OnUserDefined et OnCombatRoundEnd pour ce qui est des créatures. Ces évènements sont spéciaux dans le sens où il ne constituent pas une réaction à des situations dite "normale". Ce sont des situation de jeu spécifique. Le OnSpawn, par exemple, est très important. Aurora déclenche cet évènement au moment où la créature "apparaît" dans le module. Le terme apparaître n'est d'ailleurs pas du tout adapté. Aurora gère énormément de choses dans un module, dont des éléments que le personnage ne voit pas forcément. A savoir que quand un module est lancé, les créatures qu'on a pris soin de placer dans le module grace à l'éditeur n'existent pas encore. Aurora a pour devoir de les créer. Selon la complexité d'un module, c'est cette opération qui ralenti son démarrage. Plus Aurora aura de créature et de plaçable (et d'autres objets) à créer, plus il mettra de temps à démarrer le module. Car chaque objet créé déclenche un évènement OnSpawn. Pour peu que tous les évènements OnSpawn du module disposent d'un script (même un script par défaut), le temps d'exécution de tous ces OnSpawn sera très consommateur. C'est nettement moins important lorsqu'un objet est créé par un script au cour de l'exécution du module, pendant la partie. A ce moment, seul un script OnSpawn est déclenché.
OnSpawn est un exemple d'évènement atypique, tout comme l'est OnHeartbeat. Attention à cet évènement d'ailleurs. Cet évènement ne se déclenche que grâce à une condition de temps. C'est à dire, à chaque fois que 6 secondes sont écoulés, le OnHeartbeat se déclenche. Cela signifie que toutes les 6 secondes, s'il y a un script associé à l'évènement OnHeartbeat, le scripts s'exécute. Cela signifie aussi que s'il y a 10 créatures dans le module ayant un script OnHeartbeat, 10 scripts s'exécuteront toutes les 6 secondes (même si c'est le même, il s'exécute pour chacune des créatures). C'est donc un évènement dont il ne faut jamais abuser, car certaines machines ne le supporteraient pas. Je ne vais pas passer en revue tous ces évènements, j'en mets juste un de côté le OnUserDefined pour l'utiliser plus tard.
Ici nous avons vu de quelle façon les évènements sont déclenchés. Il faut bien comprendre que plus nous aurons d'objet (créature et plaçables principalement) plus Aurora aura d'évènement à gérer. La vitesse de travail du moteur Aurora ne dépend pas seulement de la puissance de notre ordinateur, mais aussi de la richesse et du contenu du module. De la même façon, si nous n'utilisons pas les scripts par défaut fourni par Bioware, le nombre de script à produire pour gérer le comportement de nos créatures (pour ne citer qu'elles) est assez impressionnant.


Plus en détails
Voici plus en détail comment créer un script et l'associer à un évènement. On prendra un morceau simple de notre exemple, le cas de figure ou notre chien se fait attaquer. Tout d'abord considérons les informations suivantes :
- Un script est écrit indépendamment de l'objet auquel il se rattache.
- Un même script peut servir pour plusieurs situation.
- Un script qui s'exécute possède toujours un "propriétaire".
- Un script peut déclencher des évènements, aussi bien d'autres évènements pour son "propriétaire" que sur les objets qui l'entoure.
- Aurora fourni des paramètres à tout évènement déclenché.
Je voulais évoquer cette notion de propriétaire avant d'aller plus loin. Tout script en possède un lorsqu'il s'exécute. Le plus souvent, le propriétaire du script est l'objet pour lequel Aurora déclenche l'évènement. Par exemple, quand notre chien se fait attaquer, l'évènement OnPhysicalAttacked est déclenché par Aurora. Le chien (ce chien là spécifiquement) est alors le propriétaire du script associé à OnPhysicalAttacked. Lorsque l'on écrit le script, ce propriétaire est immédiatement identifiable par "OBJECT_SELF" (traduit littéralement : l'Objet lui-même). Cela signifie aussi que le script qui utilise OBJECT_SELF pour reconnaître son propriétaire fonctionnera quel que soit son propriétaire.
Le second point important pour écrire un script est de savoir retrouver les paramètres que lui fourni Aurora pour un évènement donné. En effet, Aurora ne se contente pas de dire "ok, les conditions sont réunis pour que tel évènement se déclenche, donc j'exécute tel script". En plus de ça, Aurora fournit des informations complémentaires relatives à l'évènement. Le plus souvent, ce sont des informations sur les conditions de déclenchement elle-même. En l'occurrence, sur un OnPhysicalAttacked, on aimerait bien savoir "qui" attaque. On sait bien sûr qui est attaqué, c'est le propriétaire du script qui s'exécute, mais pour connaître qui est l'attaquant on doit faire appel à une fonction spécifique GetLastAttacker. C'est une manière standard de procéder avec les Scripts NWN, toutes les informations relatives à un évènement peuvent être retrouvé grace à des fonctions. Dans la suite de mes explications je parlerai de protagoniste.
Voici donc le script envisagé :
Code :
Pour l'interprétation de ce code je me référerai à un précédent sujet parlant justement de la queue d'action. Une fois ce script créé, il suffit de lui donenr un nom. Là je ne peux que donner un conseil, chacun opérant de la manière qu'il veut, mais une petite nomenclature pour désigner ses scripts est parfois très utile, surtout l'idée de les "classer" un peu. Quand on arrive comme moi à avoir plus de 300 scripts dans un module, c'est très important de pouvoir les retrouver rapidement dans la liste. Le truc c'est ce qu'on appelle le "préfixage". On fait précéder le nom de notre script par une suite de lettre, un code, facile à comprendre et commun à plusieurs scripts de la même catégorie. Comme les scripts sont classés par ordre alphanumérique (et oui, c'est pas tout à fait alphabétique), tout ceux portant le même prefixe sont alors regroupé ensemble. En ce qui me concerne, les scripts d'évènement sur des créatures, je les préfixe par "ce_". Le séparateur "_" est utile à la visibilité. Je pourrais, si je voulais sous-catégoriser mon script, lui placer un second code à la suite. Il est probable que toutes mes créatures ne réagiront pas pareil, je risque donc de faire plusieurs scripts du type OnPhysicalAttacked. Je pourrais donc déjà indiquer qu'il s'agit d'un script de ce type (avec une codification personnelle), ce qui donnerait "ce_p01_animaux". Ce que je traduit par "creature, évènement, OnPhysicalAttacked numéro 1 pour les animaux". Ceci n'est bien sur qu'un exemple.
Une fois mon script créé et nommé, je peux editer la référence de ma créature (mon chien) et remplir la case de l'évènement OnPhysicalAttacked par "ce_p01_animaux". Si d'autres créatures adoptent exactement le même type de comportement, je peux faire de même pour elles. Le même script fonctionnera parfaitement, puisqu'il ne s'occupe pas de connaître son propriétaire ou son assaillant pour réaliser l'attaque. Aurora lancera l'exécution de ce script quel que soit le propriétaire du script s'il se fait attaqué par qui que ce soit. Il est bon de préciser que le protagoniste "attaquant" peut parfaitement être une autre créature, ce n'est pas forcément un personnage-joueur. C'est ce qu'on sous-entend lorsque l'on dit que "Un script peut déclencher des évènements, aussi bien d'autres évènements pour son "propriétaire" que sur les objets qui l'entoure". Si un script demande à un ours d'attaquer un chien dès qu'il en voit un, le chien, quant à lui, se défendra s'il est assaillit. Il faut donc faire attention à ce genre de cas de figure, surtout si l'on veux créer des exceptions.



Si on manque d'évènement...
Très souvent, on peut arriver à cette conclusion : "zut alors, je vois pas quel évènement pourrait déclencher mon script". Un exemple que l'on retrouve assez fréquemment est celui de l'animal qui a peur du feu. Il n'existe aucun évènement se déclenchant sur "la vue du feu". Qu'à cela ne tienne. On a qu'à en faire un.
Eh oui, la richesse d'Aurora est telle qu'elle autorise un scripteur à créer ses propres évènements. Mais attention ! La contrainte de la gestion d'évènement personnalisé est forte. Car si on peut dire à Aurora de prendre en charge un évènement personnalisé, il faut aussi expliquer à Aurora quand le déclencher. Finalement c'est ce second point qui se révèle le plus délicat. Mais la meilleures façon de le gérer (la moins lourde en terme de ressources de l'ordinateur) est bien d'utiliser cette notion d'évènement personnalisé.
C'est là qu'entre en jeu l'évènement OnUserDefined. Mais attention, lorsque l'on créé un évènement personnalisé à bien noter ce qu'on fait pour ne pas s'emméler les pinceaux. On pourrait créer des évènements très complexes comme "quand la créature voit un dragon vert en train de combattre un guerrier humain armé d'un rouleau à patisserie", et on peut avoir une centaine d'évènement de ce genre à prendre en considération. Mon exemple est volontairement débile et à la fois plausible, car on pourrait vouloir créer un évènement de ce genre ou d'une complexité similaire. C'est comme quand on veux qu'une porte ne s'ouffre que sous certaines conditions, comme "danser la samba et jouer du cornet à piston en tournant le dos à la porte, les jours de pleine lune seulement".
Tout cela pour dire que gérer les conditions de déclenchement, c'est ce qui est le plus difficile. Créer le script de l'évènement personnalisé qui sera déclenché est totalement similaire à ce qu'on a déjà vu. C'est provoquer l'évènement qui va nous causer le plus de souci.
La première chose à faire est de retenir un numéro qui sera notre identifiant d'évènement. Un numéro d'identité, le numéro de sécurité de sociale de l'évènement si on préfère, ce qui permet de dire à coup sur que quand ce numéro sort, il correspond à cet unique évènement.
Dans un premier temps, il faut savoir que les évènements existant fourni par Bioware possède eux aussi un numéro. Il faut donc faire attention à ne pas utiliser les mêmes. Ensuite, il y a un autre problème. Quelle que soient la nature des évènements personnalisés déclenchés, c'est toujours le même script, celui associé à OnUserDefined, qui sera executé. Ce dernier va avoir la forme suivante :
Code :
Donc, là, par exemple, on pourrait coder à l'emplacement marqué par "//code de l'évènement personnalisé 1" la réaction de notre animal quand il voit un feu. On pourrait simplement décider de l'en éloigner, ou mieux, placer sur lui le même effet que le sort de terreur. C'est plutôt facile à mettre en oeuvre. Ce qui est plus délicat c'est de déclencher l'évènement. Du point de vue de notre animal, il n'y a rien d'autre à faire. Là on pourrait me dire qu'il suffirait dans le script déclenché par OnPerception. Hélas, OnPerception ne se déclenche que si la créature en perçoit une autre (visuellement ou par les sons). On ne pourrait jamais savoir si la créature a vu un feu de camp, par exemple. Typiquement, la solution que l'on trouve dans ce genre de cas de figure est la suivante : Il suffit de scripter l'évènement OnHeartBeat et de vérifier dans l'entourrage de la créature s'il n'y a pas un feu. Seulement cette solution va vite s'avérer impossible à mettre en oeuvre sur les gros modules, car si tout nos animaux se comportent ainsi face au feu, il faut vérifier pour chacun d'eux, toutes les six secondes, si un objet de type feu de camp n'est pas dans les parages. Rien de tel pour faire crouler un serveur sous le poids de cette masse de tests perpétuels. Et puis à quoi bon avoir codé un évènement personnalisé puisque c'est dans le OnHeartbeat du même propriétaire que l'on saura si oui ou non il y a un feu de camp.
L'autre raisonnement possible conduit donc à se dire que c'est le feu de camp qui va provoquer l'évènement chez les animaux qui l'approche. Pour l'instant, sans me préoccuper de la meilleure manière de le faire, je présente la solution technique :
Code :
EventUserDefined permet de créer un évènement, mais il doit ensuite être "envoyé" à ceux qui sont susceptibles d'y réagir. C'est ce que fait la fonction SignalEvent. A noter qu'on peut aussi utiliser ces deux fonctions pour déclencher des évènements standards, en courcircuitant ainsi le processus normal d'Aurora, on pourrait faire réagir la créature comme s'il avait reçu l'évènement OnPhysicalAttacked alors qu'il n'aurait pas été attaqué. Pour cela, au lieu de créer l'évènement 1 on pourrait créer l'évènement EVENT_ATTACKED (c'est une constante qui détient la valeur numérique d'un évènement correspondant à OnPhysicalAttacked). C'est ainsi qu'un chien pourrait réagir aux agressions verbales. Si on a fait le nécessaire dans OnConversation on pourrait détecter un "sale bête" et déclencher l'évènement OnPhysicalAttacked (ca serait mieux que de scripter une attaque directement dans OnConversation). C'est un évènement qui en entraîne un autre.
Mais revenons à notre feu de camp. Nous savons quelles fonctions utiliser pour déclencher l'évènement, mais pas comment le feu de camp va détecter une créature qui l'approche. En fait le problème s'est déplacé. Et nous sommes, une fois de plus, tenté d'utiliser le OnHeartbeat, mais cette fois, celui du feu de camp. Même problème... Si le nombre de feu présent dans le module est grand, nous augmentons d'autant le nombre de tests à faire et le nombre d'exécution de script.
Fort heureusement, il existe deux alternatives. L'une est le "déclencheur" (trigger en anglais) qui permet de définir une zone dans laquelle des évènements sont déclenchés quand quelque chose entre dedans (OnEnter) et quand quelque chose en sort (OnExit). Cette alternative a une limite cependant. On peut définir un trigger partout ou on mettra un feu de camp dans notre module. en gros on créé une zone de trigger circulaire que l'on place sur la carte et on met un feu de camp au milieu. Le feu de camp ne fait rien en soit, mais par contre le trigger pourra déclencher un évènement OnEnter quand un créature entrera. A ce moment on peut exécuter le script suivant :
Code :
Vous me direz : "et si l'objet qui entre dans la zone n'est pas une créature qui a peur du feu". Ce à quoi je répond que ce n'est pas grave. Si une créature du module entre dans la zone, son script OnUserDefined sait de quelle façon elle doit réagir face au code d'évènement 1. Dans le cas des créature ayant peur du feu, on aura prévu quelque chose, pour les autres on aura rien prévu. Et alors ? Si on envoie un évènement quand même, il ne se passera rien dans leur cas, donc on est pas obligé de faire la distinction. Ce sont nos scripts d'évènements qui font la différence entre un évènement traité et un autre non traité.
Maintenant, autre problème, nous avons fait en sorte dans notre module de permettre à un PJ de créer un feu de camp. Ceci est un problème car il n'est pas possible de créer un trigger par script. Dans ce cas, et toujours pour éviter d'utiliser le OnHeartbeat, il nous reste une alternative très similaire au trigger, on appelle cela la zone d'effet. La zone d'effet est un objet dynamique (et virtuel). en fait on le range dans la catégorie des effets, mais il a la particularité d'être un effet capable de déclencher des évènements, un effet réactif en quelque sorte. Une zone d'effet se comporte exactement comme un trigger et dispose des évènements OnEnter et OnExit. C'est au moment où nous créons une zone d'effet que nous décidons quels seront les scripts associé à ces évènements. C'est extrêmement pratique. L'idée est donc de faire en sorte que quand on créé un feu de camp, on créé une zone d'effet sur laquelle le OnEnter utilisera le script qu'on a évoqué plus haut. Ce script je vais d'ailleurs le nommer "ee_e01_feu". Le OnSpawn d'un objet est déclenché à sa création par le moteur de jeu Aurora. Il est donc aisé de créer une zone d'effet sur le feu de camp à ce moment.
Code :
Je tenais à préciser que je n'ai pas toutes mes notes sous la main et je ne sais donc plus trop quelle est la taille de la zone dont je donne le code (AOE_MOB_SILENCE). De plus, il faut retenir que certaines zones ont une animation visuelle. Ce n'est peut-être pas souhaité par ce script. Il faudra peut-être changer cette valeur. Mais pour le reste, ca devrait fonctionner. Si l'objet est détruit, l'effet devrait être détruit également, on a donc pas à s'en occuper.


En conclusion
Je vais arrêter là le sujet. Il est, je l'espère, assez facile d'accès pour bien comprendre le phénomène d'évènement et donc, commencer à se pencher sur la conception de script (en dehors de la maîtrise du langage lui-même, et de l'utilisation de l'éditeur). S'il y a des questions (ou des demandes de précision) sur ce que je viens d'écrire, je m'efforcerai d'y répondre.
En espérant que ce petit cours sera utile, je souhaite bon courage à tous les néophytes... Et les moins néophytes.
_________________
Lendraste de Loreval
Qui cherche la Vérité cherche celui qui la détient, car elle n'existe pas à l'état naturel.
La cité des mensonges - 1

Merci pour ces explications Lendrast !
Je pense que ton message (ainsi que celui expliquant les queues d'actions) devrait être posté dans le thread post-it: Conseils et recommandations diverses.

Tout pareil.....et on doit toujours monter la secte des lendrastiens