Encore moi oui désolés
En fait quand un objet dis plusieurs choses à la suite j'aimerai mettre des poses pour pas qu'il déballe tout d'un coup.
J'ai pensé à mettre ça entre chaque SpeakString :
AssignCommand(OBJECT_SELF, ActionWait(2.0));

Mais rien à faire il attends pas 2 secondes il déballe tout d'un coup...
C'est normal docteur ?
merci

J'ai toujours eu du mal avec ActionWait, je sais pas pourquoi... Du coup je me sers de DelayCommand, ça marche mieux

Il te faut quelque chose du genre :
Code :

Bon, c'est à mettre en forme hein, je n'ai plus la syntaxe exacte dans la tête mais il faut déclarer le sujet de l'action quelque part dans la commande, mais c'est les grandes lignes

Là il dira la seconde phrase 3 secondes après la première et la troisième phrase 6 seconde après la première
_________________
Aventure ! Camaraderie ! Et acier sur acier ! Les ingrédients légendaires ! Hein Bouh ?

http://cassin1306.spaces.live.com

Merci beaucoup je testerai des que je rentre mais je pense qu'il n y aura pas de problèmes, ça semble etre la bonne solution...

Il demeure toutefois plus intéressant de le faire dans la queue d'action dans certains cas. Tout simplement parce que le DelayCommand va entrainé le PNJ à prononcer les phrases quoi qu'il arrive, même si on entre en combat contre lui, alors que si c'est dans sa queue d'action, celle-ci va se vider au moment d'un affrontement et il ne prononcera donc plus ces phrases qui n'ont plus de sens... Ce n'est là qu'un exemple pour démontrer l'intérêt de garder aussi l'idée de la queue d'action et dans ce cas, il faut bien veiller à affecter les SpeakString comme des actions à la queue, par le biais d'un...
Code :
_________________
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

lendraste a écrit :Bien j'essairai, en tous cas chez moi j'ai fais comme ça et ça marchait pas :
Code :[/quote]

Peut etre qu'en ajoutant les AssignCommand ça fonctionnera...

Une action non assignée à la queue d'action est toujours immédiatement exécutée, même si c'est décrit comme un action, l'assignement reste une opération à part entière. C'est la différence entre le synchrone et l'assynchrone, toutes les fonctions du langage sont considérée comme Synchrone. Le seul moyen de les rendre assynchrone, c'est à dire de différer leur exécutions réelles par rapport au moment ou on appelle la commande est de la placer dans la queue d'action d'une créature (AssignCommand) ou de la différer dans le temps (DelayCommand). Les deux techniques peuvent même être combinée, mais ca devient vite compliquer
_________________
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

Hum hum.... *utilise un ton respectueux*
Tu sors d'une autre planête ou tu es tombé dans le scriptiing quand tu étais petit ?

Xuyl a écrit :Des fois je me demande... Disons que j'ai la fibre de la pédagogie, mais si tu comprends pas je peux essayer de détailler davantage . J'aime bien quand les concepts de bases sont bien compris et maîtrisés par tout le monde, ça permet de mieux nous comprendre entre nous.
_________________
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

Je veux bien que tu me détailles un peu plus si ça te dérange pas, merci

Bon, va pour une plus longue explication

Les langages de programmation comme le C, le Java ou le NWNScript qui appartiennent un peu à la même famille possèdent différentes caractéristiques récurentes. La principale est leur capacité à exécuter de manière séquentielle (une par une) les instructions que tu leur donnes. La plupart de ces instructions sont "synchrones". C'est-à-dire que l'instruction suivante ne sera exécutée que lorsque l'instruction courante sera terminée et ce, quel que soit le temps que cela prenne. Pour prendre un exemple dans la vie courante, lorsque tu prends un petit déjeuner et que tu bois ton café ou que tu trempes ta tartine, tu est incapable de faire les deux en même temps (ou alors tu en fous partout ). Autrement dit, tu procèdes de manière séquentielle. Tu prends une gorgée de café et puis quand c'est fini tu reposes le bol, tu trempes ta tartine, tu manges un morceau et puis tu reprends une gorgée de café et ainsi de suite. C'est un processus séquentiel synchrone. Une action ne peut pas commencer tant que la précédente n'est pas terminée.

Mais tout dans un langage de programmation ou dans la vie n'est pas un processus séquentiel synchrone. Il existe des notions, comme le parallélisme, qui décrivent la possibilité de faire plusieurs choses en même temps. Mais le parallélisme est la possibilté de réaliser plusieurs processus séquentiels synchrone en même temps. Par exemple, pendant que tu prends ton petit déjeuner, tu pourrais écouter la radio. Tu peux parfaitement le faire en même temps. Mais le fait d'écouter la radio demeure un processus séquentiel synchrone, même s'il est passif (dans le sens ou l'activité d'écouter ne demande quasiment pas d'effort physique ou de volonté). Les informations ne te parviennent que les unes après les autres et non pas toute en même temps. Tu n'écoutes qu'une seule station à la fois ou alors tu ne comprends rien.
Toutefois, il existe dans un même processus, la possibilité de déclencher des actions asynchrones, c'est-à-dire des actions dont il n'est pas nécessaire d'attendre le résultat pour continuer son activité normale. Dans le cadre du petit déjeuner, mettre une tartine à griller est un processus asynchrone dans ton activité. En effet, à moins de ne pas avoir de tartine déjà grillée en réserve, tu n'as pas besoin d'attendre que la tartine soit grillée pour poursuivre ton petit déjeuner. Certes, ce n'est pas vraiment toi qui t'occupe de la griller cette tartine, mais ton grille-pain, cependant, cela est bien dans ton activité d'avoir déclenché le dit grille-pain. Cette action est purement asynchrone. Tu ne maîtrises même pas forcément le temps qu'elle mettra à s'exécuter, mais comme tout un chacun le matin, tu es pressé par le temps, donc hors de question d'attendre que la tartine soit grillée pour continuer ton petit déjeuner. Il se peut même que tu sois parti avant que la tartine soient grillée. C'est l'essence même du processus asynchrone, lequel est déclenché lors de l'exécution d'un processus synchrone.

Dans le cas d'un langage de programmation et de ton exemple en particulier, l'interprétation est la même. La queue d'action d'une créature est une sorte de réservoir dans lequel tu déclares les actions asynchrones que tu veux faire faire à ta créature. Mais, ces actions sont déclarées lors de l'exécution d'un processus synchrone, autrement dit ta fonction de script. Cette fonction aura fini de s'exécuter et tu pourras même lui faire faire autre chose, mais tu n'auras pas attendu pour autant de savoir le résultat des actions de ta créature. Dans l'exemple que tu as codé, tu demandes à la créature de prononcer deux phrases dans un processus synchrone (donc attendant le résultat de chaque action avant de faire immédiatement après la suivante) + une instruction qui déclare qu'il devra attendre 2 secondes dès qu'il le pourra dans sa queue d'action, alors que le but de l'opération est bien de demander en un seul coup (donc en exécutant la fonction) que le personnage réalise 3 actions asynchrones (2 phrases et un temps d'attente entre les deux).

On évoquait aussi la possibilité d'utiliser une autre technique que la queue d'action, le DelayCommand. Le DelayCommand est aussi une solution pour déclencher des actions asynchrones puisque l'on demande à un instant T qu'une instruction soit exécutée dans le délai indiqué. Mais comme toute action asynchrone, le script poursuit son exécution immédiatement après avoir passé le DelayCommand, alors que l'instruction placée dans le DelayCommand se déclenchera plus tard. Toutefois l'approche "DelayCommand" est différente de celle de la Queue d'Action d'une créature. L'utilisation de la queue d'action présente l'avantage de pouvoir être annulée. C'est à dire qu'on peut "programmer" les actions d'une créature en insérant des actions dans sa queue grace à AssignCommand, mais que si l'envie nous en prend on peut décider de vider la queue en question, annulant d'un coup tout ce qu'on avait prévu de lui faire faire (la fonction pour ça est ClearAllActions). On ne peut pas du tout annuler un DelayCommand. Une fois que celui-ci à été exécuté, l'action qui a été programmée dans le temps s'exécutera envers et contre tout. Elle pourrait ne pas fonctionner par contre si les éléments requis pour son exécution sont manquants. Par exemple, tu pourrais vouloir programmer dans ton module qu'au bout d'une heure de jeu, un PNJ disparaisse. Un DelayCommand demandant un telle opération au bout de 3600 secondes (une heure ) pourrait ne pas fonctionner si le PNJ a déjà disparu. On peut alors penser que le fait d'avoir détruit le PNJ avant l'heure annule l'action différée. Mais ce n'est pas le cas. L'action différée s'exécutera mais ne trouvant pas de PNJ à détruire, elle provoquera une erreur. Mais ça, on ne le saura jamais, car nous n'avons plus aucun contrôle sur une action lancée avec un DelayCommand. La seule certitude que l'on puisse avoir est qu'elle se déclenchera.

Voilà, j'espère avoir été assez clair cette fois ... A défaut d'avoir fait court
_________________
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

c'est trés clair merci beaucoup pour ta patience.
Il me reste une question mais pas en rapport avec ce que tu viens d'expliquer.
Quel est la différence entre un SpeakString et un ActionSpeakString ?
Merci.

Xuyl a écrit :Tu fais bien de poser la question car je me suis rendu compte que mon précédent compte rendu comportait des lacunes.

La réponse technique la plus simple à ta question est "pratiquement aucune". Toute fonction en C, Java ou NWNScript renvoie une valeur d'un type donné. Cela peut être un type "concret" (un entier, une chaine de caractère, etc) par opposition à un type "abstrait" (une Action, un Evènement, etc) mais dans tous les cas, une données est renvoyée et peut être utilisée.

SpeakString renvoit un "void" (qui signifie vide, ou type vide. c'est un tytpe qui représente le fait qu'il n'y ait pas de type).
ActionSpeakString renvoit une "action".

Cette dernière proposition est fausse. Le type "action" est en fait un type "void". Le fait est que le contexte d'utilisation de ActionSpeakString la prédispose à sa mise en place dans une queue d'action par AssignCommand, ce qui n'est théoriquement pas le cas de SpeakString. Hélas, dans la pratique, cette différence n'est pas fondamentale et plusieurs autres fonctions sont dans le même cas, pouvant être utilisée indifféremment avec AssignCommand. Toutefois, les seules à se mettre en place dans la queue d'action d'un personnage sont les "Actions".

En fait, il convient de préciser que AssignCommand réalise deux choses différentes. AssignCommand permet de faire exécuter à un objet (quelconque) une fonction. Si cette fonction n'est pas une Action elle ne sera pas placée dans la queue d'action mais exécutée comme si c'était l'objet qui en était le propriétaire. Ce qu'en fera l'objet dépendra de la nature de la fonction. Oui, je sais, ça n'est pas très évident. Mais voici un exemple que tu devrais essayer. Supposons que tu aies un PNJ dont le tag est "PNJ1" et un autre dont le tag est "PNJ2". Tu souhaites que lorsque le PNJ1 voit le PNJ2 il prennent l'initiative de lui dire bonjour, et l'autre de répondre. Donc sur le OnPerception du PNJ1 on peut coder le script suivant :

Code :

Dans cet exemple, du PNJ1 qui perçoit PNJ2 (attention ca peut être par l'ouïe ou la vue), j'effectue deux AssignCommand mais l'interprétation qu'il faut en donner est que je demande à PNJ1 (OBJECT_SELF) d'exécuter un SpeakString et à PNJ2 de faire la même chose. Le résultat est synchrone car l'action demandé n'est pas une Action placée dans la queue d'action mais une instruction immédiate. Cela veux aussi dire que les deux PNJ vont pratiquement parler en même temps alors que PNJ2 répond au premier. Voici une amélioration possible :

Code :

Comme tu peux le voir ici, j'ai fait la même chose sauf que j'ai transmis des Actions. Donc celles-ci vont se placer dans la queue d'action du personnage indiqué dans le AssignCommand. Tu noteras que je souhaite que PNJ2 attende 3 secondes avant de répondre. Là, les actions sont purement asynchrones, mais elles soulèvent un autre problème que je n'avais pas évoqué jusque là. Et si les PNJs étaient déjà en train de faire quelque chose ? C'est-à-dire si on leur a déjà demandé des actions, celles-ci sont placée dans la queue d'action et les nouvelles actions que je leur commande sont mise à la suite. Elle attendront leur tour avant de s'exécuter. Dans mon exemple, si PNJ1 était en train de se déplacer, et qu'il voit PNJ2 durant son déplacement, il ne va pas lui parler de suite. Il va finir son déplacement et son action de parole se fera ensuite... hélas, il sera peut-être très loin de son camarade à ce moment. Alors que pendant ce temps, PNJ2 qui ne faisait rien va attendre 3 seconde et répondre à un bonjour que PNJ1 ne lui aura pas encore donné. Bref, même cette solution peut s'avérer bizarre à éxécuter.

Voici donc une troisième version :

Code :

Cette solution pourrait paraître idéale mais ne l'est pas davantage. Cela dépend du contexte. Cette version vide la queue d'action des deux PNJs quand PNJ1 perçoit PNJ2 et place le court dialogue dans leur queue d'action. Donc, dans cette version, les deux personnage arrêtent ce qu'il sont en train de faire pour se parler l'un l'autre... Le problème de cette solution, c'est qu'après le dialogue, ils ne reprendront pas leur activité... Ben oui, on a effacé tout ce qu'on avait programmé dans leur petite tête.

Alors, pour finir, voici peut-être la version idéale (enfin disons la plus prévoyante) :

Code :

Dans cette version, quelle que soit l'activité de PNJ1 au moment ou il perçoit PNJ2, il le salue. Et quelle que soit l'activité de PNJ2 à ce moment, ce dernier le saluera en retour 3 secondes plus tard, et les deux PNJs continueront leurs actions courantes sans s'arrêter.
AssignCommand a ici une utilisation reflexe. On veut être sur que c'est bien le PNJ1 ou 2 qui va prononcer la phrase. Le SpeakString ne peut donc être exécuté que par le personnage correspondant. Imaginons que nous souhaitons lancer ce script dans d'autres conditions que le OnPerception. Dans ce cas OBJECT_SELF ne représenterait pas forcément PNJ1. Il nous faudrait sans doute récupérer une référence à PNJ1 en utilisant la fonction GetObjectByTag("PNJ1").

Bon... j'espère que tout cela ne te perturbe pas trop. J'ai voulu évoquer les différents cas de figure pour bien montrer que leur utilisation dépend d'un certain contexte, et la différence entre Action et pas d'Action est tout de même assez importante.

Lendraste
_________________
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

Tu es ....comment dire.... mon nouveau guide spirituel !
Tes explications sont parfaites, j'ai commencé le scripting hier soir et je comprends tout ce que tu me dis.
Merci beaucoup, je comprends encore mieux.

Xuyl a écrit :Je devrais songer à fonder une secte tiens !
Ravi d'avoir pu t'aider
_________________
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

"Dites don' ? Doc Lendraste, z'êtes bon !... Si,si, vous z'êtes bon !" (cf. à un film, ça évite les pubs...)
Tout ça pour dire que, ce sont de très bonnes explications, j'ai tout compris !
_________________
"Dans la vie, chacun prend son propre chemin. Mais en fin de compte, on se retrouve tous au même endroit..."

lendraste a écrit :On s'inscrit où ? ( Moi aussi; çà m'a pas mal mis de choses à plat

Moi moi , je veut en faire partie de votre secte Grand scripteur .