Mudlet: Bug speedwalk chambres touchant

Créé le 2 avr. 2019  ·  10Commentaires  ·  Source: Mudlet/Mudlet

Bref résumé du problème / Description de la fonctionnalité demandée :

J'avais remarqué ce bug sur les cartes OPEN Area Continent à plusieurs reprises (où toutes les pièces se touchent), mais je n'avais pas compris la raison pour laquelle cela se produisait.

Je l'ai remarqué dans quelques zones que je cartographiais où j'ai décidé d'avoir des pièces se touchant, la taille 10 se touchant côte à côte.

J'ai remarqué que le cheminement s'arrête avant l'endroit où il doit réellement aller, cela suppose parce que les pièces touchent les frontières qu'il a terminé la marche rapide.

Étapes pour reproduire le problème / Raisons de l'ajout de la fonctionnalité :

Dans une zone, ayez simplement des pièces qui touchent les bordures, puis essayez de double-cliquer sur la pièce pour voir comment elle s'y dirige, puis faites qu'elles ne se touchent pas, et le cheminement fonctionne correctement.

Voici une image pour illustrer :

bug-pathing

bug medium

Commentaire le plus utile

Voir mon correctif pour cela - et moi aussi je viens de trouver le speedwalk jusqu'à la pièce dans l'autre fonction de zone - qui est en fait comme prévu (au moins lorsque le mode grille est désactivé! :stuck_out_tongue_winking_eye :)

Tous les 10 commentaires

Pour ajouter à cela, réduire la taille de la pièce lorsque les pièces sont si proches fonctionne, mais vous devez réduire la taille de la pièce à 7 avant que le bug ne disparaisse... c'est pour le moins intéressant. sans regarder le code, je ne peux pas imaginer pourquoi cela se produit. J'espère que ce n'est pas trop difficile à corriger, j'utilise la taille de la pièce 10 et j'adore l'apparence de la taille de la pièce 10, donc ce bug me rend triste :(

A priori, je dirais que le code qui détermine la pièce la plus proche de la position du clic de souris a probablement un léger décalage et cela dérange pour les pièces adjacentes. Il y a deux ou trois choses qui me viennent à l'esprit :

  • il pourrait y avoir des calculs en cours qui produisent un résultat fractionnaire (type double ) mais qui sont stockés ou comparés à des valeurs int et les choses ne sont pas qRound( ... ) ed avant d'être comparé.
  • quelque peu liés - les valeurs double ou float sont testées avec une comparaison == - ce qui n'est jamais une bonne idée !

:bulb: Jetez un œil, laissez-moi réfléchir, T2DMap::paintEvent(...) aux trois bits de code qui commencent par un ìf compliqué :

        if (((mPick || __Pick) && mPHighlight.x() >= roomRectangle.x() - (mRoomWidth * rSize) && mPHighlight.x() <= roomRectangle.x() + (mRoomWidth * rSize)
             && mPHighlight.y() >= roomRectangle.y() - (mRoomHeight * rSize)
             && mPHighlight.y() <= roomRectangle.y() + (mRoomHeight * rSize))
            || mMultiSelectionSet.contains(currentAreaRoom)) {

Le membre (QPoint) T2DMap::mPHighligtht est défini sur les coordonnées x/y où l'événement de double clic s'est produit lors d'un appel précédent à T2DMap::mouseDoubleClickEvent(...) donc je pense que vous voudrez vérifier les limites qui sont utilisées pour vérifier que une pièce est à portée du double clic.

Une chose que vous voudrez vérifier est si l'erreur est symétrique - c'est-à-dire qu'elle se produit également de chaque côté et également au-dessus et au-dessous - si c'est le cas, les limites peuvent simplement avoir besoin d'être réduites ; sinon, il y a un problème de codage. notez que certaines de ces valeurs impliquées dans le calcul sont, je pense , les types float ou double et non int , et que l'axe des y est inversé (IIRC) pour les 2 D mappeur...

Vous devez avoir raison. De plus, après un redémarrage de mudlet, je ne peux plus reproduire l'erreur et je suis exactement dans la même zone qu'avant. Auparavant, il le faisait à chaque fois et se reproduisait facilement et maintenant, je ne peux plus du tout le faire. Donc, c'est presque comme si quelque chose avait bogué puis réparé après un redémarrage de mudlet.

La prochaine fois que ce bogue se présentera, j'essaierai d'appeler gotoRoom() et de voir si cela est également affecté ou simplement le double-clic.

Mise à jour, je pense que vous avez réussi @SlySven Le bug a refait surface pour moi aujourd'hui lors de la cartographie. Je pouvais essayer d'accéder à la pièce à plusieurs reprises en double-cliquant et cela continuait de me déranger. Cependant, une fois que j'ai utilisé lua gotoRoom(23979) il s'est correctement dirigé vers la pièce.

Pour quatre (ou même huit si nous sommes préoccupés par les diagonales) pièces disposées autour de la cible, cette mauvaise sélection se produit-elle uniformément autour de la cible ?

En outre, il se peut que cela dépende de la séquence dans laquelle les pièces sont dessinées s'il y a un chevauchement dans la région pour chaque pièce potentielle (la première pièce dessinée qui est à portée déclenchera le processus de marche rapide) - et comme nous parcourons un QSet pour cela l'ordre est indéterminé...

{À des fins de débogage, il peut être utile d'utiliser l'option d'affichage de l'identifiant de la salle pour afficher à la place l'ordre de dessin de la salle - avec un compteur incrémenté après chaque itération et réinitialisé au début de chaque T2DMap::paintEvent() :nerd_face: }

cela ne se produit PAS uniformément autour de la cible, par exemple si je colle volontairement une poignée de pièces rapprochées, certaines d'entre elles sur lesquelles je peux double-cliquer et me déplacer, d'autres restent en place comme si j'étais déjà à ma destination :

disposition réelle :
2019-04-04_17-21_1

regroupé quelques pièces :
2019-04-04_17-21

avec la taille 10/10, il était très facile à reproduire immédiatement, il semble que vous soyez sur quelque chose avec eux qui se chevauchent différemment selon l'ordre dessiné, car avec eux groupés comme ça certaines pièces voisines marcheraient et d'autres pas, aussi je pouvais voir en double-cliquant sur la pièce qui a clignoté avec la cible rouge, et c'était incorrect, indiquant que le chevauchement l'affecte effectivement.

cela signifie-t-il que la surface cliquable des pièces s'étend au-delà de la zone des pièces ? Je ne comprends pas pourquoi cela se produirait... Je clique prudemment au milieu de la pièce lorsque cela se produit.

cela signifie-t-il que la surface cliquable des pièces s'étend au-delà de la zone des pièces ? Je ne comprends pas pourquoi cela se produirait... Je clique prudemment au milieu de la pièce lorsque cela se produit.

Ce serait ma supposition - je soupçonne fortement qu'il y a des défauts dans ces if tests auxquels j'ai fait référence précédemment - (et l'ordre de dessin le aggrave probablement aussi - ce qui ne serait pas un problème si les zones de sélection étaient avec précision évalué)... :inquiet:

J'ai découvert aujourd'hui en cartographiant que cliquer sur une pièce à la limite d'une zone peut parfois vous faire sortir de la zone, de sorte que le problème s'étend aux pièces d'une autre zone.

2019-04-06_01-23

Voir mon correctif pour cela - et moi aussi je viens de trouver le speedwalk jusqu'à la pièce dans l'autre fonction de zone - qui est en fait comme prévu (au moins lorsque le mode grille est désactivé! :stuck_out_tongue_winking_eye :)

Voir mon correctif pour cela - et moi aussi je viens de trouver le speedwalk jusqu'à la pièce dans l'autre fonction de zone - qui est en fait comme prévu (au moins lorsque le mode grille est désactivé! stick_out_tongue_winking_eye)

C'EST GÉNIAL! De plus, mon gridmode n'utilise pas réellement gridmode, hahahaha. Je suppose donc que je peux utiliser cette fonctionnalité géniale. dans mon mappeur, j'utilise un décalage de 2 en x,y pour la plupart des pièces et un décalage de 1 en continents (où je veux l'apparence de la grille, avec une taille de pièce de 10/10, cela a l'air vraiment bien et a un aspect agréable à pour les entrées de zone.)

Merci beaucoup d'avoir réparé ce SlySven !

2019-04-07_00-05

Cette page vous a été utile?
0 / 5 - 0 notes