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

Ça m'a l'air assez compliqué tout ça. J'espère que tu ne vas pas exploser ton budget Doliprane à cause de moi


Pour info, j'ai une room scrollable et je n'ai pas remarqué de bug. Cela dit la room ne scroll que sur la largeur, et ce n'est pas vraiment une room "à problème" car contrairement à certaines, elle est bien de profil et donc avec peu de profondeur et une walkable area plus ou moins en ligne droite. D'ailleurs je trouve ça très bizarre que GetWalkableAreaAt prenne en compte les coordonnées de le l'écran et non de la room, mais j'imagine qu'il y a une explication... 

Tu utilise le debug mode pour t'aider ? Ca doit pouvoir être utile pour repérer d'où ça vient...

J'ai déclenché le mouvement en script pur (pas à la souris), et le bug apparait quand même. J'ai essayé plein de truc, et je ne comprends toujours pas ni d'où il viens, ni comment le déclencher exactement.
Je vais essayé de monitorer mes variables pour voir si je comprend mieux, mais je m'y perd un peu dans mes overlays... Soient ils doivent être bloquant, soit le texte se réécrit par dessus et devient invisible. Quelle est la meilleur façon d'afficher en continue la valeur d'une variable à l'écran ?
Sinon, je me suis dit que ça venais peut-être d'une fonction toujours en ancien système de coordonnés, mais je n'ai rien trouvé de ce coté là.
J'ai aussi essayé avec la 1ere béta d'AGS 3.3.0, et le bug y est aussi.

Billbis a écrit:

Je vais essayé de monitorer mes variables pour voir si je comprend mieux

As-tu vérifié le placement des points intermédiaires (en y plaçant un objet par exemple, ou en dessinant sur la surface d'arrière-plan) ? Ça peut être une bonne indication pour déterminer si le problème est au niveau de ces points intermédiaire ou ailleurs.

Billbis a écrit:

Quelle est la meilleur façon d'afficher en continue la valeur d'une variable à l'écran ?

Il y en a plusieurs, moi je ferais ça :

Code:

DrawingSurface *buffer;
function on_event(EventType evenement, int data) {
  if (evenement == eEventEnterRoomBeforeFadein) {
    DrawingSurface* tmp = Room.GetDrawingSurfaceForBackground();
    buffer = tmp.CreateCopy();
    tmp.Release();
  }
}

int variable;
function repeatedly_execute_always() {
  variable++;
  variable = variable % 1000;
  DrawingSurface* tmp = Room.GetDrawingSurfaceForBackground();
  tmp.DrawSurface(buffer);
  tmp.DrawString(10,10,Game.NormalFont,"%d",variable);
  tmp.Release();
}

Bon, j'ai fait quelques tests de mon côté et j'ai aussi eu quelques déplacements un peu étranges, toutefois je ne sais pas si j'ai observé les mêmes choses que vous. Je voudrais bien aussi la pièce en question pour tester si ça ne vous dérange pas.

Concernant le fait que le mouvement se passe superficiellement "en trois étapes", rien de très étonnant : la commande Walk d'AGS utilise son propre algorithme de pathfinding, qui calcule parfois lui-même des points intermédiaires. De fait, les chemins étranges que j'ai pour ma part observés sont des chemins où le personnage se déplace tout d'abord vers le point intermédiaire de façon plutôt directe, puis se déplace vers le point final en empruntant encore un nouveau point intermédiaire qui ne correspond à aucun point calculé par le module.

Mais encore une fois, je n'ai peut-être pas vraiment observé le problème que vous décriviez, mes zones de déplacement étant un peu difficiles à cerner.

Merci Kitai de te pencher dessus !
Pour ma part, j'ai un peu laissé tombé, mais promis je me re-penche dessus bientôt.
Pour des raisons de projet TOP SECRET, je laisse le soin à valoulef de te passer (où non) sa room.
Importé dans un projet en 1024 x 768, le bug en question est particulièrement visible entre les points (841, 389) et (67, 551). Tu peux par exemple utiliser ce code là :

Code:

function hHotspot2_Interagir()
{
  player.U8D_Walk(841, 389, eBlock, eWalkableAreas);
  player.Say("Debut du bug :");
  player.U8D_Walk(67, 551, eBlock, eWalkableAreas);
}

Billbis a écrit:

Code:

function hHotspot2_Interagir()
{
  player.U8D_Walk(841, 389, eBlock, eWalkableAreas);
  player.Say("Debut du bug :");
  player.U8D_Walk(67, 551, eBlock, eWalkableAreas);
}

Moi aussi des fois je me déplace dans mon appart et je dis "début du bug" avant de faire un déplacement surréaliste en glissant



Kitai je t'envoie un mail.

Ok alors valoulef m'a sympathiquement filé la pièce en question et j'ai pu reproduire le bug grâce à tes commandes Billbis.

Mauvaise nouvelle (ou bonne selon qu'on est Billbis ou non) : le problème vient d'AGS et non pas du module. J'ai reproduit exactement le même comportement dans un projet sans le module, avec plusieurs variantes (bloquant/non bloquant, successif/non successif) de ceci :

Code:

player.Walk(699, 551, eBlock, eWalkableAreas);
player.Walk(67, 551, eBlock, eWalkableAreas);

Le résultat est toujours le même (tant qu'on stipule eWalkableAreas) :  un déplacement extrême sur la droite avant de continuer. Je pense donc que le problème vient du pathfinder d'AGS (j'avais tout anticipé en fait quand j'étais parti sur ma piste de recoder un pathfinder, oui oui oui je suis un génie extralucide).
Si on fait varier l'abscisse (67) tout en restant hors d'une zone de déplacement, le bug se reproduit. Mais si on fait varier l'ordonnée (551) d'un pixel vers le bas ou de deux vers le haut (ce qui fait un écart de 3 pixels, ce qui correspond à la finesse d'analyse du pathfinder d'AGS), le bug disparait.

La solution que je te suggère donc pour le moment Billbis, c'est d'ajouter/enlever 3 pixels à l'ordonnée de la destination intermédiaire par rapport à la position finale (et de même sur l'abscisse pour les déplacements diagonaux-verticaux). Une analyse plus fine pourrait mener à simplement moduler (l'opérateur mathématique de modulation) les coordonnées de 3 pixels, mais il faudrait faire quelques tests supplémentaires.

Ah ok, bien joué AGS (en fait j'ai l'impression d'être le révélateur de tous les bugs ou défauts du logiciel ).

C'est réparable donc ? Parce que j'ai pas tout pigé mais si le module ajoute 3 pixels à l'ordonnée, ça n'enlève pas la possibilité de se retrouver à l'ordonée 551 ?

Et aussi, pourquoi il a fallu que je vienne mettre mon grain de sel pour que ce bug apparaisse (vu que visiblement ce bug n'était pas connu)?

Merci Kitai, tu déchires.
Bon, j'ai pas tout compris à ton post, mais je vais faire des tests de mon coté pour y voir plus claire. Avec toute ses infos, je devrai pouvoir me débrouiller.
J'ai pas trop le temps en ce moment mais je me pencherai dessus d'ici ce week-end pour d'une part proposer un correctif pour mon module, et d'autre part proposer un rapport de bug sur le forum anglophone (si tu veux t'en charger, tu peux, mais sinon je le ferai).
EDIT : Après une nuit de sommeil, je crois que j'ai saisi ton post (je suis un peu lent à la compréhension en ce moment, pour cause d'alerte rouge au pollen): le bug apparait lors des déplacements purement horizontaux ou purement verticaux, lorsqu'on tombe dans des coordonnées entre les points de résolutions du pathfinder ? Je vais faire mais tests pour vérifier tout ça.

valoulef a écrit:

en fait j'ai l'impression d'être le révélateur de tous les bugs ou défauts du logiciel

Mais les testeurs comme toi sont tout à fait essentiel pour le bon développement de notre logiciel préféré. Tu joue un rôle très important, et tu le remplit bien.

Juste un petit post pour dire que j'ai enfin mis en ligne la version corrigeant le bug découvert par Kitai concernant la détection des walkeables areas en room scrollable. Le 1er post est mis à jour en conséquence (béta v0.4).
Je n'ai pas encore appliqué le correctif proposé par Kitai concernant le "bug de valoulef", mais je m'y penche très vite.

Billbis a écrit:

Mais les testeurs comme toi sont tout à fait essentiel pour le bon développement de notre logiciel préféré. Tu joue un rôle très important, et tu le remplit bien.

Peut-être mais je fais même pas exprès moi

Super Billbis ! Prends ton temps, je vais repartir pour environ 2 semaines donc ça presse pas (enfin de toute façon ça ne presse pas d'ailleurs, c'était juste histoire de glisser que vous n'allez pas me voir pendant deux semaines ).

Une petite erreur dans ta dernière version :

Code:

//export U8D_moduleON, U8D_UseAlternateHorizontalPath, U8D_UseAlternateVerticalPath, U8D_MinDistance, U8D_MinDistance;

"//" est apparu entre-temps, ce qui annule l'exportation

J'ai eu un peu peur quand j'ai mis à jour ma version et que le jeu à crashé
D'ailleurs tu gardes tes précédentes version ? Ca pourrait être utile en cas de non-compatibilité imprévue...

Par ailleurs :

Billbis a écrit:

Ajout d'une distance minimum pour déclencher le module (par défaut, 20 pixel, customisable) (02/06/2013)

D'après ce que j'ai vu dans le script, c'est 50 pixels et non 20.

valoulef a écrit:

Par ailleurs :

Billbis a écrit:

Ajout d'une distance minimum pour déclencher le module (par défaut, 20 pixel, customisable) (02/06/2013)

D'après ce que j'ai vu dans le script, c'est 50 pixels et non 20.

Voilà comment on en arrive à un manuel incohérent

Merci valoulef pour ta vigilance.
J'ai décommenté les export (plutôt que de commenter les import), j'ai remis 20 pixels en distance minimale par défauts. J'ai aussi supprimé deux lignes commentés qui n'avaient rien à faire là (je m'en suis servit pour tenter d'identifier le bug caractérisé par Kitai). j'ai laissé le même numéro de version.
En parlant de ce bug, je ne me suis pas repenché dessus, j'ai plutôt essayé de déléguer le boulot aux codeurs de la communauté anglophone : bug signalé ici et là. Malheureusement, c'est deux tentatives n'ont rencontré qu'un succès modéré : il faut convenir que debuguer un pathfinder n'est pas très sexy, surtout quand le bug en question n'est ni critique, ni fréquent (tant qu'on utilise pas mon module).
Mais libre à vous de uper les topics en question pour leur redonner une visibilité.  

valoulef a écrit:

D'ailleurs tu gardes tes précédentes version ?

Oui, bien sûr. Elles sont même toujours disponibles au téléchargement, tant que je ne les vire pas de mon dossier publique dropbox :
https://dl.dropboxusercontent.com/u/78928210/U8Dbeta0.1.zip
https://dl.dropboxusercontent.com/u/78928210/U8Dbeta0.2.zip
https://dl.dropboxusercontent.com/u/78928210/U8Dbeta0.3.zip
https://dl.dropboxusercontent.com/u/78928210/U8Dbeta0.4.zip

Kitai a écrit:

Voilà comment on en arrive à un manuel incohérent

Et oui, écrire un manuel est une tâche bien délicate.

Billbis a écrit:

Malheureusement, c'est deux tentatives n'ont rencontré qu'un succès modéré : il faut convenir que debuguer un pathfinder n'est pas très sexy, surtout quand le bug en question n'est ni critique, ni fréquent (tant qu'on utilise pas mon module).

Hum voilà qui est fâcheux... A-t-on une chance d'arriver à le contourner ou le réduire, par exemple en se basant sur les suggestions de Kitai un peu plus haut (auxquelles je n'ai pas compris grand chose  ) ?

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...