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

Fixed Future Sight not being affected by Electrify #6213

Conversation

AsparagusEduardo
Copy link
Collaborator

@AsparagusEduardo AsparagusEduardo commented Feb 7, 2025

Description

I also updated Color Change tests to use Kecleon.

Issue(s) that this PR fixes

Closes #4471

People who collaborated with me in this PR

@AlexOn1ine, who provided a better fix + a fix for Instruct's dynamic move type

Discord contact info

AsparagusEduardo

@AlexOn1ine
Copy link
Collaborator

There is a more simple fix for this

@AsparagusEduardo
Copy link
Collaborator Author

There is a more simple fix for this

Oh, weird, the commit that had the simpler fix wasn't included

@AsparagusEduardo
Copy link
Collaborator Author

Ah, I didn't push it lol

@AlexOn1ine
Copy link
Collaborator

AlexOn1ine commented Feb 7, 2025

Removing the resets of dynamic type means that it is never reset besides ai calcs which seems like a footgun. Also according to this change if an -ate ability user uses a a normal type move, gets worry seeded before instructed, it will retain the type change before it got it's ability suppressed.

Generally Instruct seems fundamentally broken. Here is one test that also fails but I think there are more because the instructed move doesn't go through the proper checks.

DOUBLE_BATTLE_TEST("Instructed move will be absorbed by Lightning Rod if it turns into an Electric Type move")
{
    GIVEN {
        PLAYER(SPECIES_WOBBUFFET);
        PLAYER(SPECIES_WYNAUT);
        OPPONENT(SPECIES_PIKACHU) { Ability(ABILITY_LIGHTNING_ROD); }
        OPPONENT(SPECIES_WOBBUFFET);
    } WHEN {
        TURN {
            MOVE(playerLeft, MOVE_TACKLE, target: opponentLeft);
            MOVE(opponentLeft, MOVE_PLASMA_FISTS, target: playerLeft);
            MOVE(playerRight, MOVE_INSTRUCT, target: playerLeft);
            MOVE(opponentRight, MOVE_CELEBRATE);
        }
    } SCENE {
        ANIMATION(ANIM_TYPE_MOVE, MOVE_TACKLE, playerLeft);
        ANIMATION(ANIM_TYPE_MOVE, MOVE_PLASMA_FISTS, opponentLeft);
        ANIMATION(ANIM_TYPE_MOVE, MOVE_INSTRUCT, playerRight);
        ABILITY_POPUP(opponentLeft, ABILITY_LIGHTNING_ROD);
        NOT ANIMATION(ANIM_TYPE_MOVE, MOVE_TACKLE, playerLeft);
    }
}

For the Future Sight fix you could just move gStatuses4[i] &= ~STATUS4_ELECTRIFIED to the function BattleTurnPassed into this loop which just means it will always be removed after Future Sight is done. And ENDTURN_ELECTRIFY can be deprecated after this change.

    for (i = 0; i < gBattlersCount; i++)
    {
        gChosenActionByBattler[i] = B_ACTION_NONE;
        gChosenMoveByBattler[i] = MOVE_NONE;
        gBattleStruct->battlerState[i].absentBattlerFlags = gAbsentBattlerFlags & (1u << i);
        gBattleStruct->monToSwitchIntoId[i] = PARTY_SIZE;
        gStatuses4[i] &= ~STATUS4_ELECTRIFIED;
    }

@AsparagusEduardo
Copy link
Collaborator Author

Generally Instruct seems fundamentally broken. Here is one test that also fails but I think there are more because the instructed move doesn't go through the proper checks.

DOUBLE_BATTLE_TEST("Instructed move will be absorbed by Lightning Rod if it turns into an Electric Type move")
[...]

I'll be adding this as a KNOWN_FAILING test ^^;

For the Future Sight fix you could just move gStatuses4[i] &= ~STATUS4_ELECTRIFIED to the function BattleTurnPassed into this loop which just means it will always be removed after Future Sight is done. And ENDTURN_ELECTRIFY can be deprecated after this change.

    for (i = 0; i < gBattlersCount; i++)
    {
        gChosenActionByBattler[i] = B_ACTION_NONE;
        gChosenMoveByBattler[i] = MOVE_NONE;
        gBattleStruct->battlerState[i].absentBattlerFlags = gAbsentBattlerFlags & (1u << i);
        gBattleStruct->monToSwitchIntoId[i] = PARTY_SIZE;
        gStatuses4[i] &= ~STATUS4_ELECTRIFIED;
    }

This didn't do it undortunertly, but I get the idea.
image

Removing the resets of dynamic type means that it is never reset besides ai calcs which seems like a footgun. Also according to this change if an -ate ability user uses a a normal type move, gets worry seeded before instructed, it will retain the type change before it got it's ability suppressed.

It still reset in CheckChangingTurnOrderEffects, which is called by SetActionsAndBattlersTurnOrder, which is called by HandleTurnActionSelectionState, which is also called by BattleTurnPassed.

@AsparagusEduardo AsparagusEduardo added category: move effect Pertains to move effects bugfix Bugfixes labels Feb 7, 2025
@AsparagusEduardo
Copy link
Collaborator Author

Applied changes discussed on Discord

@AlexOn1ine
Copy link
Collaborator

Since I collaborated probably better if someone else finishes the review 😅

@Bassoonian Bassoonian merged commit d510a39 into rh-hideout:master Feb 9, 2025
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugfix Bugfixes category: move effect Pertains to move effects
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Electrify does not Change the Type of Foreseen Moves
3 participants