In Progress RBY Fight Button Simulation Improvements (Fix partial trapping, improve Counter)

[Plague von Karma]

This is likely a very difficult thing to implement, so I'm not expecting this to be a thing any time soon, but it's something the RBY community has mumbled about for years. Since there's no suggestion thread in sight, well...here I am. A very common criticism of Pokemon Showdown's Gen 1 implementation is that it lacks a "FIGHT" button. This has caused a number of flaws in the implementation of partial trapping. This is also a problem with Counter as well.

The elephant in the room is Wrap, long and far. When using Wrap, Bind, Fire Spin or Clamp, neither player is meant to know if they can move or not until they click that Fight button. You click it, and if you're trapped, the game automatically moves to "communicating". If you're no longer trapped, you get to pick a move, or cancel and switch out. This is a crucial part of how partial trapping works, and the current PS implementation is almost completely wrong.

This also matters for Counter, as it also involves a number of desyncs that result from how highlighting moves processes attacks. This video will explain it better than I ever could. Essentially though, the move type you're using is stored even when switching out on one end, so it can trigger Counter by mistake on one side and desync the game.

Implementing this would be a massive improvement to two of RBY's most relevant attacks, and I hope this can be considered.

Also when will the RBY Council look at the Wrap-Mirror Move Desync

 

[Zarel]

We already implement the Fight button – it similar to the "you might be trapped" warning message you see sometimes. There's no reason you can't do it that way in RBY.

Specifically, the idea is that you just show the moves list as normal, but clicking any of the moves will simulate clicking "Fight" first.

 

[Plague von Karma]

We already implement the Fight button – it similar to the "you might be trapped" warning message you see sometimes. There's no reason you can't do it that way in RBY.

So considering this, Wrap shouldn't be restricting move choice on the user's end, same with thrashing about moves I believe. Making Wrap not restrict move choice would also solve the implementation in Stadium at the same time, actually, as there's an info leak issue there.

On a side note, would highlighted moves prior to switching be possible to store somewhere? That's, uh, part of another desync with Counter on cartridge...the video I linked showcases it. Or would this not quite work?

EDIT: Renamed the thread to better suit the scope now

 

[Hipmonlee]

Ok, I have looked into this.

Counter can be fixed fairly trivially, I have a fix ready to go, but I am not a big fan of it. The problem I have with it is the sim implies that a person is selecting an attack when they have a sleeping pokemon, but they are actually doing nothing of the sort.

I think that is a bad idea, because if you know how Counter is supposed to work, and you see a "FIGHT" button, then you are going to be fairly confident what the outcome of Counter will be on that turn. On the other hand, if you select an attack, it would be absolutely reasonable to expect that selecting that attack will trigger desync clause. Especially since that is how it currently works. Fixing this the trivial way is going to lead to a whole lot of battles ruined when people who havent been warned about the update all figure out what is supposed to happen one by one.

Furthermore, when it comes to Wrap, there is no trivial fix. So, since I am adding the FIGHT button for Wrap, I might as well use it for counter.

Here are two hypothetical scenarios of using wrap that are somewhat common and impactfully broken with the current system, and arent easily fixable without a fight button.

-- SCENARIO 1 --
Dragonite has used Agility, it has wrapped your pokemon into low enough health that your pokemon is now in danger of being KOed by Hyperbeam. If Dragonite wraps, you would like your current pokemon to take that damage, if it Hyperbeams, obviously you need to switch.

On cart: the defending player can select FIGHT. If wrap has not ended, they will not be able to select an attack, but they wanted to stay in in that scenario anyway. And if Wrap has ended, they can back out of the FIGHT menu and switch to another pokemon to absorb the Hyper Beam.

On Showdown: the defending player has no information at all about whether Wrap has ended. They pretty much just have to switch and hope they catch the hyperbeam.

-- SCENARIO 2 --
Tentacruel uses Wrap, Kadabra switches in, and Wrap hits. The Tentacruel user considers a switch to Dugtrio to take advantage of the trapped Kadabra, decides that their opponent will switch out in anticipation of that, so selects wrap again. However, the Kadabra user stays in. The Tentacruel user now wants to switch, in case wrap ends and they are stuck with their Tentacruel in against a Kadabra.

On cart: The Tentacruel user has no way to know whether or not Wrap has ended in this scenario without selecting FIGHT. Selecting FIGHT means that if Wrap has not ended, they cannot switch. If they are going to switch, they must do that without knowing whether or not the Kadabra will be able to attack this turn.

On Showdown: The Tentacruel user can immediately see whether or not Wrap is continuing when they select their move. If it is continuing, they can switch to Dugtrio safely, as the Kadabra will not be able to attack.

---

I think Scenario 2 is fixable by not disabling the other attacks, but whatever you select, if Wrap is continuing, it gets executed instead. But again, this is very misleading.

For Scenario 1, however, the only way I can see this working would be like, you can select your attack, and if Wrap has ended your selection is immediately cancelled, and it asks you to select your attack again, now with the knowledge that Wrap is over. Which, firstly, is utterly unintuitive, but secondly, is that even all that much easier than having the FIGHT button?

My Proposal:

I add a FIGHT button for sleeping, frozen, and pokes involved in partial trapping. Then I add a special case to battle.ts and battle-queue.ts so that FIGHT is never executed or added as lastSelectedMove. This solves the counter issue.

The FIGHT button is handled similarly to onLockedMove, but doesn’t prevent switching.

Then for wrap I replace the partiallyTrapped volatile with a “maybePartiallyTrapped” volatile. The maybePartiallyTrapped volatile forces the use of the fight button.

Then somewhere we need to treat partial trapping as a special case. I think the Pokemon’s getMoves method may be the best place to handle this (because it already deals with a bunch of special cases). getMoveRequest data checks for the onFightButton(?) volatile, if so, notifies getMoves. If the pokemon has maybePartiallyTrapped but is not frozen or asleep, it checks whether the pokemon or its opponent has the partialTrappingLock volatile. If not, then it sets a flag indicating that side.choose should call updateRequestForPokemon to ask for what move the player would like to select, it can clear the maybePartiallyTrapped volatile at that point.

(Checking the opposing pokemon for partialTrappingLock was a suggestion from NOTORIOUS - thanks!)

I also need to ensure you cant undo the FIGHT button if you are maybePartiallyTrapped.

One of the cool things about this is that maybePartiallyTrapped should work for both the attacker and the defender.

Once that is working, I should make it so that the maybePartiallyTrapped volatile gets cleared if wrap has lasted 5 turns.

So the changes are something like:
pokemon.ts---make sure that the fight button appears for selection, set a flag indicating that the FIGHT button should allow attack selection when appropriate.
battle.ts---make sure that FIGHT never executes
battle-queue.ts--make sure that FIGHT does not set lastSelectedMove
conditions.ts---add the maybePartiallyTrapped volatile, with the onBeforeMove from partiallyTrapped (this should check the opposing mon has partialTrappingLock).
side.ts---force the player to reselect their attack when their pokemon is not trapped.
moves.ts---update all the partial trapping moves.

An optional further aesthetic change is to use FIGHT for all locked moves. So instead of checking for a lockedMove, you just check for FIGHT, and once you see FIGHT, you can then do the check for the lockedMove.

This seems like a lot of work, and Zarel didnt seem particularly keen on the idea previously. So I wanted to run it past you before I got any further. Does this seem reasonable?