Préambule
Je voulais entamer ici un sujet d'une nature différente que ceux que l'on voit habituellement. Le but de la manoeuvre est de travailler progressivement sur un problème donné. C'est une sorte de tutorial sans en être un. Il n'est pas là pour diffuser une connaissance acquise mais pour la construire. En somme, ce sujet répond à un vieil adage : c'est en forgeant qu'on devient forgeron. Ici je l'adapte en "c'est en scriptant qu'on devient scripteur". C'est donc un coup d'essai. Si ce type de sujet ou le contenu que je lui associe n'intéresse personne, je le laisserai couler.

Comment ça marche ?
C'est très simple. Un problème est posé et chacun y va de son interprétation, de sa solution ou d'un morceau de la solution. Mais, la règle d'or est : On explique toujours la démarche de manière claire pour qu'un néophyte puisse comprendre et réutiliser ce savoir. Je connais au moins une solution de chaque problème qui se posera dans ce genre de sujet (d'autres peuvent être lancé par d'autres que moi évidemment). Mon intention est de décrire ma propre démarche. Mais les scripteurs amateurs ou "professionels" peuvent apporter leur pierre à tout moment, proposer des idées pour améliorer la solution. Ce que je ne veux pas voir est une solution toute faite, scriptée à la va-vite, et accompagnée d'un commentaire qui dit "mets ce script là, ça doit marcher". Le but est d'enseigner et je ne pose pas une question dont je n'ai la réponse et dont je ne puisse faire la démonstration complète. J'entends donc à ce que chaque élément apporté par les autres soient de la même trempe. De même, si la solution existe déjà, je précise qu'elle n'est d'aucun intérêt si la démarche de programmation n'est pas clairement détaillée. Je modérerai sans pitié ceux qui ne respectent pas cette règle afin que ce sujet ne devienne pas un monceau d'hypothèses farfelues. Donc, de la discipline et du bon sens dans vos interventions
Bien évidemment, les questions pertinentes sont accueillies avec joie. Le hors-sujet est exclu.

Au bout de la route
Au bout du compte qu'aurons-nous ? Un ensemble de script, des bibliothèques et des fonctions constituant la solution complète du problème posé (du moins une solution,, peut-être plusieurs), non seulement ça, nous saurons aussi comment fonctionne le cerveau tordu d'un scripteur, puisque sa démarche dans l'élaboration de la solution ou d'une partie de celle-ci sera expliquée. Je crois que c'est quelque chose de formateur pour tout ceux qui veulent se mettre au script ou aller un peu plus loin que les besoins les plus basiques.

Le problème en lui-même : la queue d'action infinie
Pour commencer cette expérience, voici le problème sur lequel je me propose d'élaborer une solution. Dans le cadre de divers besoins, j'ai très souvente fois été confronté à une limitation majeure de NWN : la limite de la queue d'action. La queue d'action est, je le rappelle, une structure abstraite rattachée à une créature du jeu (NPC et PC confondus) qui permet de stocker un certain nombre d'action à accomplir par la dite créature. Ouvrir une porte, marcher vers un objet ou un point de passage, attaquer une créature, suivre une créature, equiper un objet, prendre un objet au sol, etc... Le nombre d'action pouvant être accompli par une créature est très important, et il est possible de les enchaîner en les programmant dans la queue d'action.
Ceci permet de faire face à deux besoins :

1. réaliser des cutscenes en programmant les actions que chaque créature doit accomplir.
   
2. améliorer l'intelligence artificielle des créatures en proposant des suites de réactions plus ou moins complexes en fonction des circonstances.
   

Ces deux sujets m'intéressent fortement, mais se heurtent à une limitation. La queue d'action d'une créature ne peut stocker plus de 75 actions. Certains auront tendance à penser que c'est beaucoup, mais je n'ai aucun mal à remplir cette queue d'action lorsque je programme une cutscene, et donc, cela est préjudiciable. Le premier objectif de cette étude est de créer un moyen de dépasser cette limitation tout en assouplissant la méthode de création d'une cutscene.
A cela j'ajoute que je voudrais combler un autre besoin. Celui de pouvoir faire appel à un "programme" d'action. En somme, l'idée essentielle est de pouvoir réaliser dans une forme de pseudo-script qui serait stockée dans un fichier 2DA un programme qui me permette d'exploiter cette notion de queue d'action infinie, de telle sorte à pouvoir fournir des actions à l'infinie à une créature donnée.

Laissons mûrir
Une fois énoncée les données du problème, je laisse ceux qui le souhaitent, s'exprimer à la fois sur le concept ou réfléchir aux solutions que l'on peut bâtir. Il est a noter que j'ai essayé de simplifier au maximum l'expression du problème et que l'on peut sûrement aller beaucoup plus loin. Mais c'est aussi le but du sujet. Je commencerai à détailler ma propre démarche d'ici quelques jours. Dans le même temps, j'en profiterai pour paufiner mon prototype. D'ici à la fin du sujet, je suis sûr de pouvoir offrir une solution complète, mais j'espère que l'idée de base sera enrichie entre temps

Note de finipe : message repassé de post-it à normal, étant donné son inactivité notoire depuis un 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

Bah

Une action étant une fonction tu peux facilement combiner tout cela dans un DelayCommand, etc.
Donc je ne vois pas où se pose le problème ?
_________________
#nwnights-fr @ irc.darkmyst.org TitanQuest-FR

Baldurien a écrit :C'est typiquement le genre de réponse qui n'apporte rien au débat. Mais je sais combien tu es "paresseux" et je devine que tu ne risques pas de développer
Pour répondre, je dirais ceci :
Tout simplement parce qu'on peut annuler facilement 40 actions qu'on aurait placé dans la queue d'action, alors qu'on ne peut pas annuler facilement 40 DelayCommand. La queue d'action est bien moins consommatrice de ressource que des timers, elle permet, de plus, de synchroniser aisément les évènements entre eux. Je ne souhaite pas programmer une nouvelle queue d'action mais au contraire utiliser ses avantages tout en supprimant ses limitations. Le DelayCommand ne dispose d'aucune facilité de synchronisation, les temps etablis pour l'exécution étant absolu. Peut-être le DelayCommand est-il un bon moyen de créer cette solution, mais il faudrait en dire plus. Tu ne vois peut-être pas de problème, tout comme moi, et c'est tant mieux, mais je l'ai dis et le répète, le but de ce sujet est d'expliquer et non de se satisfaire de remarques oiseuses
_________________
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 vois en gros.

Mais la queue d'action n'est-elle pas non plus limitée par les capacités du personnage ? Je veux dire que si tu te gourre par exemple lui dire d'aller au point X quand bien même il ne peut pas, ça va bloquer quelque peu le personnage.

Ce n'est pas le cas avec le DelayCommand je trouve
_________________
#nwnights-fr @ irc.darkmyst.org TitanQuest-FR

Baldurien a écrit :Telle que fonctionne la queue d'action aujourd'hui, ce genre de cas de figure n'est pas un problème. Une action qui ne peut pas être accomplie s'annule et ne change rien à ce qui suit. Si l'action "qui ne peut pas être accomplie" était indispensable pour la réalisation de la suite, alors on se retrouve dans une impasse. Mais est-ce vraiment une limitation ? Ce genre de défaut peut, à mon avis, être comblé. Peut-être par le DelayCommand, qui sait. Il n'empêche qu'il me parait plus judicieux de profiter de la queue d'action et de ses avantages. DelayCommand manque de souplesse et est de toute façon déconseillée par Bioware et bon nombre de membres de la communauté. De plus, pour avoir déjà monté un prototype à base de DelayCommand, j'ai rencontré des difficultés insurmontables que la queue d'action a comblé, ne serait-ce que la possibilité d'être annulé.

Ensuite, il convient de se rappeler que l'on peut faire faire un peu ce qu'on veux à la queue d'action d'une créature, y compris y programmer des actions pour d'autres créatures, ce qui en terme de synchronisation est tout de même particulièrement souple. Je pense qu'une bonne customisation de la queue d'action est une approche extrêmement puissante.

Après ça, je ne peux pas empêcher un partisan du DelayCommand comme toi de produire une évidente et puissante solution à base de DelayCommand, mais il va falloir étayé un peu, car c'est le but du sujet
_________________
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

Et comment délayer des actions via la queue ? (c'est en train de tourner vers un certain côté là :

Je veux dire je voudrais que X fasse un truc après X secondes, mais le but de la queue d'action c'est qu'il fasse les actions une à une consécutivement ?
_________________
#nwnights-fr @ irc.darkmyst.org TitanQuest-FR

Pour le délai, il existe ActionWait.

Ce genre de thread me plaît bien, je vais essayer d'y contribuer comme je peux

Tout d'abord, un lien éventuellement utile : Préprogrammer des chaines d'actions par Azrael07. Je ne l'ai pas regardé en détail, mais ça pourrait sûrement aider.

Ensuite, j'adhère complètement à l'idée du 2da Pour moi, l'idée serait de créer des chaînes d'actions dans des 2da, utilisables ensuite n'importe où et n'importe quand. Ainsi, un 2da correspondrait à une suite d'action, et il suffirait de passer son nom à une fonction spéciale dans un script pour l'éxécuter.

La première colonne du 2da pourrait correspondre au type d'action, les colonnes suivantes aux éventuels paramètres de l'actin à éxécuter (objet, feat, etc.). Pour ne pas avoir à rentrer directement la valeur des constantes de Bioware dans le 2da, le script devrai créer une correspondance (nom de constante)[string] -> (valeur constante)[int]. Ainsi il sera possible de rentrer directement le nom des constantes dans le 2da, le script se chargera de les éxécuter.
La correspondance n'est pas très compliquée : au lancement du module, un script se chargera de lire le nom des constantes à partir de leur valeur dans les 2das originaux du jeu, et les sauvera dans des variables locales sur le module.

Les avantages de tout ceci:
- lisibilité et ergonomie des 2das
- encapsulation de comportements spéciaux, réutilisation multiple très aisée
- plus de limite de nombre d'actions, cela dit ...

L'inconvénient : Get2DAString est lent ! Et lire plus de 75 entrées d'un coup, c'est dur. La solution serait de précharger tout bêtement ces actions, mais il existe alors le risque de se retrouver avec des centaines de variables locales, ce qui n'est pas idéal. Je vois deux solutions à ça : d'abord, intégrer un paramètre "preloading" (par exemple dans la 1ere ligne du 2da) à 0 ou 1, selon que la chaîne d'action doit être chargée au démarrage du mod ou non. 2e solution : mettre à disposition une fonction de preloading de chaine d'action, ce qui permettra au builder de choisir à quel moment le gros ralentissement devra avoir lieu. Par exemple, preloader toutes les chaines d'actions à venir pendant que le joueur traverse une transition pourrait etre judicieux. De même, il faudra permettre au builder d'unloader une chaine d'action qui serait susceptible de prendre trop de place.
Eventuellement une dernière idée : échelonner le preloading sur un temps plus long avec des DelayCommand. Par exemple, le module pourrait lire une entrée du 2da toutes les 2 ou 3 secondes, ce qui permettrait de faire en sorte que le ralentissement soit moins perceptible. Bien sûr, il est nécessaire que ce processus soit lancé bien avant l'éxécution de la chaine. En tout cas, je n'ai jamais utilisé un tel procédé

A mes yeux, l'intérêt est présent surtout pour des petites chaines d'action à répéter à plusieures reprises. Même si utiliser des chaînes > 75 actions devrait être possible, je pense qu'il ne faudrait vraiment pas en abuser

Pas mal pour un début non ?

Ok, après de menues recherches, il semblerait qu'une variable locale ne prenne que très peu de place de toutes façons.
Pour un nom de variable entière de 10 lettres, on aurait :
2*10 octets pour le nom, 4 octets (à priori, même si ça semble débile ) pour le type, et 4 octets pour la valeur de la variable. 28 octets par variables, ainsi donc un millier de variables de ce type occuperait 28ko. Acceptable

Il faudra compter facilement de 800 à 1000 variables afin de créer la correspondance entre le nom de constante et sa valeur. De plus, une chaine devrais prendre entre 20e t 40 actions en moyennes, donc il faut prévoir environ 100 variables locales par action (faut penser aux arguments passés aux actions). Au final, je pense qu'on peut s'attendre à pas plus de 2000 variables locales, ce qui est largement raisonnable même si certaines prendront un peu plus de place que prévu.

En conclusion, précharger au moins les chaines d'actions les plus longues au lancement du mod me parait raisonnable. De toutes façons, une fois qu'une chaîne d'action aura été exécutée, elle sera gardé en mémoire pour une réutilisation ultérieure plus simple.

Cela dit, il faut avant tout s'assurer de pouvoir rendre le tout suffisamment flexible. L'intérêt pour moi est de pouvoir réutiliser un même comportement dans plusieures situations différentes. Par exemple, comment désigner l'objet vers lequel le PNJ devra se rendre ? Par son tag probablement, mais cela implique que tous les objets susceptibles d'être approchés aient même tag. Ainsi il faudra proposer plusiers désignations, par exemple : "tag:plc_01" ou "type:OBJECT_TYPE_DOOR". Plus j'y pense et plus ça a l'air faisable, mais ça risque de demander du boulot quand même

Avant de te laisser poursuivre dans cette voie de recherche, je voulais proposer une alternative aux deux solutions. Dans la mesure ou j'ai déjà imaginé et prototypé l'équivalent du préchargement en mémoire sous forme de variable, je précise donc que l'idée est bonne. Toutefois, pour ce qui est de l'usage direct du 2DA, il demeure possible. En fait, voici l'axe de reflexion que je me suis donné :

1. on ne peut pas risquer de saturer la file d'action. Même si on distille dans le temps les actions le risque de dépassement de la limite de 75 demeure. Je recherche donc une solution risque 0.
   
2. Il existe un autre risque majeur, celui du dépassement du nombre d'instruction (TOO MANY INSTRUCTIONS). Il faut parvenir à éviter ce risque en limitant au maximum le nombre d'instructions réalisé en une seule fois. Le DelayCommand permet de découper ce genre de processus, mais d'expérience, c'est une méthode que je souhaite éviter.
   
3. la lecture d'un fichier 2DA est lourde, sauf si nous n'avons qu'une ou deux valeurs à lire à la fois. Il est évident qu'un système qui parcoure un fichier 2DA est très très gourmand. J'ai déjà réalisé des systèmes de pré-chargement d'un fichier 2DA pour réaliser des menus dynamiques multi-niveau et pour une centaine de choix à charger, j'arrive à figer un PC pas trop mauvais pendant 4 secondes. Il est exclu de lire l'ensemble d'un fichier 2DA si ce n'est pas pour un pré-chargement, mais je veux pouvoir bénéficier de l'avantage des fichiers 2DA qui est de pouvoir être modifié dynamiquement par un programme externe et donc de faire bénéficier de ses modifications au reste du système. Un pré-chargement occulterait cette possibilité. La seule solution qu'il me reste est une lecture à la volée des données nécessaires.
   
4. j'en déduis que je dois trouver un système exploitant uniquement la queue d'action et permettant à chaque action devant être "jouée" de lire les paramètres de l'action proprement dite dans un fichier 2DA ou en mémoire à la volée.
   

En dehors de ces points, ton analyse sur le format des données me convient. Mon prototype définit le type des actions dans une colonne et rassemble les paramètres dans une unique chaine de caractère (donc parsing à effectuer selon les actions). En revanche je ne sais pas s'il est intéressant d'opter pour un système de correspondance des constantes.

Nanti de tous ces précieux renseignements, voici à quelle conclusions je suis parvenu :
J'ai créé une action qui s'appelle elle-même. En fait cette action lorsqu'elle se déclenche, joue l'action courante du programme défini, détermine la prochaine action a effectuer, et s'ajoute elle-même à la queue d'action. Elle ne se redéclenche que lorsque l'action courante est terminée. Il n'y a ainsi jamais plus d'une action dans la queue d'action, le cycle pouvant être brisé à tout moment comme l'utilisation normale de la queue d'action, le cycle pouvant être infini si on le souhaite. On peut envisager de créer des pseudo-actions qui sont en fait des boucles de programmes ou des sauts conditionnels et qui nous font avancer ou reculer dans notre programme, indépendamment des actions réellement jouée par la créature.
La lecture de la nouvelle action ne s'effectue qu'au moment ou elle peut effectivement être jouée. Certaines suites d'action "rapides" ou asynchrones peuvent surcharger un peu la machine en faisant plusieurs accès proches les uns des autres au fichier 2DA. C'est la seule faiblesse que j'entrevois laquelle peut-être palliée par le pré-chargement en mémoire ou un système de mémoire tampon (ce qui commence à être chiadé).
L'avantage d'avoir indifféremment la gestion du "programme d'action" en mémoire ou sur fichier 2DA permet d'envisager 2 modes de fonctionnement : le statique avec les fichiers 2DA et le dynamique en faisant créer un programme d'action en mémoire par n'importe quel script.
Dernier avantage significatif d'un programme d'action. Au fur et à mesure de son exécution, nous nous devons de conserver des informations sur son état. Si bien que s'il est interrompu, on peut se débrouiller pour le reprendre là où il a été stoppé.

Je laisse murir ces idées là avant de développer les différents aspects de cette solution.
_________________
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

Wow, on voit tout de suite l'informaticien

Moi aussi je vais laisser mûrir un peu tiens

Il est temps de reprendre un peu le sujet, vu que je suis l'un des rares à m'en occuper
J'avais évoqué dans mes précédentes interventions la technique de "l'action qui s'appelle elle-même". On pourrait l'appeler, l'action récurente ou l'action customisée. Peu importe. Je vais expliquer ici ce que j'entends par là.
Le but du jeu est d'inscrire une action dans la file d'action qui accomplit en fait deux choses. La première est qu'elle détermine et réalise une action prévue dans un "programme" d'action tel que nous les avons évoqué (sans nous être pleinement préoccupé de leur forme), et la seconde est qu'elle s'appelle elle-même de telle sorte à recommencer exactement la même chose.
Pour réaliser ce petit prodige, il convient de connaître une fonction du langage NWNScript qui s'appelle ActionDoCommand. Cette fonction transforme n'importe quelle procédure que nous pourrions écrire en une action pouvant être placée dans la queue d'action d'un PJ ou d'un PNJ. Il suffit donc de créer une procédure qui accomplissent les deux opérations décrire plus haut pour résoudre le problème posé.
Voici un extrait de code NWNScript qui décrit cette procédure :
Code :
ActionDoCommand va transformer CustomizedAction en Action qui sera ajouté à la queue d'action. Cela signifie que tant que l'action prévue par le programme d'action n'est pas terminée, CustomizedAction reste en attente dans la queue d'action.
Il n'y a plus qu'une chose à faire pour "lancer la machine" :
Code :
Cette instruction devra être utilisée pour lancer le programme d'action. Il nécessitera surement une initialisation (des variables stockée au niveau du PJ ou du PNJ doivent suffire). Une fois lancé, le programme d'action ne s'interrompt jamais, sauf si le personnage qui l'exécute est interrompu d'une manière ou d'une autre. En l'occurence, si nous exécutons un programme d'action sur un PJ, ce dernier l'interrompra en reprenant le contrôle de son personnage (si on l'y autorise). En faisant cela il "cassera" la queue d'action. De la même manière, la queue d'action d'un PNJ peut-être interrompue de différente manière par ce qui est programmé dans ses évènements de perceptions ou d'interraction. A partir du moment ou un script introduit un ClearAllActions suivi d'un quelconque action, le programme d'action est brisé.

A noter que, quoiqu'il arrive, il n'y aura jamais plus d'une action en attente dans la queue d'action, à moins que des évènements n'en ajoute. Ceci est d'ailleurs intéressant. Tandis que s'éxécute l'action courante du programme d'action, il est possible qu'un autre script introduise des actions supplémentaires. Lorsque CustomizedAction s'exécutera, elle placera la nouvelle action du programme à la suite dans la queue. Ce qui signifie que des actions introduites par des évènements étrangers pourront être joué quand même. Il y a d'ailleurs un choix à faire à ce sujet. On peut s'arranger pour qu'aucune action introduite dans la queue ne puisse empêcher le programme de se dérouler normalement. Il faudra donc insérer un ClearAllActions avant de placer l'action courante. Il pourra s'agir d'une option d'exécution du programme d'action. On peut même aller jusqu'à déclarer chaque action du programme comme non-retardable (donc avec un ClearAllActions avant) ou retardable (sans le ClearAllActions).

Bien entendu, une boucle sur l'autre, nous aurons pris soin de noter où nous en sommes dans notre programme d'action, ne serait-ce que pour déterminer quelle va être la prochaine action à accomplir. Nous disposons donc d'un compteur qui autorise les "reprises". Imaginons que nous voulions faire faire à un PNJ une suite d'action et que ce dernier est interrompu par différents évènements. Il nous suffit de relancer la CustomizedAction pour que le programme d'action reprenne là où il s'est arrêté.

Cela revient, en quelques sorte, à un équivalent du WalkWayPoints fourni par Bioware pour qu'un PNJ reprenne son circuit de déplacement. La différence ici est que son programme d'action peut être beaucoup plus varié. Toutes les prouesses d'un PNJ dépendent ensuite de la manière dont nous avons codé l'interprétation du programme d'action. Avec cette technique et l'existence d'un "compteur" d'instruction, le programme d'action peut lui-même comporter des sauts conditionnels (ce qui autorise les boucles). Il serait ainsi parfaitement envisageable de créer des programmes d'actions qui régiraient la vie de tous les jours des PNJs et qui les animeraient indéfiniment sans pour autant surcharger les files d'actions de ces PNJs.

La suite des opérations consiste donc à définir plus précisément comment nous pouvons écrire et interpréter notre programme d'action.
_________________
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

Lecture très intéressante, d'autant plus que j'ai encore à aborder la question des "Actions infinies" dans mon module, une vraie calamité pour tout builder.

A moins de me tromper, ce qui est possible , il n'est possible d'avoir que 75 actions dans la Action queue. Est-ce que tu penses qu'il y a des conseils à donner pour éviter les plus grosses "bourdes" en la matière ?

Merci

Cheyenne a écrit :Je pense que la plus grosse bourde est de penser qu'il n'y a pas de limites, et je l'ai commise. 75 peut paraître élevé, mais j'avais, une fois, programmé une animation automatisée qui produisait plus 200 actions pour faire accomplir au PJ un rituel magique. Comme quoi c'est une limite facile à dépasser. A l'époque la limite était tacite mais également bugguée, c'est à dire que le moteur indiquait que la limite était dépassée, mais il les jouait quand même. Mais pour le reste, ce n'est pas vraiment un problème que de remplir les 75 actions de la queue, ce ne sont jamais que des files d'informations et elles ne consomment que de la mémoire. Ce n'est pas comme le DelayCommand qui lui consomme du temps machine et dont le nombre peut parfois devenir assez important pour que le moteur "oublie" d'en exécuter certains.
Donc le véritable problème est et demeure, de ne jamais dépasser la limite de 75.
_________________
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 :J'ai remarqué une petite chose : si une action est présente dans un ActionDoCommand(), le script s'arrête prématurément, donc à prioris il est impossible d'utiliser cette solution...

Tzeentsh a écrit :Tu pourrais expliciter ton argument là ? Avec un exemple s'il te plaît. Je ne comprends strictement rien à ce que tu veux dire. Je tiens à préciser que cette solution fonctionne puisque je l'exploite, alors si j'ai manqué quelque chose j'aimerai savoir quoi
_________________
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

Humf me serais-je trompé... Je ne vais pas montrer d'exemple car il était très simple (j'avais simplement inserré des actions avant le dernier ActionDoCommand()) mais ça ne fonctionnait pas.

Les actions se jouaient, mais une seule fois : le script ne bouclait pas donc j'en déduis que c'est la dernière action qui plante.

Tzeentsh a écrit :Je serai tenté de dire que si l'action que tu lui faisais faire risquait de faire vider la queue d'action de la créature, le script ne peut effectivement pas boucler. Petite précision à ce sujet, les scripts par défaut de Bioware étant bourrés de ClearAllActions et d'interaction possible, il vaux mieux employer cette technique sur des créatures "clean". Les PJs et les créatures dédiées à l'usage de cette technique s'y prête très bien. Les premiers pour la possibilité de faire jouer au PJ une suite d'action interruptible à tout moment, la seconde pour préparer une sorte de programme parallèle donnant des ordres ou diffusant des informations. En se débrouillant bien avec l'ensemble de la technique (c'est à dire Queue d'Action Infinie et Programme d'Action) les plus folles solutions sont envisageables. Par exemple on peut créer un programme d'action qui bouclerait sur lui-même pour faire agir un PNJ (lui programmer sa journée entière d'activité par exemple. Ca peut remplacer très avantageusement le classique système de "ronde") sachant que s'il est interrompu, le programme d'action peut-être relancé au point où il s'était arrêté, l'interruption pouvant être gérée au cas par cas avec les autres évènements programmables.
J'aimerai bien continuer le développement de ce sujet d'ailleurs, car ma solution est aujourd'hui très avancée et remplie d'idées de ce genre. J'espère avoir le temps de transcrire tout cela par écrit.
_________________
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

Autant pour moi, j'ai recréé un script test et il boucle parfaitement (Les mystères de l'informatique...). J'ai cependant rencontré un problème de taille au niveau du ActionWait() :

Lorsque je place des délais relativement court comme 30.0f ou 60.0f, tout se déroule parfaitement, mais un délai de HoursToSeconds(24) n'a pas fonctionné, et cela avec le même script.

Un ActionWait() trop long s'interromp t'il tout seul ?

Tzeentsh a écrit :C'est très possible. J'ai toujours pensé qu'il pouvait y avoir une limite au ActionWait, mais j'ignore laquelle. Je me suis dit (car je n'ai pas encore terminé cette partie là) que pour les délais d'attente de longue durée, il faudrait sans doute prévoir plusieurs appel à ActionWait.
Quoiqu'il en soit, je te félicite d'avoir testé le HoursToSeconds(24), ce qui fait 48 minutes d'attentes avec les paramètres par défaut d'un module. J'essaierai de découvrir si le ActionWait a une limite, mais si tu as encore le temps de faire des tests, n'hésite pas
_________________
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 pars au ski une semaine donc tu auras le loisir de faire mumuse pour trouver les limites.

Cependant, bien que cette limite soit gênante, elle reste largement préférable à un DelayCommand() de HoursToSeconds(24)...

Je suis également tombé sur un message de FastFrench, sur un autre forum, qui expliquait qu'à partir d'une centaine de variables locales sur un même objet cela commençait à lagguer. Utiliser différents PNJs pour les queues d'action permet de limiter très fortement ce phénomène puisque :

- Ce système utilise beaucoup moins de variables locales.
- Ce système permet de les répartir sur différents objets très aisément.

En d'autres termes il s'agit bien de l'ultime solution, reste à explorer les limitations

Au niveau des tests, le ActionWait() fonctionne parfaitement jusqu'à 600.0 : je n'ai pas testé au delà.

Mais reste le problème des temps supérieurs à 75 * Limite pratique de l'ActionWait() puisque selon toi la queue d'action ne peut comporter plus de 75 actions.

Deux petites questions sinon :
- Une créature morte mais non détruite peut-elle utiliser une queue d'action ?
- Les placeables et les créatures peuvent avoir une queue d'action. Les area et le module peuvent-ils également s'en voir assigner une ?

Tzeentsh a écrit :Ce n'est pas vraiment un problème. Avec le principe que j'ai évoqué, il n'y a jamais plus de 2 actions à la fois dans la queue d'action. La première action est l'action courante, la seconde est un programme qui détermine la prochaine action courante à placer dans la queue d'action et qui se replacera lui-même en seconde action, et ainsi de suite. Ce programme peut donc aller chercher une liste d'action potentiellement infinie. Attendre un certain temps avec des ActionWait les uns à la suite des autres peut donc être mis artificiellement en place par une boucle du "programme d'action" ou une primitive que l'on aura conçu à cet effet.
Par exemple, si on admet que l'ActionWait a une limite on peut s'arranger pour que le temps d'attente soit découpé en plusieurs ActionWait de durée fixe + une durée supplémentaire pour ajuster le temps d'attente global. Mais la liste de tous ces ActionWait quelle que soit leur durée n'est pas implantée dans la queue d'action directement, mais une par une dans le programme d'action, lequel est "joué" par la procédure qui fait boucler la queue d'action.


Citation :Honnêtement, je ne sais pas. Je n'ai jamais essayé.


Citation :A ma connaissance, les plaçables n'ont pas de queue d'action, seule les créatures en ont. A moins que cela ait changé récemment, mais je m'en étonne. Les Area et le Module n'ont pas non plus de queue d'action. Il est vrai qu'on peut "affecter" une action à tous ces objets (ça faisait même planter NWN quand on le faisait sur l'Area ou le Module dans les anciennes versions), mais elles n'ont théoriquement aucun effet (quoi que je ne l'aie pas testé pour toutes les actions).
_________________
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

Salut Lendraste,
mon module est congestionné par les DelayCommand(), au point que le temps arrête de s'y écouler.
Je pense que la queue d'action pourrait résoudre mes problèmes. Pourrais-tu nous faire profiter de tes scripts s'il-te-plait ?

Je ne crois pas qu'il y ait de "script tout fait miracle pret à l'emploi qui soulager magiquement ton module"...

C'est, je pense, plutot à toi de donner tes scripts plein de delaycommand pour qu'on le transforme en queue d'action...

M'enfin, ça reste à Lendraste de répondre, ce n'est que ma vision de la chose apres tout...
_________________
http://perso.wanadoo.fr/kikitor | Deviant Art | www.VistaEntraide.com | CCLLSELFV! | D-lire_K | Viendez rêver au Pays des fées... | Ne taquinez pas l'admin!

Ma foi je vois la queue d'actions comme un ensemble de fonctions (ou une bibliothèque) qui peuvent être utilisées indépendemment du type de module. Comme Lendraste a dit plus haut qu'il l'utilisait déjà et ce depuis un certain temps, j'ai pensé qu'il pourrait peut-être nous en faire profiter.