Empêcher la sélection d'une attaque

Principe

Une attaque peut ne pas être sélectionnable pour deux raisons distinctes :

• Depuis l'attaque elle-même : l'attaque vérifie ses propres conditions et décide qu'elle ne peut pas être choisie.
• Depuis un effet externe : un effet actif sur le Pokémon empêche la sélection de l'attaque.

Dans les deux cas, l'empêchement est signalé par le retour d'un Proc. Ce retour doit impérativement être accompagné d'un message indiquant clairement la raison au joueur.

Différence avec l'échec (guide 001) : l'empêchement de sélection intervient avant le tour, dans le menu de combat. L'échec intervient pendant le tour, à l'exécution de l'attaque.

Depuis l'attaque

Certaines attaques peuvent ne pas être sélectionnables selon leurs propres règles. Par exemple, l'attaque Garde-à-Joues ne peut pas être sélectionnée si l'utilisateur ne tient pas de Baie.

Pour gérer ce comportement, on override la méthode disable_reason dans la classe de l'attaque.

Exemple : Garde-à-Joues

# Get the reason why the move is disabled
# @param user [PFM::PokemonBattler] user of the move
# @return [#call] Block that should be called when the move is disabled
def disable_reason(user)
  reason_message = @scene.display_message_and_wait(parse_text_with_pokemon(60, 508, user))
  return proc { reason_message } unless user.hold_berry?(user.battle_item_db_symbol)

  return super
end

• L'appel à super est indispensable pour conserver les vérifications par défaut.
• Si la condition n'est pas remplie, un Proc contenant le message est retourné pour signaler que l'attaque est désactivée.
• Si la condition est remplie (l'utilisateur tient une Baie), super prend le relais.

Depuis un effet

Certaines attaques peuvent ne pas être sélectionnables à cause d'un effet actif sur l'utilisateur. Par exemple, l'effet Gravité empêche la sélection des attaques affectées par la gravité.

Pour gérer ce comportement, on utilise la méthode on_move_disabled_check dans la classe de l'effet.

Exemple : Gravité

# Function called when we try to check if the user cannot use a move
# @param user [PFM::PokemonBattler]
# @param move [Battle::Move]
# @return [Proc, nil]
def on_move_disabled_check(user, move)
  return unless move.gravity_affected?

  reason_message = move.scene.display_message_and_wait(parse_text_with_pokemon(19, 1092, user, PFM::Text::MOVE[1] => move.name))
  return proc { reason_message }
end

• La première ligne vérifie que l'attaque est bien concernée par la gravité.
• Si elle l'est, un Proc contenant le message est retourné.
• Si elle ne l'est pas, nil est retourné implicitement (pas de blocage).

Cas particulier : couplage avec la prévention

Lorsqu'on utilise disable_reason pour désactiver une attaque, il faut également implémenter move_usable_by_user (guide 001). En effet, une attaque désactivée peut quand même être lancée via des effets comme Métronome qui contournent la sélection.

De la même manière, pour les effets, on_move_disabled_check doit être couplé avec on_move_prevention_user pour couvrir le cas où l'attaque est lancée sans passer par le menu.

Conclusion

• Utilisez disable_reason et move_usable_by_user si la logique dépend de l'attaque elle-même.
• Utilisez on_move_disabled_check et on_move_prevention_user si la logique dépend d'un effet externe.
• Retournez un Proc pour signaler que l'attaque est non sélectionnable.
• Affichez toujours un message clair au joueur indiquant la raison.
• Pensez toujours à couvrir le cas où l'attaque est lancée sans passer par le menu de sélection.