FIGHT Button Implementation Side Effects (Desync/Infinite Sleep)

[gastlies]

I am curious how this would work in practice:

Would this mean Counter could potentially work more frequently - where it would currently be canceled due to Desync Clause? The only way for it to fail is if the target picked a non-Normal/Fighting-type move?

Two examples:
1. Paralyzed Snorlax clicks Body Slam on Chansey, next turn Snorlax clicks Earthquake and FPs on Counter.
2. Paralyzed Snorlax clicks Earthquake on Chansey, next turn Snorlax clicks Body Slam and FPs on Counter.

Both of these cause desyncs on cart. In example 1 Counter works on Chansey’s side but fails on Snorlax’s side. In example 2 Counter works on Snorlax’s side but fails on Chansey’s side.

Current implementation means desyncs result in move failure no matter what so counter fails in both examples here. The new proposal is to just take what’s on the target’s side so Counter would work in example 2, but not example 1.

 

[bingingem]

Two examples:
1. Paralyzed Snorlax clicks Body Slam on Chansey, next turn Snorlax clicks Earthquake and FPs on Counter.
2. Paralyzed Snorlax clicks Earthquake on Chansey, next turn Snorlax clicks Body Slam and FPs on Counter.

Both of these cause desyncs on cart. In example 1 Counter works on Chansey’s side but fails on Snorlax’s side. In example 2 Counter works on Snorlax’s side but fails on Chansey’s side.

Current implementation means desyncs result in move failure no matter what so counter fails in both examples here. The new proposal is to just take what’s on the target’s side so Counter would work in example 2, but not example 1.

Thanks for clarifying! That's what I figured. I think those changes are worth the update to Desync Clause imo.

 

[Hipmonlee]

Fascinating!

And option 2 seems like a very sensible approach that balances maximising cart accuracy without including utterly gamebreaking nonsense. Nice work!

 

[NotVeryCake]

I also have to ask another question for these people with a fervour to cart accuracy. How far do they actually want to take this. A precedent where we just ban every thing that could cause an issue in cart, no matter how niche the situation opens up such an awful door. There are definitely countless desyncs that are undiscovered, are we just going to ban everything that caused one. What if we somehow find out Body Slam or Ice-type moves and what have you not can cause a desyncs under hyper specific circumstance, are we going to ban them and therefore take away vital tools? There has to be a line drawn in the sand for how far this was going to be taken, and this was decided back when desync clause was implemented. To be honest this just feels like the limited amount of people who never liked desync clause to begin with are just trying to use a new reason to get it removed, despite it being the wish of the players to have desync clause as it was literally voted on.

If we really want to be fair open and democratic about this, let's go ahead and hold another vote on desync clause, as this bug here is something that directly falls under the jurisdiction of it. This thread needs to go to Policy Review either way, I'm not really sure why it's in the RBY thread and not there to begin with. I think we all know how that vote would turn out though.

 

[Deezcastforms]

option 4 - get rid of the fight button and go back to the way it was before

Completely ignorant comment (sorry, I was mean :D ). The Fight button is just an interface to indicate that no actual move is being committed. Even if we displayed the moves in the client, the internal behavior would still follow the updated logic that matches the cartridge. That's already what happens when you're still trapped after 2 turns—since you don't know if you're still trapped, the moves are shown. However, internally, no move is committed.

Any option that bans Counter would be loathsome to me. Worshipping cart accuracy is not close to being worth banning as prominent an aspect of the metagame as Counter. I would rather revert the updated logic of the internal behavior to what it was before the fight button implementation than allow Counter to be banned.

Expanding desync to make this work so that we have both the updated logic and Counter naturally seems like the ideal outcome. If the devs can't figure it out, then either ignore it or revert the update. Removing Counter would be a needless net negative to RBY.

 

[Soda Eesti]

Would doing something like - if move abort move if turn use offline implementation - be off the table? Its not as consistent as we'd like but its not completely insane, its closer to cart accuracy than just ignoring it or deciding the interraction ourselves (which should be completely off the table, alongside other mods that change how the game functions in a way thats not these 2.) and keeps the status quo for moves like counter.

 

[hammer798]

I think that, broadly, enforcing complete cart accuracy is an unfeasible goal and one we already give up on in specific situations for competitive balance (Freeze/Sleep clauses in particular). Not to say that cart accuracy isn't valuable (I personally think that the many quirks specific to RBY make these tiers more interesting than many modern tiers), but removing significant parts of the metagame in pursuit of it feels like the wrong approach. I strongly oppose banning Counter and Quick Attack. These moves add meaningful depth to metagames that already by their nature have extremely limited options, and unlike other moves we've banned, like evasion and PT moves, this is not an issue of competitive balance, just one of philosophy.