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

valoulef a écrit:

On peut y faire appel depuis les scripts des rooms ou pas ?

Et bien, si tu les importes au préalable dans le GlobalScript.ash, oui !

Code:

//    You can import a few bool in your GlobalScript.ash to do some customizations.
//      import bool U8D_moduleON;
//      import bool U8D_UseAlternateHorizontalPath;
//      import bool U8D_UseAlternateVerticalPath;)
//    U8D_moduleON can be set to false to force U8D_walk to act as normal walk function.
//    (useful to set this module as optionnal).
//    U8D_UseAlternateHorizontalPath and U8D_UseAlternateVerticalPath will change waypoints priorities.
//    (see code comments for details).

D'ailleurs, merci pour avoir relevé la coquille, mport veux bien sur dire import.

Donc comme je te l'ai déjà dit ton module est vraiment super. Par contre, je viens de remarquer que pour les micro déplacements (10 ou 20 pixels) ça fait bizarre de voir le perso changer de direction à la vitesse de la lumière. Admettons qu'il soit à la coordonnée 0*0 et qu'on veuille le déplacer à la coordonée 10*5, il va d'abord se déplacer de 5 pixels, puis tourner pour se déplacer de 5 autres pixels. Et tout ça en un pas. Donc s'il y avait une longueur minimale pour que le U8D_walk fasse effet, ça serait pas mal. Je pense que ça doit pas être trop compliqué à prévoir (enfin je pense) sauf si tu prends en compte le scaling où là ça serait un peu plus chiant.

J'ai aussi remarqué que dans les bords extrêmes des Walkable Area ou quand il y a des trous dans celle ci, il arrive que le perso fasse du sur-place ou presque sur un ou de pas, mais pour le coup je ne sais pas si ça vient du module, car il ne change pas de direction.

Sinon le module est parfois un peu chaud à gérer pour les déplacements programmés dans certaines zones à problèmes (pour garder une certaine fluidité), mais ça vaut le coup !

valoulef a écrit:

Donc s'il y avait une longueur minimale pour que le U8D_walk fasse effet, ça serait pas mal.

Bonne idée, et facile à implémenter : ça sera dans la prochaine version.

Citation :

mais pour le coup je ne sais pas si ça vient du module,

A priori, non. C'est juste qu'AGS essaye de finir les animations de marche avant de passer à la suite...

J'ai remarqué un bug hyper bizarre et qui je pense ne peut venir que de l'U8D_Walk, dans la mesure ou le personnage fait une étape dans son déplacement.

Il se produit lorsqu'on se trouve au bord d'un angle d'une Walkable Area, et qu'on se déplace de l'autre côté. Pour être plus clair, voilà un schéma :

1 : Position de base
2 : Point intermédiaire de passage
3 : Destination

Le plus bizarre, c'est que ce point intermédiaire bizarrement placé ne correspond pas aux critères habituels, vu que le personnage glisse sur tout le trajet (au moins dans un cas où ça s'est produit).

A priori, ça reste quand même rare car les conditions pour que le bug se produise sont assez spécifiques...

Étrange... vu de loin, ça ressemble à une erreur de signe (variable Signe du module) pour un chemin secondaire... Le plus simple serai que tu m’envoies la room en question en MP ou par mail (clic droit sur la room en question dans l'éditeur, create template from room) que je puisse essayer de reproduire (et corriger) l'éventuel bug.
Juste pour en savoir plus : y a t'il un obstacle sur le trajet (objet ou personnage solide) ? Le personnage va-t-il au point 3 une fois arrivée en 2, sans que tu ais re-cliqué ? Le déplacement est il déclenché par un clique en mode WalkTo, par un script ou par un clic sur un hotspot ?

Billbis a écrit:

y a t'il un obstacle sur le trajet (objet ou personnage solide) ?

Non, en dehors de l'absence de walkable area.

Billbis a écrit:

Le personnage va-t-il au point 3 une fois arrivée en 2, sans que tu ais re-cliqué ?

Oui

Billbis a écrit:

Le déplacement est il déclenché par un clique en mode WalkTo, par un script ou par un clic sur un hotspot ?

Il est déclenché par un clic en mode WalkTo.



Ok je verrais à t'envoyer ça, mais comme je le dis c'est très spécifique donc pas idéal à reproduire. Cela dit il y a une situation où c'est assez simple, je te donnerai les coordonnées au pire.

valoulef a écrit:

Ok je verrais à t'envoyer ça.

J'attends toujours.
En fait, ça m'aiderai pas mal pour comprendre et corriger le bug (ça m’économisera surtout pas mal de cachets de paracétamol).

Sinon, au passage : *NOUVELLE VERSION*
Beta 0.3
Pas de grand changement, juste le rajout de la distance minimum pour déclencher le module (par défaut, 20 pixels, customisable via U8D_MinDistance (ligne 7 du .asc).
Pensez à dé-commenter les export et import pour y avoir accès depuis tout les scripts.
1er post mis à jour en conséquence.

Oui c'est vrai, je n'y suis que peu retourné depuis, j'essaye d'y penser demain.

Je mettrai aussi à jour ma version

Bon, après une petite heure d'investigation :
-J'ai reproduis le bug rencontré par valoulef dans sa room, et à plusieurs reprise, de plusieurs endroits différents.
-Je l'ai aussi redéclenché dans un autre projet, avec une autre room (mauvais signe, ça veux dire que c'est bien la faute de mon module, pas celle de valoulef).
-C'est beaucoup plus fréquent que ce que je pensai, beaucoup trop pour être laissé dans l'état.
-A priori, le bug ne se déclenche que lorsque (xWP1, yWP1) n'est pas dans une walkeable area.

Ce que je ne comprend pas, c'est que ça déclenche un mouvement en trois étapes (!), et que ce n'est à priori pas un bête problème de calcul.
J'ai pensé que c'était un problème d'accolades mal fermés, mais j'ai tout revérifier et mes accolades semblent ok.
Vu la position totalement farfelue du point de passage buggé, j'ai cherché des inversions (y,x) au lieu de (x,y), mais je n'en ai pas trouvé.
Je ne vois pas d'où ça peut venir.
Kitai, à l'aide !

Billbis a écrit:

Kitai, à l'aide !

Je suis flatté par tant de considération, mais je ne sais pas si je serai d'une grande aide.
Pour le coup j'ai jeté un coup d’œil plus attentif à ton code. Voilà ce que je peux dire :

1. Tout d'abord, truc tout bête, mais quand tu vérifies s'il y a une zone de déplacement possible à chacun des deux points intermédiaires en lignes 72 et 76, tu oublies de prendre en compte le décalage de l'écran (GetWalkableAreaAt prend les coordonnées de l'écran, pas de la pièce).
   Toutefois, à moins que le problème ne survienne que pour les pièces à défilement, je doute que ce comportement vienne de là.
   
2. Ma seule piste pour le moment est que la seconde commande Walk d'affilée (lignes 86 et 97), bien que ne prenant visiblement effet que lorsque le personnage a atteint le point de destination intermédiaire, est peut-être interprétée in situ : le calcul du chemin à parcourir pour le personnage serait donc effectué depuis sa position d'origine, et c'est ce chemin qui serait mis "à la file" après le chemin jusqu'au point intermédiaire. Dès lors, le comportement pourrait bien être assez chaotique.
   Malheureusement l'explication de l'exécution des fonctions bloquantes est un peu obscure, et ma traduction n'arrange clairement pas les choses.
   

Voilà tout ce à quoi je pense pour le moment...

Regarde alors si le problème persiste dans les mêmes conditions si tu passes en eNoBlock : puisque dans ce cas tu gères le point intermédiaire dans repeatedly_execute, si mon explication vise juste, le problème ne devrait pas se manifester.

Billbis a écrit:

-J'ai reproduis le bug rencontré par valoulef dans sa room,

[...]

Je ne vois pas d'où ça peut venir.
Kitai, à l'aide !

Valoulef, créateur de dépression nerveuse depuis près de 25 ans

Merci Kitai d'avoir jeté un coup d'oeil.

Kitai a écrit:

tu oublies de prendre en compte le décalage de l'écran (GetWalkableAreaAt prend les coordonnées de l'écran, pas de la pièce).

Bien vu ! Je vais corriger ça. En l’occurrence, les rooms où le bug en question apparait sont non scrollables. (attention, je ne dit pas que le bug n'apparait pas dans les rooms scrollablse, j'en sais rien).

Kitai a écrit:

Reguarde alors si le problème persiste dans les mêmes conditions si tu passes en eNoBlock

Bin, pour l'instant le bug n'est apparu que en eNoBlock, vu que déclenché par des clics de souris. Mais je vais essayer de le reproduire en mode eBlock, pour voir.

Billbis a écrit:

Bin, pour l'instant le bug n'est apparu que en eNoBlock, vu que déclenché par des clics de souris.

Ah oui, je suis bête, je croyais que c'était eBlock par défaut lors des clics. Ça m'aurait surpris que AGS déconne de façon native sur deux commandes Walk successives.

Bug reproduit en mode eBlock.

Mais sinon, j'ai corrigé le ViewPort dans GetWalkableAreaAt.

Vu que ça fait un mouvement en TROIS parties, j'ai l'impression que le ClaimEvent ne fonctionne pas sur le mode eWalkto. Ça expliquerai un autre bug que j'obtiens sur un de mes minijeux (où le personnage ce déplace malgré le ClaimEvent), je vais creuser.
Pour vérifier cette théorie, je vais déclencher le déplacement via un simple script, et non via un clic de la souris.

Billbis a écrit:

Pour vérifier cette théorie, je vais déclencher le déplacement via un simple script, et non via un clic de la souris.

Bonne méthode. À noter que ClaimEvent est censé n'empêcher que les événements correspondants contenus dans les scripts plus bas que le script en question. De plus, je crois que les événements correspondants dans les scripts des pièces sont exécutés avant ceux des modules.
C'est un peu compliqué tout ça, mais si tu n'as aucun on_mouse_click dans des scripts plus haut ou dans des scripts de pièce qui lancent la commande Walk, je vois mal d'où ça viendrait.

Sinon, tu peux vérifier les points intermédiaires qui sont calculés par ta routine : dessine un gros point rouge et un gros point vert sur la surface d'arrière-plan par exemple
Tu verras bien si tu as trois ou quatre points (auquel cas ta fonction est appelée plusieurs fois) et si ces points correspondent ou non au point vers lequel se déplace le personnage.

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