[Module] IsoWalk (ex Use motsly the 8 Directions - U8D)

Sans doute, en tout cas, ça mérite d'être testé...
...il me reste juste à avoir le courage de m'y mettre (parce que si j’attends dans avoir envie, je m'y mettrai jamais).

Oui enfin il n'y a pas obligation non plus ! Dans tout les cas je pense et j'espère que le bug sera suffisamment rare (et sans gravité) pour que ça ne gâche pas le jeu. A mon avis beaucoup de joueurs joueront sans le voir, dans la mesure où on se déplace rarement beaucoup dans tous les coins quand on joue à un point & clic, contrairement à moi quand je teste mon jeu.

Si un courageux codeur passe par là, d'après ce que j'ai compris, le pathfinder d'AGS est codé ici (mais je ne suis pas tout à fait sur que ce soit la version actuelle ?). Il s’agit de l’algorithme Dijkstra, disponible en pseudocode sur wikipedia, par exemple. Idéalement, il suffirai dans un premier temps de relire le code AGS (ligne 386 à 634), et de vérifier qu'aucune erreur d'étourderie ne c'est glissée dedans par rapport au pseudo-code originale.
Mais malheureusement, mes maigres compétences en C/C++ ne me le permette pas encore...

EDIT : En fait, d'après ces quelques lignes :

Code:

//ligne 573
  int is_straight = 0;
  if ((srcx - tox[0] == 0) || (srcy - toy[0] == 0) || (abs(srcx - tox[0]) == abs(srcy - toy[0])))
    is_straight = 1;
//ligne 603
  if (is_straight)
    ; // don't use new algo on arrow key presses
  else if (find_route_dijkstra(srcx, srcy, tox[0], toy[0])) {
    return 1;
  }

Djikstra n'est appelé que dans le cas de mouvement qui ne SONT PAS selon les 8 directions. Il faut donc chercher le bug ailleurs. Reste plus qu'à trouver cet "ailleurs", et ce n'est peut être pas l'implémentation de dijkstra le responsable.

EDIT 2: Du coup, il faut sans doute analyser le code de la fonction try_this_square (lignes 253 et suivantes), ou encore ailleurs, find_route (ligne 722 et suivantes).

Vu le caractère spécifique du bug, je doute que ça soit très simple...

Sinon, il faudrait que je trouve un moyen de transformer ça en gag, une sorte d'easter egg imposé

Tiens donc, je viens de remarquer que "U8D_UseAlternateHorizontalPath" et "U8D_UseAlternateVerticalPath" ne fonctionnent plus quand j'y fais appel dans ma room. Pourtant elles sont bien importer dans le GlobalScript.ash et sont reconnues par l'autocomplétion.

C'est bien comme ça qu'il faut y faire appel en haut du script ?

Code:

U8D_UseAlternateHorizontalPath = true;

valoulef a écrit:

C'est bien comme ça qu'il faut y faire appel en haut du script ?

Il faut le mettre sous un déclencheur, quand même. Par exemple le function room_Load().

Ah ok mince je pensais avoir fait comme ça la dernière fois... Merci !

Bon, tant qu'à mettre la poussière sous le tapis, autant le faire en publique.
Résumé des épisodes précédents : valoulef a trouvé un bug étrange dans mon module, et Kitai a brillamment démontré que le bug était dans AGS et pas dans mon module (ce qui explique pourquoi je ne trouvai pas le bug dans mon module).
Après quelques analyses, il apparait qu'AGS utilise deux pathifinder différents : dijkstra par défaut, et le old pathfinder dans les lignes droites et les diagonnales à 45°. Le bug est a priori dans le old pathfinder, mais comme je ne comprend rien au code, je n'arrive pas du tout à le trouver. Une des solutions serai de compiler le moteur AGS en remplaçant les lignes 603 et suivante du route_finder.cpp :

Code:

if (is_straight)
  ; // don't use new algo on arrow key presses
else if (find_route_dijkstra(srcx, srcy, tox[0], toy[0])) {
  return 1;
}
// A remplacer par :
if (find_route_dijkstra(srcx, srcy, tox[0], toy[0])) {
    return 1;
}

Il faudrait ensuite voir si ça ne fait pas crasher le moteur, et si ça ne casse pas trop les mouvements au claviers et autres WalkStraight.
J'ai voulu le faire, mais je suis tellement nul que 1) je n'arrive pas à configurer les compilateur C++ ni de CodeBlocks, ni de Visual C++ Express 2008 et 2) je n'arrive pas à importer le projet sous ces IDE. Du coup je suis plutôt allé apprendre Löve2D, ça a l'air sympa et puissant, mais un peu long a mettre en place : il faut par exemple coder soit même les collisions, etc. Du coup j'ai acheté le Humble Deep Silver Bundle et je joue à Dead Island. Ca, ça va, j'y arrive à peu prés : il faut taper sur des zombis avec une batte de baseball à scie circulaire (ou une machette électrifié, au choix).
Mais tout ça ne résout pas notre problème. Problème que j'ai d’ailleurs signalé chez les Rosbifs ici et là, sans grand succès pour l'instant.
Du coup, une solution provisoire serai (comme l'a suggéré Kitai) de décaler les positions des points intermédiaires de +3 /+3 (résolutions de la grille de pathfinding dans AGS), pour déclencher djikstra et non le old pathfinder, en espérant que ça n'induise pas d'effet de glissement des personnages (ce qui serai paradoxale !). Et j'ai un peu la flemme de le faire en ce moment. Donc soit vous me suppliez de le faire quand même, et je me laisserai peut-être apitoyer, soit vous le faîtes vous mêmes, soit je tombe sur coffre remplit de motivation et je le fait quand même (mais aucun coffre à porté de vue).

Je serais bien tenté de te supplier, mais après tout le mal que tu t'es déjà donné j'ai un peu de scrupules  C'est vraiment compliqué à mettre en place la solution de Kitai ?

Le bug est moins rare que je l'espérais malheureusement, surtout dans certaines pièces où on ne s'est clairement pas facilité la tâche (enfin surtout la tâche d'AGS) niveau zones de déplacements. C'est vrai que le pathfinding d'AGS a l'air un peu codé avec les pieds, d'ailleurs si ce bug était mon seul problème ça serait bien. Des fois mon perso fait des trucs assez bizarre, ou par exemple la vue de profil est déclenchée dans un déplacement (glissé, à un moment ou l'U8D walk ne peut pas se déclencher) alors que la vue de 3/4 serait préférable. Après c'est peut-être une question de perspective, je ne sais pas. Bon, je relativise un petit peu tout ces problèmes après avoir vu l'immense bâclage (pour ne pas dire escroquerie) qu'est Yesterday, mais quand même, y'a du boulot avant que les déplacements de Sam soient propres

PS : Ce message rompt l'inquiétant silence qui règne ici depuis maintenant 3 jours  

Coucou valoulef !

valoulef a écrit:

C'est vraiment compliqué à mettre en place la solution de Kitai ?

Nan, c'est tout simple, mais j'ai la flemme de faire une nouvelle version. Le plus simple, le plus propre et le plus rapide c'est que tu le fasses de ton coté.
En fait, il faut juste modifier les lignes suivantes en rajoutant des "+3"

Code:

// lignes 67 à 77
    if ( WWhere == eWalkableAreas) {
      if (GetWalkableAreaAt(xP1+3-GetViewportX(), yP1+3-GetViewportY()) !=0) { //if P1 is in a WA, we use it
        xWP = xP1 + 3;
        yWP = yP1 + 3;
      } else if (GetWalkableAreaAt(xP2+3-GetViewportX(), yP2+3-GetViewportY()) !=0) { //if P2 is in a WA but not P1, we use P2
        xWP = xP2 + 3;
        yWP = yP2 + 3;
      } else { //is not P1 neither P2 are in a WA, then we give up
        xWP = x;
        yWP = y;
      }
// lignes 87 et 88
      if (BStyle == eBlock) {
        this.Walk(xP1 + 3, yP1 + 3, eBlock, eAnywhere);

Avec ce code, la variable is_straight du moteur sera fausse (les trajets ne sont pas exactement droits), et djikstra sera appelé à la place du "vieux pathfinder", du coup on évite le bug sans doute présent dans le vieux pathfinder (j'ai testé, ça marche bien). En revanche, on a plus des horizontales, verticales et diagonales exactes, mais sur des relatives grandes distance dans un projet haute résolution, ça ne devrai pas trop se voir. Tu peux aussi remplacer les "+3" par des "-3" si ça rend plus joli...

valoulef a écrit:

C'est vrai que le pathfinding d'AGS a l'air un peu codé avec les pieds

Je ne dirai pas ça, quand même : même moi qui suis novice en C++ j'ai compris la structure et la logique du code. En revanche il reste un ou deux bug, comme ça nous arrive à tous d'en faire...

valoulef a écrit:

Des fois mon perso fait des trucs assez bizarre, ou par exemple la vue de profil est déclenchée dans un déplacement (glissé, à un moment ou l'U8D walk ne peut pas se déclencher) alors que la vue de 3/4 serait préférable. Après c'est peut-être une question de perspective, je ne sais pas.

As-tu essayer de modifier la valeure de l'option du général setting "Characters turn before walking" ?

valoulef a écrit:

PS : Ce message rompt l'inquiétant silence qui règne ici depuis maintenant 3 jours

C'est la semaine du 15 août, beaucoup doivent être en vacances sans forcément avoir un accès internet ou voulant un peu se déconnecter, ça ne m’inquiète pas trop.  

Merci beaucoup, je vais tester ça. Si ça supprime le bug, ce sera déjà une belle avancée

EDIT : Ça a l'air de marcher ! Ça ne règle pas tous mes problèmes, mais ce bug, qui était le plus grave, est enfin corrigé ! Merci mon petit génie (ainsi que son souffleur ), vous m'enlevez encore une fois un belle épine du pied !

EDIT n°2 : J'avais déjà fait la remarque que mon perso faisait parfois du surplace pendant un laps de temps dans des zones de déplacement étroites. J'ai l'impression que c'est causé aussi par le module (ou un mix entre le module et le pathfinding), car cela intervient au moment du changement de direction. Je le signale juste à titre indicatif.

Billbis a écrit:

Je ne dirai pas ça, quand même : même moi qui suis novice en C++ j'ai compris la structure et la logique du code. En revanche il reste un ou deux bug, comme ça nous arrive à tous d'en faire...

Ce n'est pas parce qu'il est clair qu'il est bien codé ;)Bon mais je reconnais que c'est un peu facile à dire de ma part, et je suis un peu dur mais je ne trouvais pas de façon plus douce de le dire. Ce qui est sûr c'est qu'il comporte quelques soucis. Bon et puis Chris Jones a dit lui même que ce code n'était pas exemplaire apparemment...

Billbis a écrit:

As-tu essayer de modifier la valeure de l'option du général setting "Characters turn before walking" ?

Cette option permet au personnage de se retourner de manière fluide, plutôt que de passer par exemple directement de la direction gauche à la direction droite, ce qui est un peu brutale. Là le problème c'est plutôt le choix de la vue utilisée dans certains déplacements. Quand mon personnage ce dirige à la fois vers la droite et vers le fond, quitte à glisser je préfèrerai que la vue de 3/4 soit appelée.

Billbis a écrit:

C'est la semaine du 15 août, beaucoup doivent être en vacances sans forcément avoir un accès internet ou voulant un peu se déconnecter, ça ne m’inquiète pas trop.

Je voulais plutôt dire "inquiétant" comme le silence d'un grand château vide après le départ des invités, plus que par rapport au forum lui même

valoulef a écrit:

EDIT : Ça a l'air de marcher !

Cool !

valoulef a écrit:

J'avais déjà fait la remarque que mon perso faisait parfois du surplace pendant un laps de temp

C'est sans doute dût au fait qu'AGS termine les boucles d'animations avant de revenir à la position statique du personnage, et ce y compris lors de l’arrêt au point intermédiaire causé par mon module. Mon module ne fait que doubler la prévalence du problème. Cette feature permet des transitions d'animations fluide, au lieu d'une rupture brutale, mais induit un léger effet de sur-place.
Tu peux minimiser ce problème en :
-diminuant le nombre de frame de tes animations de marche
-en séparant les boucles de marche en deux ou trois parties en cochant "Run the next loop after this to make a long animation". (pas sur que ça marche, mais ça vaut le coup d'essayer)
-en recodant le système d'animation de marche des personnage avec du script, faisable mais un peu long...

Peut-être bientôt du nouveau concernant le problème du pathfinder, suite à ce message sur le forum officiel, qui a l'air d'être passé moins inaperçu que le signalement de Billbis (même si la réponse de Khris ne semble pas prendre en considération l'idée que le pathfinder est directement responsable du comportement).

L'espoir renait ! D'ici la sortie de L'affaire Aspirox on a peut-être de bonnes chances que les choses évoluent...

Par contre j'aurais plutôt tendance à dire leS problèmeS de pathfinder

Tiens, j’étais passé à coté de ces messages. En effet, tout espoir n'est pas perdu, d'autant plus que l'irremplacable Crimson Wizard a suggéré qu'il allait se pencher sur le pathfinder un jour (pour optimiser ses performance, mais il fera peut-être du débogage en même temps).

TheBitPriest est en train de regarder plus en détail le code source du pathfinder. Il est d'accord avec mes conclusions : le problème viens du "old pathfinder" et pas de Djikstra, qui sait parfaitement résoudre ce genre de situations (mais qui n'est pas appelé dans les mouvements en ligne droites, pour des raisons de déplacements aux claviers d'après les commentaires du code).
Il fait judicieusement remarquer que le "old pathdinder" ne fonctionne pas si mal, mais qu'il a un problème avec les cul-de-sacs, et qu'il y en a un petit dans la WalkableArea de valoulef :

(l'image est de lui)

Lorsque ce petit cul-de-sac d'un pixel est comblé, le "old pathfinder" fonctionne correctement et conduit au bon chemin.

Sinon, j'ai remarqué qu'il existai déjà un module nommé "8-Direction Movement". Il faut que je regarde plus en détail ce qu'il fait, mais il a l'air vieux et plus adapté pour les mouvements au claviers. Je pense donc renommer ce module IsoWalk pour le poster sur le forum anglophone afin d'éviter toute confusion. Je rajouterai aussi une propriété IsoMoving qui fonctionnera comme le Moving mais qui fonctionnera avec ce module.

Billbis a écrit:

TheBitPriest est en train de regarder plus en détail le code source du pathfinder.

Cool, je m'disais bien que quelqu'un finirait par regarder ce bug de plus près sur le forum anglophone

Je rajouterai cette partie de l'explication que donne TheBitPriest : l'ancien pathfinder se déplace en "lignes droites". Lorsqu'il se trouve dans un cul-de-sac, sa réaction est de revenir sur ses pas.
Voici ce qui se passe dans notre cas (j'extrapole un peu, il est donc possible que certaines étapes fonctionnent différemment) :

1. Il y a un clic hors de la zone de déplacement, AGS trouve le point le plus proche dans la zone de déplacement : c'est le coin inférieur gauche.
   
2. Depuis la position initiale du personnage, l'ancien pathfinder calcule une ligne droite vers le point d'arrivée (le coin inférieur gauche).
   
3. L'ancien pathfinder déplace dans un premier temps le personnage selon cette ligne droite vers le point d'arrivée, mais rencontre alors un cul-de-sac (le pixel pointé dans la capture d'écran de TheBitPriest).
   
4. De là, le pathfinder fait "marche arrière" jusqu'à trouver un point depuis lequel il pourra se déplacer en ligne droite jusqu'au point d'arrivée, c'est-à-dire qu'il déplace le personnage vers la droite jusqu'à trouver un point à partir duquel on pourra arriver à destination en ligne droite.
   
5. Une fois ce point atteint (qui se situe vers la droite de la zone de déplacement), le personnage se déplace en ligne droite vers le point d'arrivée, en bas à gauche de la zone de déplacement.

Petit éclaircissement sur cette remarque de Billbis que je n'avais pas comprise à la première lecture :

Billbis a écrit:

Lorsque ce petit cul-de-sac d'un pixel est comblé, le "old pathfinder" fonctionne correctement et conduit au bon chemin.

Par "comblé" il faut comprendre qu'on modifie la zone de déplacement de façon à faire disparaître le cul-de-sac (c'est-à-dire qu'il ne faut pas comprendre "comblé" comme "exploré par le pathfinder", comme je l'avais fait à la première lecture).

Il faudra que je regarde à nouveau nos tests de variation de 3 pixels pour voir si tout s'explique bien.

Billbis a écrit:

Je rajouterai aussi une propriété IsoMoving qui fonctionnera comme le Moving mais qui fonctionnera avec ce module.

Il y aura une différence entre IsoMoving et Moving ? Cela a-t-il à voir avec le cycle de jeu durant lequel le personnage se trouve entre deux lignes droites (et où il ne bouge donc pas durant un très court instant).

Double post pour tenir la communauté francophone au jour : TheBitPriest a synthétisé le problème du pathfinding sur une page wiki.

Oui, j'avais vu ça.
Il faut vraiment que je trouve le temps et le courage de revenir sur ce module.
J'ai déjà mis en place le changement de nom (U8D_walk() devient IsoWalk() ).

Kitai a écrit:

Il y aura une différence entre IsoMoving et Moving ? Cela a-t-il à voir avec le cycle de jeu durant lequel le personnage se trouve entre deux lignes droites (et où il ne bouge donc pas durant un très court instant).

Oui tout à fait. Mais selon mes tests, tant que le Moving est dans un fichier script sous le module (ou dans un fichier de scipt de room), Moving restera vrai jusqu’à la fin du mouvement. Et comme on ne peut pas rajouter d'attribut sur des structures prédéfinit, il n'y aura finalement pas d'IsoMoving, mais ça ne posera pas trop de problème.
En revanche, j'ai remarqué que pour l'instant seul un seul personnage peu faire un IsoWalk non bloquant à la fois. Je vais essayer de corriger ça, mais ça risque de me prendre un peu de temps et une ou deux boite de doliprane.

J'ai enfin mis à jour ce module, avec de nombreux mois de retard.   
Vous pouvez la télécharger la nouvelle version ici (~5ko).

Au menu du jour :
-Changement de nom de U8D vers IsoWalk (pour éviter toute confusion avec ce module) (désolé pour la rétrocompatibilité Utilisez les fonctions Rechercher -> Remplacer de l'éditeur).
-Intégration du petit hack pour forcer AGS à utiliser Djikstra.
-Le module permet maintenant à plusieurs personnages de faire des IsoWalk simultanément de façon non bloquante (non testé, mais ça devrait marcher - c'est le cas de le dire ).

Comme d'habitude, premier post mis à jour.

Petite mise à jour 1.1, pour encapsuler quelques variables optionnelles. Parce que.

Utilisation :

Code:

// fonction principale
cEgo.IsoWalk(100, 100);
cEgo.IsoWalk(100, 100, eBlock, eAnywhere);

// pour désactiver le module ( IsoWalk se comportera comme un walk normal), utile pour faire une option.
IsoWalkModule.ModuleON = false;

// distance minium en pixel pour que le module soit actif (20 par défaut). En dessous, un walk normal est appelé.
IsoWalkModule.MinDistance = 100;

// change l'ordre de priorité des points de passages P1 et P2.
// vrai : la diagonal en premier (faux par défaut).
IsoWalkModule.UseAlternateHorizontalPath = true;
IsoWalkModule.UseAlternateVerticalPath = true;

Désolé pour la rétrocompatibilité.
Premier post mis à jour.
Bientôt disponible à l'internationale.

Sinon, Gurok viens de rejoindre theBitPriest dans la résolution du fameux bug découvert dans le pathfinder. Je le dit, je le répète, tout espoir n'est pas perdu. Bientôt la disparition des "+3" !

J'étais curieux de regarder un peu comment fonctionnait ce module, quelqu'un aurait une copie ? Le lien est mort.

Petit bug a noter, IsoWalk fait crasher si l'on change de Player avec la fonction Character.SetAsPlayer() alors qu'on est entrain de marcher, et que le nouveau player se trouve dans une Room différente. Ca peut paraître absurde de se déplacer et de changer de player actif, mais imaginez que vous codez un objet dans une room, une interaction avec cet objet détermine le changement de SetAsPlayer... Dans ce cas là, si votre personnage doit marcher jusqu'a cet objet pour le déclencher, c'est justement dans cette configuration que le bug se produit.


Tout simplement parceque le dans le code IsoWalk, lorsque la fonction est lancée, elle calcule la distance entre player.x et la destination et détermine des Waypoints, et donc si le player n'a pas terminé son trajet en mémoire, mais qu'on lui demande de changer de Character référent et de Room .... ALORS BADABOUM !

Logique non ?

Pensez-y.

Pardon (^__^)'

(en toute franchise, je ne pense pas corriger ce bug pour l'instant, donc si quelqu'un veut proposer sa version patché, qu'il le fasse maintenant et que ça reste à jamais).