Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve Gen 4 Encore behavior #5221

Closed
wants to merge 5 commits into from
Closed

Conversation

scheibo
Copy link
Contributor

@scheibo scheibo commented Feb 28, 2019

Gen IV
  • Encore should fail if the target did not make a move during its turn
    Due to flinch, full paralysis, etc.

Originally posted by @Marty-D in #2367 (comment)

This PR adds a test for this behavior, which already seems to work. However, it also seems to work regardless of generation, which makes me a little worried about what the correct behavior should be/whether the test is correct (for reference, this is the log from the test)?

@Marty-D - can you confirm that this test is testing the scenario you wanted fixed? Should the behavior be Gen 4 specific (in which case, what is the correct behavior for other gens so I can fix it?) or is this universal (in which case, I should just make the test run against the latest generation instead of scoped to gen(4))?

@Marty-D
Copy link
Collaborator

Marty-D commented Feb 28, 2019

Oh, I guess my brief summary isn't very clear. In modern gens (5 onward), using a move, then being fully paralyzed, then being Encored has the Encore succeed on the move used the turn before. In Gen 4 (and earlier I presume, but I'll have to double check 2 and 3 later), that same situation has Encore fail.

@scheibo
Copy link
Contributor Author

scheibo commented Feb 28, 2019

Great, I've updated the tests and now it makes more sense - the current behavior passes the new test case, and the Gen 4 (and possibly before) behavior is failing.

@scheibo
Copy link
Contributor Author

scheibo commented Feb 28, 2019

So, looking at how I would fix this, here's what I'm thinking:

  • the naive approach would be to look into unsetting lastMove in cases where the Pokemon didn't move. I don't think I'd want to do this because I imagine lastMove is used by several other things and this would likely affect their behavior.
  • leverage moveThisTurnResult / moveThisTurnResult. This seems like it would be very convenient - just check if the moveLastTurnResult was successful before determing whether encore should fail. However, I think we also care about moveThisTurnResult because the lastMove could have been attempted this turn before the Encore user moves. However, while moveThisTurnResult has a warning about inspecting it in the middle of the turn, it seems like (!moveThisTurnResult && !moveLastTurnResult) makes my test pass? I'm a little worried about the case where moveThisTurnResult is undefined because the target is mid move? iunno, I'm still in the process of learning all this.

@Marty-D
Copy link
Collaborator

Marty-D commented Mar 1, 2019

The naive approach might be the best way to do it; only problem could be Sketch. Here's a table of Gen 4 lastMove behaviour courtesy of UPC. I'll double check how Sketch works in HGSS in a bit.
Edit: Sketch does indeed succeed even if the last move was prevented.

If... The last move used... The last move called... The last move used (for Sketch)... The last move used by a Pokémon (for Copycat)...
Move is used Is different for each Pokémon in battle Is different for each Pokémon in battle Is different for each Pokémon in battle Is shared among all Pokémon in battle
Move fails, misses, or becomes ineffective Is set Is set Is set [unsure for misses or becomes ineffective] Is set
Move is Pursuit and a Pokémon is about to switch Is set no matter whose attack segment it is [unsure] Is set no matter whose attack segment it is [unsure] Remains unchanged Remains unchanged
Move is prevented from being used Is reset to "no move" Is reset to "no move" Remains unchanged Is reset to "no move"
Move can’t be used because it has zero PP Is reset to "no move" Is set Is set Is set
Move can’t be used because it has no target Is reset to "no move" Is set Is set Is set
Move is used by another move Remains unchanged Is set Remains unchanged Remains unchanged
Move had been taken by Snatch Remains unchanged [unsure] Remains unchanged if Pokémon is the move’s original user [unsure otherwise] Is set no matter which Pokémon’s attack segment it is N/A
Move had been taken by Magic Coat Remains unchanged [unsure] Is reset to "no move" while the move is used, but is then set to that move at the end of its original user’s attack segment Remains unchanged N/A
Move is a two-turnattack Is set on both turns of use Is set only on the second attack segment; is reset to "no move" otherwise Is set only on the second attack segment; remains unchanged otherwise Is set only on the second attack segment; remains unchanged otherwise
Move is Hyper Beam or an equivalent move Is set only on the first attack segment [unsure if reset otherwise] Is set only on the first attack segment; is reset to "no move" otherwise Is set only on the first attack segment; remains unchanged otherwise Is set only on the first attack segment; is reset to "no move" otherwise
Move is Bide Is set on any attack segment of its use, but is reset to "no move" if it fails on the third attack segment of its use Is set on any attack segment of its use, but is reset to "no move" if it fails on the third attack segment of its use Is set on any attack segment of its use, but remains unchanged if it fails on the third attack segment of its use Is set on any attack segment of its use, but is reset to "no move" if it fails on the third attack segment of its use
Move is Mimic, Sketch, or Transform Is set Is set Is set Is set
The Pokémon leaves the battle Is reset to "no move" Is reset to "no move" Is reset to "no move" Remains unchanged
The Pokémon used Baton Pass, Healing Wish, Lunar Dance, or U-turn to leave the battle Is set to the corresponding move at end of new Pokémon’s attack segment Is set to the corresponding move at end of new Pokémon’s attack segment Is set to the corresponding move at end of new Pokémon’s attack segment Is set to the corresponding move at end of new Pokémon’s attack segment
If an item is used with the Bag command Remains unchanged Remains unchanged Remains unchanged Remains unchanged
If the Run command is used and running is unsuccessful Remains unchanged Remains unchanged Remains unchanged Remains unchanged

@scheibo
Copy link
Contributor Author

scheibo commented Mar 1, 2019

Hmm, that seems to be a more elaborate breakdown then PS currently tracks? To the best of my understanding, PS's Pokemon#lastMove corresponds to "The last move called" (I dont think we distinguish between called and The last move used" and not the "The last move used (for Sketch)..." either?), PS's Battle#lastMove seems like it would correspond to "The last move used by a Pokémon (for Copycat)...").

I've come up with two possible solutions to get the specific " Encore should fail if the target did not make a move during its turn (Due to flinch, full paralysis, etc.)" test case to pass:

  • using move{This,Last}TurnResult: 6a65937
  • resetting lastMove if the move is aborted: f99a01b

Neither of these encompass the entire table linked above (I think we would need 4 different fields, not just 2...), but seem like they would still be an incremental improvement over the current state?

@scheibo scheibo changed the title Add test for Gen 4 Encore behavior Improve Gen 4 Encore behavior Mar 1, 2019
@scheibo
Copy link
Contributor Author

scheibo commented Mar 30, 2019

If I'm being honest with myself, I don't think I'm coming back to this. @Marty-D - you should add that table to the card for "Gen 4: Encore targeting in Double Battles" so that the next person looking into this knows about it.

@scheibo scheibo closed this Mar 30, 2019
@scheibo scheibo deleted the gen4-encore branch April 3, 2019 02:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants