Closed Slayer95 closed 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.
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.
Oh, you can fix that, too.
Maybe the request message JSON can have a field that goes nocancel:true
if you disallow cancelling.
Would be a good way to do it.
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.
I'd modify the request to prevent cancel; I like having request-relevant data in the request itself.
Fiine. I'll do this as soon as I get my hands on a computer with Node.
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 beWhich one?