Closed dbaelde closed 9 years ago
Je suis tout à fait d'accord. C'est plutôt rageant.
Pour la portée d'attaque, je pense, que comme c'est demandé en #150, on va faire un bouton pour afficher rapidement cette donnée.
Le fonctionnement des attaques est amené à changer, puisqu'il a été décidé que seules les unités au corps-à-corps pourraient se déplacer et attaquer sur le même tour (pour les autres, il faudra faire un choix). Je pense qu'il serait intéressant dans ce cas de créer un menu sans le bouton 'Attack' si celle-ci n'est pas possible. A discuter...
En fait, on va avoir besoin de menus qui ne sont pas statiques… Pour les bâtiments de production, on voudrait griser les unités qui sont hors budget par exemple.
Pas besoin de trop se fouler, plutôt que de juste rendre le menu actif/inactif et modifier sa position, il suffit de le créer on-the-fly à la bonne position et avec les bons boutons. On peut facilement encapsuler ça dans une fonction, et le surcoût est négligeable (on n'ouvre pas un menu à chaque frame).
Oui, c'est précisément ce que je voulais dire. ;) Mais tu parlais de créer deux menus pour gérer deux cas différents non ? C'est pour ça que je disais ça.
Comment fait-on donc ?
On pourrait transformer l'attribut enabled
en glaçon de type booléen peut-être ?
J'avais pensé à une méthode set_enabled
, mais le code que ça donne dans Game.ml
est un peu dégeu donc j'ai stash.
Bon j'ai quasi fini le projet réseau, je peux repasser sur le GL :)
Pourquoi ne pas simplement créer une fonction create_battle_menu : string list -> (int * int) -> widget
qui prend en paramètre la liste des items, la position, et crée le menu correspondant ? Si on n'a pas d'unités à portée, on l'appelle avec ["move", "cancel"]
, si on en a on l'appelle avec ["move", "attack", "cancel"]
.
De même, pour les bâtiments, tu appelles une fonction similaire avec la liste des unités constructibles (ie. celles pour lesquelles tu as les crédits). Tu peux éventuellement ajouter une liste correspondant à des boutons grisés.
C'est sympa, mais avec ton système de UI_manager, c'est pas possible… (ce n'est pas une critique). Ou alors un truc m'échappe.
Il faudrait rajouter des méthodes pour lui enlever un menu à chaque fois non ?
Ah oui tiens j'ai pas mis de fonction remove_widget... Bon c'est pas bien dur à rajouter, et normalement ça marche.
Mais après il faut quand même un accès à ce menu en dehors de la fonction create_ui
.
Ouep, mais de toute façon ce menu n'est pas créé dans create_ui, il est créé par ta fonction create_battle_menu
qui te renvoie ton menu comme objet de type widget
.
Les string
sont donc des identifiants ?
On l'ajoute au ui_manager puis on le supprime à chaque fois ?
Les feature requests ne sont peut être pas la priorité mais au cas où: Quand je fais attack et qu'il n'y a personne à portée d'attaque, cela effectue un déplacement et termine le tour de l'unité. C'est énervant quand on ne sait pas quelle est la portée de l'unité et qu'on fait attack pour tester. Je dirais que dans ce cas cela devrait échouer, et laisser le jouer faire un move à la place si c'est son intention. Ou alors j'ai mal compris le mode d'emploi?
PS: y a-t-il un moyen de voir la portée d'attaque sans tester ainsi?