Etendre les possibilités de déplacement d'objet

[TonyFlow]

J'ai effectué des modifications sur le client svn afin d'améliorer les possibilités de déplacement d'objets que l'on effectue par drag & drop ou double-clic (essentiellement au sein de l'inventaire ou avec le dépot). Disponible en activant FR_SWAPITEMS à la compilation (fichier make.default du svn mis à jour avec la balise activée).

Pour info, je détaille ici les différents cas possibles et le nouveau comportement du client. Rassurez-vous si le détail point par point semble un peu lourd, au final tout doit être relativement intuitif. Ce sont surtout des contraintes en moins lors des déplacements des objets à la souris


Déplacement d'un objet provenant du sac (inventaire non équipé)...

• sur un autre objet du sac :
  - s'il y a une case dispo dans le sac
  > échange des places effectué automatiquement
• sur un autre objet équipé :
  - si l'option de changement d'équipement est activée
  - s'il y a une case dispo dans le sac
  > l'objet équipé est placé dans le sac pour que l'autre soit mis à sa place
  (jusque là, comportement inchangé)
  + à condition que l'objet équipé ne soit pas empilable
  > alors l'objet déséquipé est remis à la place qu'occupait l'objet équipé
• sur lui-même (considéré comme un double-clic) :
  - aucun changement dans ce cas
  > l'objet sera équipé vers la première case d'équipement vide

Déplacement d'un objet de l'inventaire équipé...

• sur une case quelconque du sac :
  - aucun changement dans ce cas
  > l'objet sera déséquipé vers la case indiquée si elle est libre
  > ou sinon vers la première case vide du sac
• sur lui-même (considéré comme un double-clic) :
  - on tente de déséquiper l'objet
  > cf le cas précédent
• sur une autre case libre d'équipement :
  - s'il y a une case dispo dans le sac
  > l'objet équipé est déplacé dans le sac pour être rééquipé à la place voulue
• sur une autre case d'équipement occupée :
  - s'il y a deux cases dispo dans le sac
  > les deux objets équipés seront déplacés dans le sac
  > pour ensuite être remis chacun à la place de l'autre dans les équipements
• sur une case du dépot :
  - s'il y a une case dispo dans le sac
  > l'objet sera déséquipé puis rangé dans le dépot

Déplacement d'un objet du dépot...

• sur une case d'équipement dans l'inventaire :
  - s'il y a une case dispo dans le sac
  - s'il y a une case dispo dans les équipements
  > l'objet sera placé dans le sac puis équipé dans la case indiquée
  > ou si celle-ci est occupée dans la première case d'équipement libre
• sur lui-même (considéré comme un double-clic) :
  > l'objet sera ajouté dans le sac avec la quantité sélectionnée
  (équivalent à un laché dans l'inventaire, mais sans avoir à déplacer la souris)

Si besoin, on pourrait rendre activable certains de ces comportements dans les options, pour laisser le choix à l'utilisateur de les avoir ou non, comme c'est déjà le cas avec l'option "Permettre changement équipement". A la limite, plutot que de multiplier les options, autant réutiliser cette dernière pour éventuellement étendre son champs d'action à certaines de ces modifications.

Note : Quelques exceptions lorsque l'opération nécessite de déséquiper un objet empilable (cas actuellement rare, à ma connaissance seuls os et branche sont possibles). Il n'est alors pas possible de procéder aux échanges de places (car on ne peut savoir avec exactitude l'emplacement d'un objet empilable déséquipé, le serveur décidant lui-même où le mettre si un empilement est possible). Celà pourrait être envisager avec le support des item_uid.

[TonyFlow]

Un dernier ajout lié à ces fonctionnalités de déplacement : deux petits boutons ont fait leur apparition sur la fenêtre de l'inventaire, juste en dessous des cases d'équipements :

• ' < ' permet de retirer tous les équipements portés (sous réserve que l'inventaire dispose d'assez de cases libres bien entendu)
• '<<<' permet également de retirer tous les équipements portés, mais cette fois pour les ranger ensuite dans le dépôt (sous condition que le dépôt soit ouvert et accessible, une case libre dans l'inventaire reste nécessaire)

A noter également (je ne sais plus si je l'ai déjà signalé ici) que les boutons "tout déposer" et "tout au sol" ont davantage d'options. Il était déjà possible de choisir de garder la dernière ligne (option à cocher dans le menu contextuel du bouton). A présent vous pouvez décider de garder également la première ligne, la première colonne et/ou la dernière colonne pour chacun des boutons.

[Ackak]

La touche "<<<" ne fonctionne pas chez moi si je porte 2 objets. L'un est rangé, mais pas l'autre.

[Skwyrell]

' < ' fonctionne chez moi.
'<<<' aussi, y compris avec une seule case de libre dans l'inventaire (testé avec 4 ou 5 objets équipés plusieurs fois).

[Ackak]

Ca plante chez moi lorsque j'ai un os comme objet.

[tosh]

Code : Tout sélectionner

if(strcmp(nick, "Ackak") == 0)
  exit(EXIT_FAILURE);

Chez moi ça fonctionne très bien aussi

EDIT : en fait, lorsque l'on a déjà un objet du même type dans l'inventaire, ça ne le range pas au dépôt.

[Skwyrell]

Apparemment le coup de laisser l'objet déséquipé dans l'inventaire lorsqu'on en a plusieurs n'arrive qu'avec les objets empilables, je n'ai pas réussi à le reproduire ailleurs qu'avec les os.

Par contre, j'ai réussi à le faire buguer autrement :

exemple : Je prends plusieurs objets non empilables, par exemple, deux boucliers aciers, deux paires de bottes, deux pantalons
= il va quasiment à chaque fois enlever qu'une partie de l'équipement, mais aussi mettre au dépôt des objets de la partie inventaire.

Il va déséquiper le bouclier et les bottes mais pas le pantalon, et il va mettre au dépôt 2 boucliers au lieu d'un (celui resté dans l'inventaire en plus donc), les bottes déséquipées seulement, et aucun pantalon.

[TonyFlow]

Le cas des objets empilables est toujours particulier car le serveur pourra forcer la destination s'il trouve moyen de l'empiler. Du coup rien de fiable ne permet de déséquiper un objet empilable en sachant où il se trouve dans le sac pour en refaire autre chose (que ce soit mettre au depot ou rééquiper).

Dans ces condition, ce cas est généralement laissé de côté : l'action n'ira pas jusqu'au bout lorsqu'on suppose que l'objet a pu être empilé. Donc normal que parfois, un os ne soit pas traité, ou juste partiellement.

J'ai d'ailleurs laissé quelques commentaires dans le code avec marqué "TODO", histoire de noter l'abandon et penser un jour à tenter de traiter ce cas malgré tout. Ce n'est pas impossible non plus, mais j'attendrais pour celà le support des ITEM_UID par le serveur

En effet avec un id unique pour chaque objet, il sera possible de faire une recherche dans le sac, voir si notre objet empilable y occupe déjà une case, et ainsi savoir enfin avec quasi certitude où il se retrouvera. Actuellement, si c'est pour faire cette recherche en se contentant de la comparaison des images... je préfère m'en abstenir.

PS: L'ajout de l'item_uid serait vraiment un plus pour le client. Il y a déjà pas mal de fonctions qui se basent aujourd'hui sur la comparaison d'image_id pour distinguer/reconnaitre un objet, ce qui n'est vraiment pas tip-top.

[TonyFlow]

Je viens de regarder pour l'autre type de bug souligné par skwyrell, lorsqu'on veut mettre les équipements direct au depot mais qu'on en avait aussi des identiques dans le sac...

Pour comprendre pourquoi ça foire, c'est simple : mettre 3 objets identiques dans son sac, prendre le 3ème pour le ranger au dépot... au final le serveur a décidé de ranger le premier dispo dans le sac

Donc voilà, c'est la faute au serveur d'abord !!

Bon d'acc, normalement mon code devrait s'adapter pour faire avec ^^.
Ceci dit, avant d'essayer de contourner au mieux ce problème, je me demande s'il serait pas possible de changer ce comportement dans le code du serveur.

En effet je pense que c'est aussi un truc agaçant quand on prend l'objet en case 5 de son inventaire pour le mettre au dépot que le serveur décide pour nous de ranger plutot celui de la case 2 parce qu'il est en premier dans le sac.

[Teylae]

Arrêtez moi si je me trompe, mais ce qui se passe lorsque l'on dépose quelque chose en dépôt :
- envoi d'une trame au serveur : je veux déposer x objets de la case n°5 (par exemple) dans le dépôt
- le serveur vérifie que le dépôt a été ouvert
- le serveur vérifie que le dépôt est dans une zone proche
- le serveur vérifie que la case n°5 comporte un objet
- le serveur analyse le type de l'objet de la case n°5
- le serveur boucle à partir du début de l'inventaire, supprime x objets dont le type est identique à la case n°5 jusqu'à la fin de l'inventaire
- le serveur renvoi d'information au client concernant les cases qui ont été modifiées et le contenu du dépôt qui a été modifié

Le problème ne se pose évidemment pas pour des objets empilables. Mais pour ceux qui ne sont pas empilables, il n'y a pas d'autre solutions.
Lorsque vous voulez déposer qu'un seul et unique objet, cela parait stupide comme opération, mais lorsque l'on veux déposer x objets, le serveur n'a pas le choix que de boucler sur l'ensemble de l'inventaire (en commençant par le début, évidemment).

[TonyFlow]

Le problème ne se pose évidemment pas pour des objets empilables. Mais pour ceux qui ne sont pas empilables, il n'y a pas d'autre solutions.
Lorsque vous voulez déposer qu'un seul et unique objet, cela parait stupide comme opération, mais lorsque l'on veux déposer x objets, le serveur n'a pas le choix que de boucler sur l'ensemble de l'inventaire (en commençant par le début, évidemment).

Tu as très bien décris ce qu'il se passe, mais je ne suis pas d'accord sur ta conclusion :p

Le serveur pourrait mieux faire, même avec x objets non empilable :

- le serveur vérifie que la case n°5 comporte un objet
- le serveur analyse le type de l'objet de la case n°5
- le serveur boucle à partir de la case n°5 (et non du début) de l'inventaire, supprime x objets dont le type est identique à la case n°5 jusqu'à la fin de l'inventaire
- si la quantité indiquée n'a pas été atteinte, alors le serveur fait un second parcours, cette fois avec une boucle partant de la case n°5 jusqu'au début de l'inventaire.
- le serveur renvoi d'information au client concernant les cases qui ont été modifiées et le contenu du dépôt qui a été modifié

D'ailleurs, ce comportement plus intelligent du serveur, prenant en compte la position de l'objet indiqué, existe déjà ! On peut l'apprécier lorsqu'on lache des objets au sol


PS: à défaut que le serveur ne gère mieux le déplacement de l'inventaire vers le dépot, le bouton "<<<" qui permettait de ranger les équipements portés dans le dépot est supprimé du client, ne pouvant fonctionnait correctement dans les conditions actuelles.

[Teylae]

D'ailleurs, ce comportement plus intelligent du serveur, prenant en compte la position de l'objet indiqué, existe déjà ! On peut l'apprécier lorsqu'on lache des objets au sol

En effet, bien vu...
Et dans le cas de x objets, il ne repart même pas au début de l'inventaire, il part de la fin.

[Ackak]

Modifications intégrées à la version 1.6.0.2 du client.