FIGHT Button Implementation Side Effects (Desync/Infinite Sleep)

Hello RBYers. We’ve recently had a cart accurate implementation of the FIGHT button on our sim, which is helping our battles be closer to original mechanics. I want to start by thanking Hydrametr0nice for the work on this implementation and bingingem for helping me understand these changes. Please correct me if I messed anything up here.

As a result, we’re discovering new bits about how this interacts with other gen 1 specialties, like sleep/pt/counter. Particularly, there’s a condition that prevents sleep from burning during pt, as well as a new major desync condition (also counter related).

The goal of this post is twofold: 1) to update everyone on the changes, and 2) to open a discussion on how far we want to take desync clause. I’m just going to post the info to the best of my knowledge, give my brief opinion, then leave it for others more engaged in the community to decide how to proceed.

Summary 1: Infinite sleep during partial trapping.

If you are trapped (by wrap or other) and select the FIGHT button, your last move used is set to a variable called CANNOT_MOVE. This variable overrides any sleep checks, so if you then switch a sleeping mon, you will not be able to burn turns nor wake at any point.

This only occurs if you switch to a sleeping mon after clicking FIGHT while being trapped (T3 or later of wrap). If you switch to a sleeping mon immediately after being wrapped (T2 of wrap), the above variable is not set and everything is fine.

As far as I know, the only way to clear this condition is to switch out, wait for a new wrap cycle / other move selection. The opponent can even switch Pokémon and start attacking, and you’re still locked (shown in this replay here https://replay.pokemonshowdown.com/gen1ou-2577504641-29sthgvqhu4dyuepm8j01nim8e7am7dpw)

This one is more straightforward. Everything works, just be aware of the change and status. There’s even an implemented tooltip to explain it now.

Explanation from Hyddra:
1775582895485.png


I recorded two videos on actual international cart (red vs blue) on a link battle (sorry for the shit quality). In video one you see things working “properly” with an immediate switch to a sleeping mon upon being wrapped. In this case, FIGHT is not selected while under pt (by the awake mon), so CANNOT_MOVE is never set, and the sleeping Pokémon can burn turns normally. In video 2, we see the Beedrill select FIGHT after being trapped (which sets CANNOT_MOVE), then switch to sleeping Parasect, and Parasect never gets the animation of sleep turns burning. Around 45sec we see a new instance of wrap being initiated, and the condition persists. I tested this multiple times, ftr.


Summary 2: Priority desync during sleep following counter/quick-attack.

To quote Hydra directly “Basically, when a Pokémon in asleep or frozen, its owner sees it with the same priority as the last move used by their team, but the opponent sees that Pokémon with the priority of the first move in its moveset.”

So this would trigger if you select a priority changing move (counter or quick-attack, idt there’s others?), then switch to a sleeping/frozen mon. Now, you see things with priority of counter (ie -1, so you always go second), but your opponent sees things “normally.” If you were to wake/thaw on that turn while your opponent used a status move, that would trigger a battle desync and crash. (Not actually sure if thaw is relevant because that situation is impossible with thawing; we have to look into that)

1775582870772.png

Worth noting, devs are still figuring out how to exactly implement this desync, so currently games just move forward with the speed change occurring for both players, but that isn’t accurate.

We noticed this in an example during rbywc yesterday in Peasounay vs Suikyo, so let’s take that as an example here. Start at T10, we see Suikyo’s (AsmiRedx) Snorlax use Counter. T11, Suikyo goes Jynx vs Victreebel. Now, the game calls priority for Suikyo based on last move move (counter), so it has priority -1 and is slower. On actual cart, Peas would’ve seen priority based on Jynx’s first move in slot (assume Lovely Kiss), so jynx would be faster. Here would cause the desync. I’m not too sure on exactly how desyncs work, but I don’t think the game would crash yet. However, on T12 it would: Vic uses Sleep Powder. On cart, from Peas’ perspective, Jynx would wake and then take Sleep Powder and be slept; but from Suikyo’s perspective, Jynx is slower, so Sleep Powder would miss, Jynx would then wake and be awake to do stuff (as happened in the replay). Now we have a difference in game state and the desync is fully catastrophic.



This is the core of the discussion: we either need to expand desync clause to handle this someway, or just ban counter (unfortunately quick-attack would have to be banned as well).

The way I see it, we have 3 options, but option 2 isn’t viable imo:
  • Expand desync to account for this situation in some way by manually fixing the priority. Devs are working on this but haven’t quite figured out the best way to do it.
  • Ignore it. Let it play out as happened in the above game.
  • Ban priority changing moves (counter and quick attack)
Acetylaldehyde’s feelings: Option 3. Historically, I’ve been both pro-counter and pro-cart accuracy. However, idt these two can co-exist anymore. I think the reality is desync clause will be pulling too much mechanical weight for its use case, so we should really consider that priority changing moves in gen 1 just don’t work right.
 
Hey, as the developer of all these Gen 1 mechanics, I just want to explain why this latest desync isn't patchable like the others.

Our desync clause basically works like this: if the game is about to desync, we simply abort the move. All the desyncs we've had so far happened during move execution, so they were easy to fix.

The problem with the priority desync is that it occurs when the players' choices are being committed. The only way to apply the current desync clause would be to abort the entire turn, which could result in both players repeatedly selecting the same moves, waiting for the other player to concede selecting a different move.

From an objective developer standpoint—setting aside players who may not want to change the format—there are two main solutions to make the desync clause as objective as possible:
  1. Ban Counter, Quick Attack, and any other moves that could cause desync. That might be a relatively big list with Wrap moves, Bide and Psywave. Edit: Thawing alone can cause desync, so no relatively small ban list would fix ALL desyncs.
  2. Change the desync clause mod from aborting the move to executing it from the acting player's point of view. This would match the behavior seen when playing against NPCs and is essentially how it works in Pokémon Stadium.
Of course, after implementing the first option, I could still apply the second one, since it wouldn't affect Smogon formats anymore and would solve the priority desync.

But ultimately, it's up to you!

can we ban counter already
To prevent this priority desync, it would also require the ban of Quick Attack.
option 4 - get rid of the fight button and go back to the way it was before
:blobthumbsup:
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.
 
Last edited:
Completely ignorant comment. The Fight button is just an interface to indicate that no actual move is being committed. Even if I 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, so the moves are shown. However, internally, no move is committed.
mean. I was just making a joke :(
 
However, I just remembered that thawing alone can cause desyncs, and since we won't ban all freezing or all burning moves...
id be content if we banned qa/counter due to not being straightforward to patch (unlike psywave) and just keep the clause for the straightforward cases (like psywave). they're different cases, one is easy, make the desyncing move fail, the other doesn't really have a single move culprit that we can fix by causing move failure.
 
I empathize with the cart accuracy perspective, but personally I’ve come to the complete opposite conclusion for the same reason.

Let’s just embrace modding! Seriously. I think banning all the stuff that causes desyncs would be lame as hell. We’d have to remove sleep moves, most Ice-type moves, partial trapping, and moves that change priority. That’d remove a lot of dimension from the tier and I personally would not enjoy playing RBY if these were all banned.

Matter of fact, I think we should add MORE mods to make the game the best possible version of itself. I know we’re supposed to limit modding to only when it’s “absolutely necessary.” But like, that clearly isn’t true. We have already accepted Sleep Clause Mod and Freeze Clause Mod when neither is necessary. The uncompetitiveness of multiple freezes is massively overblown, and we could always just play the game without sleep.

If we decide to go ahead and expand desync clause to cover this, I think we should also work on patching out other bugs as well, such as the 1/256 miss and the Fly/Dig invulnerability glitch. Lets make this game the best possible version it can be.
 
The way I see it, we have 3 options, but option 2 isn’t viable imo:
  • Expand desync to account for this situation in some way by manually fixing the priority. Devs are working on this but haven’t quite figured out the best way to do it.
  • Ignore it. Let it play out as happened in the above game.
  • Ban priority changing moves (counter and quick attack)
I'd like to look at this from three perspectives: the perspective of desync clause as policy to deal with, as a compromise for cartridge accuracy, and as it impacts RBY as a competitive game (specifically OU since that's what I'm well-versed in)

To start, I'd like to clarify the core belief that underpins my opinions on this: we will find more desyncs. It's guaranteed we have not yet found every situation that causes a desync, and it's unlikely we'll ever truly figure out all the edge cases. Desync clause would therefore need to be continually expanded as more triggers become known.

All attempts at expanding desync clause require, for each interaction that cause a desync, a decision on the part of the council as to which side of the desync is the "true" side, in the case of Counter that being the side where the move doesn't execute. If we were to keep going forward with desync clause as the solution, it seems to me like it'd make it progressively harder to keep a consistent philosophy and would require a very involved approach from the developers, constantly adding patches to how the flow of battle works to adjust to players' expectations. For these reasons, I don't think expanding desync clause is the correct option.

As a compromise for cartridge accuracy, desync clause was necessary to prevent the game from exploding whenever someone clicked Counter in otherwise completely normal gameplay. While I'm not the biggest proponent of cartridge accuracy, and am much more concerned with the player experience, I can see that desync clause was previously a simple answer to a simple problem. With the addition of these new triggers to the clause though, the simulator would be making many micro-adjustments to fit broken mechanics in a vaguely coherent box. I don't think anyone genuinely thinks of making a desync end the game as a viable solution, but expanding desync clause also makes the game stray farther than before from cart accuracy, which is what the new changes from Hydrametr0nice brought us to. I think if you're interested in both cart accuracy and playing RBY OU, the only logical step is to ban moves that cause ever-increasing numbers of desync problem when used on carts.

Finally as it impacts OU competitively: The current implementation of Counter, while something I appreciate as a novelty that gives Gen 1 part of its unique charm, also undeniably creates a lot of confusion among new players. I don't think that's necessarily a bad thing: non-intuitive things can also add depth, and there's a real case to be made that the depth added by Counter compensates for the initial confusion players go through while learning the game. However, as more situations cause desyncs, and more arbitrary fixes get added to work around those situations, the game becomes more complex while not necessarily adding any more depth.

For these reasons, I think the best way forward is to ban priority-changing moves. Add it alongside Fly and Dig to the list of moves that make RBY unplayable if used incorrectly and therefore cannot be used on sim.
 
I just want to clarify what the second option would look like in practice.
Change the desync clause mod from aborting the move to executing it from the acting player's point of view. This would match the behavior seen when playing against NPCs and is essentially how it works in Pokémon Stadium.

After that, I'll remove myself from this conversation except to answer questions about mechanics, cause I have to go watch Sporting beat Arsenal.

To start, I'd like to clarify the core belief that underpins my opinions on this: we will find more desyncs. It's guaranteed we have not yet found every situation that causes a desync, and it's unlikely we'll ever truly figure out all the edge cases. Desync clause would therefore need to be continually expanded as more triggers become known.
To be clear, this solution would solve any possible future desyncs. We would always solve it by simply mimicking from an offline pov, there would be no more room for subjective discussions.

This is how all the existing desync mechanics would unfold:
  • Counter would react based on the last move selected by the target, even if paralyzed. What causes the desync is that the last move selected might be different from the last move actually used. This would lead to less desyncs! All the instances where you currently don't desync, you still wouldn't desync.
  • Thawing before acting would allow your Pokémon to use whatever the last move used by your team was, even if your Pokémon doesn't have that move (this is a funny one).
  • Psywave would never roll a 0.
  • Bide's accumulated damage would just reset to 0 when a Pokémon faints (current behavior). This was wrong. From an offline pov, Bide accumulated damage would stay the same when a Pokémon faints.
  • If Mirror Move copies a trapping move and the opponent switches out, the player would reuse the trapping move from turn zero. Metronome would still fall back to using Metronome (since this was actually patched by them).
  • The priority of a sleeping/frozen Pokémon would always be the same as the last move used by its team (current behavior).
 
Last edited:
Matter of fact, I think we should add MORE mods to make the game the best possible version of itself. I know we’re supposed to limit modding to only when it’s “absolutely necessary.” But like, that clearly isn’t true. We have already accepted Sleep Clause Mod and Freeze Clause Mod when neither is necessary. The uncompetitiveness of multiple freezes is massively overblown, and we could always just play the game without sleep.

I do think RBY has a lot of bad things about it that could be fixed with many mods. My main problem with adding mods to fix moves is that it demands that we decide as a community what the moves "should" do. Is Counter hitting on the switch an intended mechanic or a bug? If you fix Fly/Dig invulnerability, do you put the Pokemon back on the ground or let them be invulnerable for another turn? This strays further into the territory of pet mods than what I'd like
 
I think ideally we would all like the RBY we play to be completely cart accurate, but this isn't really an option unless we remove so much of the game as to make it unrecognizable. We're already picky choosy about what we decide to patch out. But I don't think this discovery is any cause to get all gung-ho about patching out every single bug. The dig/fly and the 1/256 bugs don't have anything to do with desyncs, but as far as I know nobody was clamoring to have them fixed before this discovery.
 
Change the desync clause mod from aborting the move to executing it from the acting player's point of view. This would match the behavior seen when playing against NPCs and is essentially how it works in Pokémon Stadium.
Replacing the current desync mod with active-player desync mod seems most sensible to me. If desyncs are going to be handled with a mod, surely a one-size-fits-all mod that covers all desyncs now and in the future is preferable to a pick-and-choose method where some desyncs get modded and others banned.
 
We’d have to remove sleep moves, most Ice-type moves, partial trapping, and moves that change priority. That’d remove a lot of dimension from the tier and I personally would not enjoy playing RBY if these were all banned.
Why would we have to remove sleep moves and priority changing moves? Doesn't removing just one solve the problem?
As I pointed out earlier unless there is something I'm not aware of, PT can stay and the issue is Mirror Move. Not to mention there is a compromise here where we keep current mods and just remove this edge case with bans (and it is an edge case, every other known desync is caused by a single move that changing to failure fixes, while this case involves a two turn setup with no clear move that changing to failure solves). It's useless to advocate for removing mods at this point but I don't think any of this requires us to add more. We can keep Psywave and Mirror Move without expanding mods even further than they already are. It is simply the cleanest solution to not touch desync mod and remove priority changing moves and call it a day.
 
Counter desync becomes an irrelevant issue if you force counter/qa into slot 1. If you do this approach, the raised/lowered priority will be stored on both sides. You don't even have to actually force the moves on slot 1 in sim if you want you can just pretend it's in slot 1 if you replicate the game on cart. If you wanna be really pedantic, you can ban counter/qa on the same set since u cant force both on slot 1 but electabuzz is the only mon that learns both, and I don't rlly think this would be a necessary ban to begin with
 
Counter desync becomes an irrelevant issue if you force counter/qa into slot 1. If you do this approach, the raised/lowered priority will be stored on both sides. You don't even have to actually force the moves on slot 1 in sim if you want you can just pretend it's in slot 1 if you replicate the game on cart. If you wanna be really pedantic, you can ban counter/qa on the same set since u cant force both on slot 1 but electabuzz is the only mon that learns both, and I don't rlly think this would be a necessary ban to begin with
so if i want to use counter on a pokemon, now all my pokemon need counter in their slot 1 or risk desync? one of us is misunderstanding something and i hope its not an average melbelle dumbass moment

edit to actually explain what i think lol thats more useful than whatever i said before:
i believe its slot 1 of the sleeping mon, aka jynx needs counter in their slot 1, not the other counter user
 
Counter desync becomes an irrelevant issue if you force counter/qa into slot 1.
Electabuzz has access to both Counter and Quick Attack, so unfortunately this isn't a universal solution.

teh read challenge (i think this issue should just be handled by desync clause anyways)
 
so if i want to use counter on a pokemon, now all my pokemon need counter in their slot 1 or risk desync?

on cart yes, but as i said for sim: "You don't even have to actually force the moves on slot 1 in sim if you want you can just pretend it's in slot 1 if you replicate the game on cart"
 
on cart yes, but as i said for sim: "You don't even have to actually force the moves on slot 1 in sim if you want you can just pretend it's in slot 1 if you replicate the game on cart"
issue is, what if i want to run a jynx without counter, and also run counterlax? again, i believe the issue is the slot 1 of the sleeping mon, not the counter user. jynx not running counter = counter cant be jynx's slot 1.
 
issue is, what if i want to run a jynx without counter, and also run counterlax? again, i believe the issue is the slot 1 of the sleeping mon, not the counter user. jynx not running counter = counter cant be jynx's slot 1.
you are correct and this is dumbass gastlies moment, my solution does not work, i'll leave the posts up so if anyone else thinks of this they'll know why ty for clarifying
 
Feel like I kinda have to agree with the side of expanding desync clause even if we don’t catch all potential desyncs. As nice as cart accuracy is idt it’s really feasible and we already have stuff like sleep clause so what’s one more. Also we’d have to ban a lot of stuff for this to be properly addressed from a ban perspective so I’d think expanding the clause is just easier for the sake of tiering.
 
I lean toward option 2 introduced by Hydra. It seems like a reasonable way to handle desyncs and preserve, in my opinion, an important part of the game. If we're going to have a mod to the game, a more encompassing approach seems ideal. I do think link play mechanics should take precedent over offline mechanics, but if we're going to mod the game, I think offline play is preferable to moves just outright failing.

I am curious how this would work in practice:
Counter would react based on the last move selected by the target, even if paralyzed.
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?

Also, big thanks to Acetylaldehyde for your time verifying these changes and starting this discussion. And to Hydrametr0nice for your work implementing these changes.
 
Back
Top