Bonjour, je prend petit à petit la mesure de ce forum, un superbe travail IMHO. Cela ne fait que 2-3 semaines que j'ai NWN (1.32) et je me suis rapidement décidé pour ne jouer qu'en MJ et ce dans le rôle d'un MJ (d'où le titre quelque peu vaseux d'un précédent topic )
Or donc, me voici en pleine construction d'un premier module, avec deux buts bien arrêtés : le plus réaliste possible, compte tenu des possibilités d'Aurora, et nécessitant l'intervention d'un MJ. Je suis motivé à plus d'un titre : j'ai une expérience de plus de 15 ans aussi bien en programmation en C qu'en maître de jeu ... tout cela ne _me_ rajeunit pas ! Présentation nécessaire, puisque je compte user et abuser de ce forum
Le problème du jour : j'ai créé une zone "hivernale" et je souhaite que les PJ subissent des dommages régulièrement (s'ils n'ont pas de vêtements chauds mais ce sera pour la version 0.1b). J'ai donc écrit un script que j'ai rattaché à l'évènement "onHeartbeat" de cette zone. Cela fonctionne dans la zone mais l'effet persiste dans la zone suivante J'ai pensé résoudre le problème en créant un script "rien()" pour le "onHeartbeat" de la zone suivante mais cela ne fonctionne pas. Si quelqu'un pouvait m'indiquer d'où vient le problème ? Merci d'avance. Ci-joint, le script en question (pompé dans un autre sujet) :

C'est tout-à-fait normal que l'effet "persiste". Le script du OnHeartbeat de cette zone hivernale continue de se déclencher toutes les 6 secondes, même si les pj ne sont plus dans la zone ! Or, 'GetEnteringObject()' renvoit à l'objet qui est entré en dernier dans la zone. Bref voici une version corrigée de ton script :



Note que ça me paraît un peu sévère -1 pv/round, sauf s'ils sont pris dans le blizzard... On peut très bien imaginer que ce soit plutôt -1pv/tour, mais ça, c'est à toi de voir. On peut imaginer également des dommages plus importants au cas où l'un deux aurait l'idée saugrenue de ne pas mettre d'habits du tout !
_________________
ToB : Une seule chose semble certaine : tant que le trône de sang de Bhaal restera vide, le chaos règnera.

Moi : Une seule chose semble certaine : tant que la tête de singe de Bush restera vide, le chaos règnera.

Je te remercie pour ta réponse plus que rapide ! Je pense avoir saisi le rôle d'"OBJECT-SELF" mais cela signigie donc que tous les évènements du type "onHeartbeat" sont cumulatifs si l'on ni prend pas garde ? Je pensais que c'était une gestion évènementielle avec signature (de la zone en l'occurence) ... Quoiqu'il en soit, merci.

PS : puis-je faire quelque chose d'équivalent pour certains carrés d'une zone (par exemple, de rivière) ? Ca me donnera une idée plus précise des possibilités d'Aurora, merci.

Je vais répondre moi-même Avec un "déclencheur", j'ai bon ? Dans la même veine, on a parlé dans un autre topic de rivières infranchissables mais je n'ai pas encore trouvé ça (est-ce dans un hak pack) ?
Et si tu pouvais m'indiquer la ou les instructions qui permettent d'occasionner ces blessures plus lentement (i.e par tour), je t'en serais reconnaissant

Juste une suggestion (à confirmer) : peut-être en mettant des triggers sur les morceaux de zone où tu veux appliquer ce genre d'effet, en prenant la personne qui rentre dans le trigger. Après il est peut-être possible de gérer ça en fonction de la position du joueur dans la zone (avec ses coordonnées).

Edit : quasi en même temps Pour les rivières infranchissables, il me semble qu'elles sont présentes dans certains des tilesets de base mais pas tous. Après il y a du y avoir des haks pour les inclure dans les autres tilesets et certains tilesets faits de toutes pièces
_________________
Sacred - FR - La Bibliothèque de Neverwinter - Titan Quest - FR
Bloqué dans SoU ? La solution n'est pas loin...
HotU vous pose des problèmes ? Une seule solution

Pour les dégâts par tour et non par round, j'imagine qu'il me suffit d'utiliser l'arithmétique modulaire (ici 6) ? Je ne me suis pas encore donné la peine d'essayer car malgré l'utilisation de la fonction GetArea(), il semblerait que l'effet de l'évènement "onHeartbeat" se fasse sentir à présent dés le début du scénario. Et quand je le duplique dans une autre zone (elle aussi hivernale bien sûr), l'effet est (bien) cumulatif (2 PdV/r) ! Je ne maîtrise donc pas du tout l'effet désiré (basé par facilité sur "onHeartbeat" jusqu'ici)

Merci Gorkk pour les effets déclenchés et pour m'avoir confirmé l'existence de différents cours d'eau suivant les tilesets. C'est dommage que l'on est pas inclu ce type de propriété dans les "propriétés du carré de terrain".

Merci Lavok et Gorkk ! En forme de préambule : non je n'ai pas bu Voilà le topo : j'ai 3 zones, A, B et C. La zone A est ma zone de départ. Seules les zones B et C ont comme évènement "onHeartbeat" le script proposé par Lavok. Je n'ai défini aucun évènement "onHeartbeat" pour le module. Ce qui se passe : mon PJ "test" apparait (dans la zone A) et se prend -2 PdV/r tout de suite (-1 par évènement "onHeartbeat" existant pour l'instant) ? Comprend pas. A moins que la fonction GetArea() ne fait pas ce que je crois, je ne vois vraiment pas. Toute suggestion accueillie avec gratitude si ce n'est soulagement intellectuel.

PS : je n'ai pas vu trace d'attribut "static" pour les variables locales, donc si je veux appliquer les dommages tous les N rounds, je dois passer par une variable globale (beurk) ?

Je me permet d'intervenir un peu à contrepied des solutions proposées jusqu'alors qui se fixent sur le OnHeartBeat de toute zone ou déclencheur. Je rappelle (ou précise) qu'il est déconseillé d'utiliser trop de OnHeartBeat. De plus, la solution proposée par Lavok possède un gros défaut. Tout d'abord, il faut distribuer le script sur autant de zone ou de déclencheur que d'endroit où l'on veux prendre en charge les dégâts dus au froid, et d'autre part, chaque fois que ces scripts se déclenchent, ils font tous la même chose : ils parcourent la liste des joueurs connectés pour savoir si ceux-ci sont ou non présent dans la zone (soit dit en passant le déclencheur c'est un peu plus délicat). Ce qui fait que dans un module où 10 zones de froid sont à gérer, 10 scripts OnHeartBeat vont parcourir la liste de tous les PJs en même temps pour savoir s'ils sont "là" ou non. Un PJ ne pouvant se trouver qu'à un seul endroit à la fois, une grosse partie de ce temps machine est purement et simplement gaspillée.
Je préconise donc de s'arranger pour ne faire qu'un unique parcours de la liste des PJs toutes les 6 secondes (par exemple en plaçant le script dans le OnHeartBeat du module). Le tout est de pouvoir déterminer simplement si un PJ doit ou non subir des dégâts. Plusieurs solutions sont possibles pour les zones :
- La zone marque le PJ quand il entre dans une zone de froid et le "démarque" quand il en sort. Cette marque peut-être une variable stockée sur lui.
- Le nom ou le tag de la zone peut-être comparé à une liste de nom ou de tag de zone considérée comme froide (l'une de mes technique favorite en terme de maintenance est de maintenir une liste de zones dans une variable chaine de caractère, séparée par un séparateur, et de chercher grace à la fonction FindSubString si le nom de la zone courante du PJ se trouve dans cette chaine)
- Le nom ou le tag de la zone est formaté de telle manière à préciser sa nature. Genre un tag qui porterait un prefixe ou un suffixe indiquant la nature de la zone. Exemple : Z_MAZONE_F (_F pour froid), Z_MAZONE2_N (_N pour normal). Je suggère de travailler sur le TAG plutôt que sur le nom ou le resref. Le nom s'affiche et le ResRef ne peut être changé une fois la zone créée.

Le cas d'un déclencheur est plus subtil. La première solution proposée convient aussi bien pour une zone et un déclencheur, mais on ne peut guère appliquer les deux autres méthodes puisqu'on ne peut savoir qu'un PJ se trouve ou non dans un déclencheur qu'à partir du moment où il y est entré ou qu'il en est sorti.

En terme de développement, je préconise un mélange de solution. Il suffit de créer un déclencheur personnalisé dont les scripts OnEnter et OnExit sont écrits. A chaque fois que l'on déploie un tel déclencheur, il n'y a rien d'autre à faire. Quant aux zones, la troisième solution me paraissait la plus simple à retenir.

Cela étant, je voulais pousser la reflexion un peu plus loin. Le réalisme étant de mise dans le module, se pose le problème des PNJs. Pour le moment seuls les PJs sont les victimes des intemperris, mais qu'en est-il des PNJs et autres monstruosités du coin ? On peut résoudre le problème en prétendant qu'ils sont tous adaptés à leur environnements ou vêtus comme il convient. Mais n'y en a-t-il pas un qui ne le sera pas ? Dans ce cas, les solutions évoquées jusque là ne s'appliquant que sur les PJs, il faut prévoir d'élaborer une autre solution. Et c'est véritablement problèmatique puisque le nombre de PNJ à parcourir peut être très conséquent... Pour l'instant je ne vais pas développer cet aspect, car je comptais aller me coucher avant de tomber sur ce sujet . De plus, je suis désolé de ne fournir aucun script, mais pour répondre à la dernière interrogation et pour l'avoir testé moi-même il y a un petit moment, la comparaison d'objet de type Area n'est pas très fiable.
_________________
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

Haaa, voilà une réponse qui va me permettre de m'initier en profondeur à la conception de scripts NWN. Merci lendraste, j'espérais bien une intervention de ta part J'ai bien noté en parcourant les forums que l'utilisation du onHeartbeat doit se faire avec parcimonie et effectivement l'utilisation de celui-ci au niveau du module me semble plus adéquate dans ce contexte. Le traitement du nom du tag pour déterminer le type de zone m'a particulièrement intéressé. L'influence du (mauvais) temps sur les PNJ m'a effleuré mais mon esprit s'est convulsionné sous l'ampleur de la tâche
Je vais moi aussi pouvoir aller me coucher l'esprit (presque) tranquille.