Placer chaque membre sur sa propre case quand le leader n’est pas le protagoniste #88

Open
opened 2026-06-22 14:02:56 +00:00 by Reliodas · 1 comment
Owner

Régression confirmée après les tickets #71 et #76. Quand Bran devient leader avant une rencontre, World démarre encore EncounterFlow avec GameState.ensure_hero() sur player.grid_pos. Le jeton Player représente pourtant Bran. Le protagoniste est donc placé sur la case du leader, puis le placement de Bran échoue car cette case est occupée. Bran reste hors de TacticalGrid à la position (-1, -1). Réproduction minimale : recruter Bran, placer le protagoniste en (5,5) et Bran en (5,6), choisir Bran comme leader, puis déclencher le gobelin. Résultat attendu : protagoniste en (5,5), Bran en (5,6). Résultat observé : protagoniste en (5,6), Bran en (-1,-1). Périmètre : découpler le combattant principal de la position du jeton Player, assembler les positions depuis Party et les jetons de chaque membre, vérifier le résultat de chaque placement et refuser proprement une rencontre incohérente. Critères d’acceptation : chaque membre présent commence sur sa case d’exploration ; aucun chevauchement ni combattant absent de la grille ; leader protagoniste et non protagoniste fonctionnent ; fuite, victoire et reprise conservent les bonnes positions. Tests : compléter test_world_combat_active_actor avec des assertions sur grid.position_of pour les deux membres après changement de leader, puis couvrir le retour à l’exploration.

Régression confirmée après les tickets #71 et #76. Quand Bran devient leader avant une rencontre, World démarre encore EncounterFlow avec GameState.ensure_hero() sur player.grid_pos. Le jeton Player représente pourtant Bran. Le protagoniste est donc placé sur la case du leader, puis le placement de Bran échoue car cette case est occupée. Bran reste hors de TacticalGrid à la position (-1, -1). Réproduction minimale : recruter Bran, placer le protagoniste en (5,5) et Bran en (5,6), choisir Bran comme leader, puis déclencher le gobelin. Résultat attendu : protagoniste en (5,5), Bran en (5,6). Résultat observé : protagoniste en (5,6), Bran en (-1,-1). Périmètre : découpler le combattant principal de la position du jeton Player, assembler les positions depuis Party et les jetons de chaque membre, vérifier le résultat de chaque placement et refuser proprement une rencontre incohérente. Critères d’acceptation : chaque membre présent commence sur sa case d’exploration ; aucun chevauchement ni combattant absent de la grille ; leader protagoniste et non protagoniste fonctionnent ; fuite, victoire et reprise conservent les bonnes positions. Tests : compléter test_world_combat_active_actor avec des assertions sur grid.position_of pour les deux membres après changement de leader, puis couvrir le retour à l’exploration.
Reliodas added this to the 0.16.0 milestone 2026-06-22 14:02:56 +00:00
Author
Owner

Audit du 2026-07-02 — mécanique confirmée dans le code : start_encounter (scenes/exploration/world.gd:533) passe player.grid_pos (la case du jeton = celle du leader) comme case du héros à EncounterFlow.begin_encounter, et les échecs de grid.place ne sont pas vérifiés (encounter_flow.gd:79-90), d'où Bran en (-1,-1). Point supplémentaire relevé pour le même périmètre : _sync_surviving_allies (world.gd:450) exclut le protagoniste — quand il n'est pas leader, sa position de fin de combat n'est jamais reportée dans member_pos_by_map et le grid_pos de son jeton suiveur reste périmé (la boucle _process ne met à jour que position, pas grid_pos). À couvrir par le critère « fuite, victoire et reprise conservent les bonnes positions ».

Audit du 2026-07-02 — mécanique confirmée dans le code : start_encounter (scenes/exploration/world.gd:533) passe player.grid_pos (la case du jeton = celle du leader) comme case du héros à EncounterFlow.begin_encounter, et les échecs de grid.place ne sont pas vérifiés (encounter_flow.gd:79-90), d'où Bran en (-1,-1). Point supplémentaire relevé pour le même périmètre : _sync_surviving_allies (world.gd:450) exclut le protagoniste — quand il n'est pas leader, sa position de fin de combat n'est jamais reportée dans member_pos_by_map et le grid_pos de son jeton suiveur reste périmé (la boucle _process ne met à jour que position, pas grid_pos). À couvrir par le critère « fuite, victoire et reprise conservent les bonnes positions ».
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: jeux/beaulieu-sur-brume#88
No description provided.