La Couronne de Cuivre

J'ai la situation suivante à gérer:
- un PNJ se déplace vers un point sur la carte.
- Si le PNJ voit le groupe sur sa route, il s'arrête et entame le dialogue. Sinon il va au point attendu et s'arrête.

Au niveau codage:
Si je fais deux blocs:
-1 MoveToPoint sur le PNJ pour le déplacement
-2 SEE pour voir les PLAYER

Le PNJ se dirige vers le point puis il peut voir les PLAYER. En gros, il est focus sur le déplacement même si le groupe est visible sur sa route.

D'habitude pour palier à ce problème, je déclenche une interruption toutes les 2-3 pour savoir le si les PLAYERS sont vus (GlobalTimer + ClearActions). Sinon je relance le déplacement.

Je trouve cette méthode un peu lourde. Est-ce qu'il y a un code plus simple pour gérer ce besoin?

Dans ce cas pourquoi ne pas avoir une créature invisible sous célérité faisant le travail pour ton personnage? Elle suit ton perso avec un MoveToObjectFollow et écrase son comportement si elle aperçoit un membre du groupe?

As-tu essayé d'inverser l'ordre des conditions ? Il faut toujours placer les plus faibles en premier (sinon elles ne sont jamais évaluées et passent à la trappe) et les plus fortes en dernier (afin qu'elles "n'écrasent" pas les autres) ? Donc mettre d'abord les conditions liées au répérage des PNJ en premier, puis le bloc lié au déplacement.
En mettant un Range, tu peux faire en sorte que la condition ne se vérifie qu'à partir d'un certaine distance.

Schématiquement ça donne un truc comme ça :

IF[INDENT]...[/INDENT]
[INDENT]Range(NearestPC,x,LESS_THAN)
See([PC],0)
[/INDENT]
THEN[INDENT]MoveToObject(NearestPC)[/INDENT]
[INDENT]StartDialog ...[/INDENT]
END

IF[INDENT]!See([PC],0)
...
[/INDENT]
THEN[INDENT]MoveToPoint (x,y)
...[/INDENT]
END

Faust, Luren, merci pour vos retours.

Faust> pour mettre les 2 actions sur un fichier distinct, le plus simple, pour moi est d'utiliser un fichier .baf pour le PNJ et le fichier .baf de la carte.

Luren> J'ai pris en compte ton conseil. Ordonner le code sur le fichier .baf du PNJ et mettre d'abord le code de détection puis le code de déplacement.
J'ai simplifié le code à mort (suppression du Timer etc...).

Résultat agréable ça fonctionne dans les deux cas.

Du coup, je me suis dit, je vais inverser les codes des actions pour confirmer que c'est bien l'origine du problème. Résultat: ca fonctionne aussi.
Bah là, j'en perds un peu mon latin.

Des problèmes différents où j'ai dû m'adapter avec un timer pour gérer les déplacements interrompu de PNJ et faire mon test, je n'avais jamais réussi à faire quelque chose d'aussi simple et efficace. Les deux différences je dirai sont:
- que je n'avais pas forcément les deux actions sur le pnj en question mais au moins le déplacement sur le .baf de la carte.
- que le mot clé était MoveToObjectFollow sur le PLAYER1.

Je note que MoveToPoint peut être interrompu facilement avec les deux actions sur le script du PNJ.

Cocrane

Du coup, je me suis dit, je vais inverser les codes des actions pour confirmer que c'est bien l'origine du problème. Résultat: ca fonctionne aussi.
Bah là, j'en perds un peu mon latin.

Tout dépend des conditions que tu mets dans ton script. Si elles sont suffisamment précises et restrictives, l'une ne prend pas le dessus sur l'autre. C'est quand on veut mettre des conditions simples, qui donc se vérifient prioritairement, qu'il faut les placer en dernier. Si les conditions sont toutes deux aussi restrictives, de sorte que l'une ne risque pas de se vérifier en empêchant l'autre d'être évaluée, peu importe leur ordre.
Par exemple :
Si je vois un ennemi, mage, elfe équipé d'un bâton -> faire ceci
Si je vois un ennemi équipé d'une arme à distance -> faire cela
Si je vois un ennemi -> faire ceci

Si tu mets la troisième condition en premier, les deux autres ne seront jamais évaluées et passeront à la trappe. Mon exemple est très simple et ne pose pas de problèmes, mais selon les cas, il faut bien vérifier que les différents bloc de conditions ne terminent pas le script sans que certaines conditions n'aient été évaluées alors qu'on voulait qu'elles le soient.
C'est un problème d'organisation du script auquel je me heurte souvent, et ton problème me faisait penser à quelque chose de similaire... d'où ma remarque !

Si tout marche bien, c'est nickel. C'est vrai que quand un script marche, c'est une bonne chose de voir s'il ne pourrait pas marcher tout aussi bien en le simplifiant !