-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Conversation
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. |
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. |
So, looking at how I would fix this, here's what I'm thinking:
|
The naive approach might be the best way to do it; only problem could be Sketch. Here's a table of Gen 4
|
This reverts commit 6a65937.
Hmm, that seems to be a more elaborate breakdown then PS currently tracks? To the best of my understanding, PS's 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: 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? |
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. |
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)
)?