Voici aujourd'hui, après un travail extrêmement long de ma part, une traduction du pavé d'OmnipotentEntity qui, après quelques trucs basiques, nous explique aujourd'hui le fonctionnement de la barre de raccourcis et des slots L et R. Croyez-moi, vous allez en baver.
Salut, mesdames et messieurs, Aujourd'hui fut un jour très animé. Ce fut surtout bartwe et moi, nous défiant sur des corrections de bugs en stream. Et c'est gonflant. Voici une courte liste avant que je ne vous parle de trucs plus intéressants. J'ai menti quand j'ai dit qu'il n'y avait eu que des corrections de bugs. J'ai aussi ajouté un second inventaire, les matériaux se retrouvant automatiquement dedans. Il y a donc maintenant 92 slots plus les slots d'équipement. Honnêtement, j'avais complètement oublié que j'avais fait ça ce matin. Longue journée... C'est parti. Tout d'abord, bartwe a effectué quelques changements dans la gestion des erreurs sous Windows, essayant de rendre meilleur l'historique de la pile d'exécution qui se crée lorsque le jeu plante sous Windows. Ça nous aidera à débugger dans le futur, mais ça n'est pas vraiment une correction de bug. Il a ensuite corrigé un problème avec le nombre de dégâts affiché lors d'un coup. Après ça, il a changé un peu du code des risques dus à l'environnement pour permettre à une partie seulement des valeurs de dégâts de vie d'être utilisées. Ensuite, il a corrigé quelques oublis grâce à l'ajout de la fonctionnalité sus-mentionnée. J'ai eu droit à quelques fonctionnalités manquantes. Il a aussi corrigé quelques problèmes de placement des particules de dérapage des ennemis. Elles n'étaient pas générées avec la bonne courbure. Enfin, il a corrigé quelques erreurs typographiques et fait un peu de ménage dans le code. J'ai commencé la journée avec le truc du second inventaire. J'ai ensuite corrigé quelques bugs concernant la façon dont était géré le rayon de la hache laser. La courbure était mauvaise. Ensuite, j'ai corrigé un oubli dans l'interface graphique qui pouvait conduire les volets à être enregistrés dans le gestionnaire de volets sans avoir été officiellement enregistrés au départ, causant quelques soucis. J'ai ensuite corrigé un problème du système de craft, celui-ci ne prenant pas en compte le second inventaire. Après avoir corrigé ça, j'ai dû corriger un autre bug car les objets n'étaient pas retirés de l'inventaire après les avoir utilisés pour crafter. Derp ! Avez-vous déjà remarqué dans les streams que lorsque quelqu'un utilise la hache laser, la main du personnage se comporte bizarrement quand il tourne, une sorte d'à-coup en haut ou en bas avant de revenir doucement en bas ou en haut ? Corrigé. Il y avait aussi un problème en approchant le curseur trop près du joueur, la main devenait folle et s'agitait plus sauvagement qu'un chat jeté dans une baignoire. Ouais, corrigé aussi. J'ai aussi corrigé la gestion de quelques cas extrêmes, dont je parlerais plus en détail plus tard, et un autre problème d'interface utilisateur où les slots d'objets équipés ne chargeaient pas correctement lorsque on redémarrait le jeu à partir d'une sauvegarde. J'ai ensuite eu quelques bugs de George, qui m'avait dit que la fenêtre de navigation n'apparaissait et ne disparaissait pas correctement. Donc j'ai pris un peu de temps pour corriger ça. Le volet n'était pas marqué comme persistent et "mangeait" les touches frappées. Deux bugs corrigés, là. J'ai ensuite pris du temps pour ajouter une fonctionnalité qui me préoccupait : Shift+clic envoie maintenant les objets de l'inventaire à la barre de raccourcis et vice-versa. J'ai toujours besoin d'un bon raccourci pour ajouter l'objet dans la bonne main. Des idées ? Longue journée... pfiou. Donc... pour rendre les choses moins fades et listées, parlons de la gestion de l'inventaire et de la barre de raccourcis au sens large. Il y a eu récemment des modifications majeures pour les rendre bien plus réfléchis. Parce que c'est délicat et plein de cas extrêmes, c'est difficile de faire en sorte qu'il fasse "le bon truc". Donc ceci est ma barre de raccourcis. Il y en a bien d'autres comme celle-ci, mais c'est la mienne. Action Bar 1 Une chose que vous pouvez remarquer est que les slots L et R sont maintenant de vrais slots et non plus un reflet d'autres slots de la barre. Cependant, souvenez-vous, il y a aussi des objets à deux mains, comment fonctionnent-ils avec ce système ? C'est très simple : on désactive simplement le slot approprié et on le montre en le grisant. Action Bar 2 Cette solution semblait bien plus élégante que de forcer l'objet à sortir du slot et entrer dans un sac qui peut avoir ou ne pas avoir la place de le contenir. "Mais !" vous entends-je pleurer, "Cette méthode semble bien plus lourde ! Je perds la capacité de me déplacer rapidement entre les slots si j'ai besoin de déplacer un objet sur le slot L ou R !" "Pas si vite !" vous réponds-je, "Vous pouvez toujours vous déplacer rapidement entre les slots !" Action Bar 3 Et ça marche bien sûr avec les objets à deux mains. 8-16_update4 Parlons donc un peu de tout ce travail. La barre de raccourcis en elle-même est contrôlée par le fichier /source/frontend/StarActionBar.hpp qui, avec son fichier cpp associé, est géré par l'interface principale, /source/frontend/StarMainInterface.hpp. Cette interface principale contrôle à peu près l'intégralité de l'interface graphique. Un fichier également pertinent pour cette discussion est la classe d'inventaire du joueur, localisée dans /source/game/StarPlayerInventory.hpp, qui a requis beaucoup de modifications pour rendre tout cela possible. Passons des changements de niveau basique aux changements de haut niveau. Nous allons donc commencer avec l'inventaire du joueur. Cette classe a subi deux changements majeurs pour que ça fonctionne. Tout d'abord, et évidemment, il a fallu lui ajouter deux nouveaux slots. Ceux-ci existent en dehors du reste des slots de la barre de raccourcis pour plus de facilité d'implémentation. Ils sont tout simplement appelés "LeftHand" et "RightHand" (ndlr : "MainGauche" et "MainDroite", pour les non anglophones). Ensuite, il a fallu ajouter le concept de slot "Held" (ndlr : tenu, équipé). Auparavant, nous gardions la trace de l'objet sélectionné dans la barre de raccourcis , mais cela utilisait simplement un type size_t du sac, plutôt que la classe InventorySlot créée pour désigner un emplacement unique n'importe où dans l'inventaire. Bien que ce ne soit pas actuellement utilisé, ce changement permet à n'importe quel InventorySlot d'être marqué comme "Held" plutôt qu'un emplacement potentiellement invalide quelque part dans un sac spécifique. Donc ! Maintenant, nous avons quatre objets différents, pouvant être équipés de façons variées, avec trois états possibles pour deux de ces objets et quatre états possibles pour les deux autres. Les slots de "Main" gauche et droite peuvent être à deux mains, à une main, sélectionnés mais vides ou non sélectionnés. Ce qui me conduit à la question suivante. Comment faisons-nous pour savoir quel objet doit être dans la main gauche et quel objet doit être dans la main droite ? Hé bien, c'est en fait quelque chose de très compliqué, et il y a 144 possibilités de combinaisons différentes d'à deux mains, à une main, vide, non sélectionné etc. Donc la seule façon pour donner un peu de sens à ce désordre est d'énumérer tout ce qui doit arriver dans chaque cas. Faire cela aide également à repérer les bugs. Car le comportement attendu est parfaitement clair. Voici donc le remaniement actuel de la matrice de décision Alt Hand. // The following is a grid of the possibilities here // Source: // AE = Alt hEld Item, AH = Alt Hand Item // PE = Pri hEld Item, PH = Pri Hand Item // 2 = two handed item // 1 = one handed item // 0 = empty slot (selected) // N = not set (Held items only) // // Result: // X = invalid / don't care // P = primaryHeldSlot(); // p = leftHand(); // A = altHeldSlot(); // a = rightHand(); // 0 = none(); // /////////////////////////////////////////////////////////// // XX |AE | 2 | 2 | 2 | 1 | 1 | 1 | 0 | 0 | 0 | N | N | N | // XX |AH | 2 | 1 | 0 | 2 | 1 | 0 | 2 | 1 | 0 | 2 | 1 | 0 | // ---+---+---+---+---+---+---+---+---+---+---+---+---+---+ // PE | | | | | | | | | | | | | | // EH | | | | | | | | | | | | | | // ---+---+---+---+---+---+---+---+---+---+---+---+---+---+ // 22 | | X | X | X | X | X | X | X | X | X | P | P | P | // ---+---+---+---+---+---+---+---+---+---+---+---+---+---+ // 21 | | X | X | X | X | X | X | X | X | X | P | P | P | // ---+---+---+---+---+---+---+---+---+---+---+---+---+---+ // 20 | | X | X | X | X | X | X | X | X | X | P | P | P | // ---+---+---+---+---+---+---+---+---+---+---+---+---+---+ // 12 | | X | X | X | A | A | A | 0 | 0 | 0 | 0 | a | a | // ---+---+---+---+---+---+---+---+---+---+---+---+---+---+ // 11 | | X | X | X | A | A | A | 0 | 0 | 0 | 0 | a | a | // ---+---+---+---+---+---+---+---+---+---+---+---+---+---+ // 10 | | X | X | X | A | A | A | 0 | 0 | 0 | 0 | a | a | // ---+---+---+---+---+---+---+---+---+---+---+---+---+---+ // 02 | | X | X | X | A | A | A | 0 | 0 | 0 | a | a | a | // ---+---+---+---+---+---+---+---+---+---+---+---+---+---+ // 01 | | X | X | X | A | A | A | 0 | 0 | 0 | a | a | a | // ---+---+---+---+---+---+---+---+---+---+---+---+---+---+ // 00 | | X | X | X | A | A | A | 0 | 0 | 0 | a | a | a | // ---+---+---+---+---+---+---+---+---+---+---+---+---+---+ // N2 | | A | A | A | A | A | A | p | p | p | p | p | p | // ---+---+---+---+---+---+---+---+---+---+---+---+---+---+ // N1 | | A | A | A | A | A | A | 0 | 0 | 0 | 0 | a | a | // ---+---+---+---+---+---+---+---+---+---+---+---+---+---+ // N0 | | A | A | A | A | A | A | 0 | 0 | 0 | a | a | a | // ---+---+---+---+---+---+---+---+---+---+---+---+---+---+ La légende est incluse. J'espère que ça n'est pas trop difficile à comprendre. Grosso modo, il s'agit d'une table de recherche. Sur le côté, on trouve la main primaire, en haut, la main alternative. Ça se traduit en code de la façon suivante : auto priHand = underlyingPrimaryHandItem(); auto altHand = underlyingAltHandItem(); // If we have a two handed primary held item, return it // Covers 0,0 to 2,11 submatrix if (safeTwoHanded(primaryHeldItem())) return primaryHeldSlot(); // If we have a alt held item, it takes priority // Covers 0,0 to 11,5 submatrix if (altHeldItem()) return altHeldSlot(); // if we're flagged as holding an empty item in altHeld // and a two-handed item in our priHand, return priHand // Covers 9,6 to 9,8 submatrix if (validInventorySlot(altHeldSlot()) && !altHeldItem() && !validInventorySlot(primaryHeldSlot()) && safeTwoHanded(priHand)) return InventorySlot::leftHand(); // If we have a alt held slot selected, but not item... // Covers 3,6 to 11,8 submatrix if (validInventorySlot(altHeldSlot())) // implicit !altHeldItem() return InventorySlot::none(); // If we have a no selected primary held item and primaryHandItem is two handed, use that // Covers 9,9 to 9,11 submatrix if (!validInventorySlot(primaryHeldSlot()) && safeTwoHanded(priHand)) return InventorySlot::leftHand(); // If we have no item in primaryHeldSlot, but it's selected, and we're two handed, use rightHand // Covers 6,9 to 8,9 submatrix if (validInventorySlot(primaryHeldSlot()) && !primaryHandItem() && safeTwoHanded(altHand)) return InventorySlot::rightHand(); // If we have have a valid one handed primary hand item, and we're two handed, return none // Covers 3,9 to 5,9 submatrix if (validInventorySlot(primaryHeldSlot()) && safeOneHanded(primaryHeldItem()) && safeTwoHanded(altHand)) return InventorySlot::none(); // If we have a one handed primary hand item, and a two handed alt hand item, return none // Covers 10,9 cell if (safeTwoHanded(altHand) && safeOneHanded(priHand)) return InventorySlot::none(); // Covers remainder return InventorySlot::rightHand(); Quel cirque ! C'est un peu plus compliqué de juste "faire la bonne chose", en particulier quand la bonne chose n'est pas toujours claire dans les cas extrêmes. Par exemple, dans le cas où vous avez le slot d'équipement primaire sélectionné mais rien dedans, un objet à deux mains dans le slot alternatif. Il semble correct de désactiver les deux slots. Mais j'ai pensé que ce serait probablement une mauvaise idée et donc à la place, j'ai simplement donné au slot alternatif la priorité sur le slot primaire, même si ça semble violer les règles de priorité précédentes, parce que ça semble être la "bonne chose à faire". Ensuite, parlons de la zone de la barre de raccourcis. Maintenant que nous avons légitimité et support dans l'inventaire pour ce genre de chose, il y a quelques trucs en plus à ajouter à la barre de raccourcis. Tout d'abord, nous devons rendre les objets dans les slots L et R vraiment interactifs. Ils devraient faire des choses quand on clique. Dans le cas présent, il désélectionnent l'objet actuellement sélectionné ou le font tirer s'il est activé. Mais les autres objets de la barre ? Hé bien, c'est un peu plus compliqué. Il y a trois façons de sélectionner un objet comme équipé. Mais seulement une d'entre elle utilisé vraiment l'interface de la barre de raccourcis. Les autres utilisent l'interface principale, car il faut intercepter les frappes sur le clavier et les mouvements/clics de souris qui n'ont tout simplement rien à voir avec cette barre. Mais pour la méthode qui utilise vraiment le code dans StarActionBar.cpp, c'est un peu compliqué ! Il y a trois choses dont l'interface utilisateur doit garder la trace. Il y a trois couches :

Slot selectedslot-l selectedslot-r

Ceci compte pour une. Ensuite, nous avons la position de la molette sur les slots L et R. Ces valeurs sont stockées dans l'interface principale, car c'est ce qui les référence. Enfin, nous devons savoir quel slot d'inventaire est sélectionné. Cette valeur est aussi stockée dans l'interface principale. Ces trois valeurs sont similaires mais subtilement différentes, et suivent des règles légèrement différentes. On doit donc en garder la trace séparément. Donc à chaque fois que je demande une mise à jour de blah blah, il y a une logique derrière qui contrôle ces trois trucs mais seulement si c'est approprié pour la situation actuelle. Si vous êtes toujours en train de lire et que vous prêtez toujours attention à ce que je raconte, bravo. J'aime votre cran. Répondez au topic avec "AltHandSmock", si vous êtes le premier, je vous enverrez par message privé une clé pour un pack pixel (ndlr : déjà fait par quelqu'un, pas la peine de vous précipiter sur l'article officiel, cependant j'offre une clé Steam pour Bastion à la première personne à faire ça ici). Je n'ai pas encore trouvé de bon moyen de garder une trace de toutes ces dépendances. Mais la bonne nouvelle est que j'ai tout fait à peu près correctement du premier coup, donc tout va bien. Jusqu'à la maintenance, bien sûr. Ainsi, quand vous cliquez sur un slot, vous avez plusieurs options. Si vous faites shift+clic, ça essaiera d'envoyer l'objet dans un contenant ouvert, si un tel contenant existe dans le monde. Sinon, il essaie de l'envoyer dans votre inventaire. Si vous ne maintenez pas shift, ça vérifie que votre inventaire est ouvert. S'il l'est, ça met simplement l'objet de votre barre de raccourcis dans le slot d'échange, qui est un autre truc de l'inventaire dont je n'ai pas encore parlé, qui contribue à savoir quel objet est utilisé. À moins que vous ne fassiez un clic droit, auquel cas ça essaie d'appliquer l'objet déjà dans le slot d'échange à l'objet sur lequel vous venez de cliquer. C'est comme ça qu'on répare des objets comme les pioches. Si l'inventaire n'est pas ouvert, ça met l'objet dans votre slot d'équipement primaire. À moins que vous n'ayez fait un clic droit, auquel cas ça le met dans votre slot d'équipement alternatif. Ensuite, ça vérifie si votre objet est à deux mains. S'il l'est, ça fait la chose appropriée et met à jour les trois informations mentionnées précédemment S'il ne l'est pas, ça fait la chose appropriée pour cette situation. Quand vous faites tourner la molette vers le haut ou le bas ou que vous appuyez sur une touche de 1 à 9 (plus le 0) de votre clavier, l'interface principale s'en charge. Le code est similaire mais plus simple car il y a moins d'actions possibles. Il y a toujours besoin de mettre à jour les trois valeurs, en fonction de ce qui est approprié. Et je pense que c'est tout ce qu'il y a à dire, aussi loin que vont les détails d'implémentation gonflants. Ce problème particulier a fini par me prendre beaucoup plus de temps que je ne l'avais prévu, malheureusement. Si vous vous rappelez de mon stream de la nuit dernière, c'est probablement 90% de ce que vous avez vu. J'ai eu quelques faux départs, ce qui est la raison pour laquelle ça m'a pris autant de temps. Mais j'ai vraiment mis en forme le fonctionnement de PlayerInventory, et ça a fini par faire en sorte que tout marche finalement bien mieux. Ce qui est très sympa à la fin de la journée, parce que ça m'a causé un stress infini pendant que c'était en cours. Enfin bon, j'vais me taire. J'espère que vous appréciez votre pavé. Voici une image en récompense. Wario reward
Bon, ça y est, c'est enfin fini, j'espère que vous appréciez votre pavé traduit, bien complexe et gorgé de trucs techniques. On peut donc ainsi comprendre mieux le fonctionnement du jeu. Source : [16th August Progress]