Moonwalking

[panchino]

Cette nuit sans le vouloir, j'ai tenté un revival, et ce fut un succès

Voici les évènements du perso 159194 :

14/09/2010 04:05:51 Déplacement de -7,1,-6 vers -8,0,-6
14/09/2010 04:05:37 Déplacement de -6,0,-6 vers -7,1,-6
14/09/2010 04:01:38 Déplacement de -5,-1,-6 vers -6,0,-6
14/09/2010 04:01:55 Déplacement de -5,-1,-6 vers -6,0,-6
14/09/2010 04:02:16 Déplacement de -5,-1,-6 vers -6,0,-6
14/09/2010 04:01:28 Déplacement de -5,-1,-6 vers -6,-1,-6
14/09/2010 04:01:22 Déplacement de -4,-2,-6 vers -5,-1,-6

Si on les prend dans le bon sens, ces évènements montrent le perso partir 4 fois de la position -5;-1;-6 et arriver 4 fois à une autre contigüe.

On peut remarquer aussi qu'un déplacement n'est chronologiquement pas à sa place.

Ce qui est étrange, c'est qu'il avait 20 PA sous Bip² à disposition et qu'il n'a effectué au total que 7 déplacements au lieu de 10.



La situation :
Pour quelle raison un MK delanien se fend d'agir à 4h du mat en pleine semaine ? Pour cumuler sur un déplacement tendu ^^

Pendant la première dlt, il y a eu un blocage sur le chargement de la page de résultat.
J'ai donc stoppé, agacé je dois le dire, cette page d'une manière ou d'un autre, plusieurs fois de suite, comme par exemple par un retour arrière sur le browser, et par l'activation d'autres personnages via le menu Gestion de compte.
Puis soudain, les déplacements ont repris leur cours normal, il ne me restait que 4PA mais la seconde dlt engagée.

Il semble donc que 3 de ces déplacements aient coûté 4PA chacun au lieu de 2.




Double problème donc :
Un trépignement.
Une dépense de PA inadéquat.


Voyez-vous une raison à ce dysfonctionnement ?

[Wiiip]

Un gros cafouillage dus au parallélisme d'évènements contradictoires simultanés sur le même personnage. Certains ont du s'arrêter en route, consommant les pa et plantant avant d'inscrire les évènements (et de toute façon, l'effet a été réécrit par un autre évènement).

En bref, il faudrait que chaque évènement bloque l'arrivée d'autres actions, mais en cas d'erreur, tu ne pourrais plus rien faire, en plus de la consommation supplémentaire de ressource (et l'augmentation de la complexité).
Donc, quand ca rame, il vaut mieux le laisser ramer. (même à 4h du matin :s)

Désolée pour toi :s
J'espère que tu as pu échapper à ton danger.

Nota : il y a aussi le risque qu'un monstre t'aie attaquée entre les deux déplacements (ca m'est déjà arrivé), et qu'un certain nombre de déplacements se retrouvent être des fuites (manquées ou non).
Je ne me souviens plus si les fuites manquées sont inscrites dans les évènements.

[Labrute]

Un gros cafouillage dus au parallélisme d'évènements contradictoires simultanés sur le même personnage.

A tes souhaits.

Je ne me souviens plus si les fuites manquées sont inscrites dans les évènements.

Ben si, "a tenté de fuir le combat avec..."
Dis donc morpion abjecte ça fait longtemps que t'as pas loupé une fuite toi ^^

[Wiiip]

Dis donc morpion abjecte ça fait longtemps que t'as pas loupé une fuite toi ^^

[Nastywoks]

J'ai déjà pu remarquer (malheureusement), que dans certaines conditions (par exemple, jouer à Delain au travers d'un proxy), utiliser le retour arrière du browser suite à un déplacement entraine un autre déplacement involontaire.

Dans mon cas, c'était un aller retour sur ma position -_-'

[Reivax]

Si je ne m'abuse, 4h du mat', ce n'est pas l'heure quotidienne de maintenance des serveurs ?

[panchino]

entraine un autre déplacement involontaire.

Ah oui ça pourrait se tenir : Trois fois un retour, non marqué dans les évènements, sur la case de départ, et qui auraient coûté 2PA chacun.

il vaut mieux le laisser ramer.

Oui sans doute C'est le plus dur à 4h

[Difool]

Et si on l'aide à ramer ca avancera plus vite non ?

[Edalb]

Je pense à la même chose que Reivax, les archéologues du forum pourront trouver des posts à ce sujet il me semble.

En tout cas, quand l'application rame, mieux vaut faire preuve de patience que de cliquer partout comme un sauvage

edit pour l'explication des bizarreries : pour une action lancée comme un déplacement, il y a plusieurs requêtes qui vont modifier la base qui se font séquentiellement, et le plantage ou l'arrêt de l'une ne vient pas annuler les précédentes. Si on commence par enlever les pa, puis par écrire l'évenement et enfin par procéder au déplacement en lui même et qu'on stoppe le process en cours de route, on peut constater ce genre de chose.

[kroum]

En tout cas, quand l'application rame, mieux vaut faire preuve de patience que de cliquer partout comme un sauvage

Sauf que si tu as un cumul sur le feu, ca brûle.

pour une action lancée comme un déplacement, il y a plusieurs requêtes qui vont modifier la base qui se font séquentiellement, et le plantage ou l'arrêt de l'une ne vient pas annuler les précédentes.

Il y a pourtant moyen de faire cela. Un bon "BEGIN" en première requête, un "COMMIT" à la fin, et le tour est joué. Vu le niveau des développeurs de delain, je pense qu'ils l'utilisent. Ils ont dû oublier de le mettre sur les déplacements.

K.

[Edalb]

J'ai pas dit qu'il n'y avait pas de moyen pour y remédier, j'ai juste exposé comment ça marchait. Après on peut effectivement s'amuser avec les transactions, mais pas sûr que le jeu en vaille la chandelle.

[Merrick]

Il y a déjà des transactions (les fonctions sont déjà transactionnelles par défaut)

[Edalb]

Dans ce cas, j'ai dit que des conneries sur ce post
Du coup, vu que toutes les requêtes liées à un déplacement sont dans une seule fonction, je n'ai pas d'idée sur le pourquoi du comment du cas exposé.

[Merrick]

En cas de ralentissement, les requêtes sont stockées, et exécutées dès que possible, ce qui peut en cas de surcharge de la base, avoir des effets assez aléatoires. C'est un comportement assez rare, malheureusement impossible à éviter. IL faut simplement éviter de cliquer comme un fou quand la base ne répond pas...