smogon / pokemon-showdown-client

The client for Pokémon Showdown
http://pokemonshowdown.com
GNU Affero General Public License v3.0
544 stars 759 forks source link

Cancel doesn't work if the only battle request is the own #316

Closed Slayer95 closed 9 years ago

Slayer95 commented 9 years ago

There are some cases when it's evident that the battle has only a single request pending. Under such circumstances, the battle will proceed as soon as the player makes their choice, and any subsequent /undo messages will be invalid. As the option to cancel doesn't really exist then, it follows that (at least) for those circumstances, the cancel button should either be

Which one?

Zarel commented 9 years ago

Mainly we want to send the "cancelable period is over" message as soon as possible. Immediately sending | to both players once both decisions are in, without waiting for sim processes to respond, is probably the best solution.

Slayer95 commented 9 years ago

That's probably a good approach for the cases when you could cancel if you clicked fast enough.

What this issue is about is for cases when you could never actually cance, i.e. there was no cancelable period at all. For example: if you are prompted to switch on U-Turn usage, or if your Pokémon faints and no other player has to switch another Pokémon in, the client will display the Cancel button for the brief (or long) period before the server responds, which ideally shouldn't happen at all.

Zarel commented 9 years ago

Oh, you can fix that, too.

ascriptmaster commented 9 years ago

Maybe the request message JSON can have a field that goes nocancel:true if you disallow cancelling.

Zarel commented 9 years ago

Would be a good way to do it.

Slayer95 commented 9 years ago

I'm considering a fully client-side solution for this. Given that https://github.com/Zarel/Pokemon-Showdown/issues/1452 turns out well(*), the client will always be able to know if the opponent has Pokémon available to replace any fainted slots. If the current request type is switch, the switching out Pokémon are fainted (i.e. no Volt Switch), and either the opponent active Pokémon are all alive or no inactive foe Pokémon is alive, then we shouldn't display the Cancel button.

Modifying the request to prevent cancel has its merits, nevertheless, as removing the Cancel feature from any metagame objecting its existence (think of VGC) would be straightforward. However, for such cases I'd support making |rule| operational.

(*) We need it because otherwise we can't know the length of the foe party in metagames without Team Preview.

Zarel commented 9 years ago

I'd modify the request to prevent cancel; I like having request-relevant data in the request itself.

Slayer95 commented 9 years ago

Fiine. I'll do this as soon as I get my hands on a computer with Node.