Player hangs indefinitely when battle_format contains @@@ custom rules

[ChazWinterYT]

Checked with version 0.12.0

I may have spotted a bug in player.py:_create_battle:

When a Player is initialized with a battle_format containing custom rules via @@@ (for example, "gen6ou@@@Team Preview,Adjust Level = 50"), the player hangs forever and never completes a battle. The root cause appears to be that self._format stores the full string including @@@, but three methods compare it against values that only ever contain the base format:

_create_battle (player.py:185)
split_message[1] comes from the battle room tag (e.g. battle-gen6ou-1), which is always the base format. The equality check against self._format (which has @@@) fails, so the battle object is never created.

_update_challenges (player.py:451)
Showdown's updatechallenges JSON sends the base format in challengesFrom. The check format_ == self._format fails, so the challenged player never puts the challenger into _challenge_queue, and accept_challenges blocks forever.

_handle_challenge_request (player.py:436)
split_message[5] contains the base format, comparison against self._format fails.

To reproduce:

from poke_env.ps_client.account_configuration import AccountConfiguration
from poke_env.player.player import Player

# Any Player subclass initialized with an @@@-format hangs on battle_against()
player = MyPlayer(battle_format="gen6ou@@@Team Preview", ...)

Fix:
Instead of if split_message[1] == self._format:, use if split_message[1] == self._format.split("@@@")[0]:
(or some other way to strip the custom rules)

I worked around it by create a subclass of Player and overriding all three methods above.

[JiwaniZakir]

The root cause is that self._format stores the full @@@-annotated string, while Showdown's protocol always communicates using only the base format (in battle room tags, updatechallenges JSON, and challenge messages). This mismatch causes the equality checks in _create_battle (line 185), _update_challenges (line 451), and _handle_challenge_request (line 436) to silently fail, leaving coroutines blocked on queues that never receive input. Normalizing self._format at assignment time — e.g., storing battle_format.split("@@@")[0] as the base format while keeping the full string separately for battle creation — would fix all three sites consistently without needing per-callsite workarounds.

[cameronangliss]

@ChazWinterYT does this resolve this issue for you?