Proposal About the FIGHT! Button in RBY, and its lack of cartridge accuracy

[Eledyr]

Hi everyone, I know I'll probably not gonna make friends with this one, but this thread is about a difference I've seen in cartridge vs. the simulator that I think has no reason to exist in the first place. I will be looking into shiloh's Tiering Policy Framework:

I.) We play, to the best of our simulator's capabilities, with the mechanics given to us on the cartridge.

• While we strive to maintain fidelity to in-game mechanics, rare exceptions are made when specific elements are proven to undermine competitive integrity.

The fundamental issue with the FIGHT Button currently, is the mere existence of a cancel option. Once you've clicked the FIGHT! Button (which is also just an option as it is currently implemented), you have no issue to cancel it, as long as your opponent have not decided of what they'll do next. This is simply not how the game works. In game, you only have the option to click the FIGHT! Button once you're in battle, and whether or not your opponent have acted, if you use it and happens to be locked into the move, you can't decide whether or not to change.

I'd say that fundamentally, changing this would follow the Tiering Policy straight to the point; however, this would have quite a big impact on how RBY is played. I'm not sure where to post this too (and it seems that it was mentioned in phoopes's post regarding cartridge accuracy vs. modding debate, but not fully implemented):

FIGHT! button:
Ugh, this is such a long post already and I was going to link to a post that explains this better than I could but it seems to have been deleted? Anyway, this is another thing that has buffed partial-trapping moves and I think that this should be implemented as to not have that be the case. Basically, when you click a partial-trapping move (say, Wrap), in-game you don't know when the move ends necessarily. You click the "FIGHT!" button and if the move is continuing, you're locked in. You only know that the move is over if it's already hit five times or if your four moves show up again. On Showdown, however, you always know whether or not you're locked in with the way partial-trapping moves are currently implemented. This means that it's easier for the player using the partial-trapping move to position via switching because they always know whether they're locked in or not.

I feel like I'm not explaining this very well, but just know that as it's currently implemented, players using partial-trapping moves have an advantage on Showdown as opposed to if they were using the move in-game. This is something that I feel like has been approved to be implemented already, but idk if there's record of that anywhere on forums.

phoopes' suggestion: Implement the FIGHT! button. Please. I'm tired of hearing about how busted Wrap is every few weeks lol.

tl;dr: my proposal is to implement the FIGHT! button as it should be: No other possibilities if you want to use a move, and if you're still locked into the move, you can't change it afterwards.

Let me know your thoughts on this. I wish you all a nice weekend

 

[gastlies]

This is already implemented, right? Unless I'm missing something the cancel button doesn't work if you have clicked the fight button

On turn 2 my Victreebel is currently locked into Wrap, I click the Fight button then try to cancel it then switch to Dragonite, but I still end up using Wrap that turn.

 

[HiZo]

When designing this with shellnuts and zarel this was one of the things to make sure it was implemented. The same way there is an undo button is like how there's an undo button when you click a move while the opponent has imprison up (it will error out if you try and undo).

 

[Hydrametr0nice]

I'm pretty sure that even if you click cancel, you still can't switch afterward. And even if you cancel and click on another move, if it's still locked, the locked move will still be executed. Yeah, the client (the interface) gives you a false sense of freedom, but I'm almost certain that the server (the underlying logic) is correctly implemented.