Switching phases

[kevinlul]

Originally described 28/10/2019 by @DyXel :

Right now we have this system

        //M2, EP
        if(core.to_m2)
            message->write<uint8>(1);
        else
            message->write<uint8>(0);
        if(core.to_ep)
            message->write<uint8>(1);
        else
            message->write<uint8>(0);

The possible phases are hardcoded. My idea is simple: instead of sending a bool per possible phase, we just send the phases the player can go to OR'd together, e.g.: PHASE_MAIN2 | PHASE_END. The client checks with & and enables the respective buttons; the answer would be the phase the player wants to go to, something like

(t == 2 && (s & PHASE_MAIN2) && core.to_m2) ||
(t == 2 && (s & PHASE_END) && core.to_ep)

This would solve 3 issues: 1) If the player can/must perform a certain phase twice, it would naturally be seen by the client. 2) Foresight: if in the future, we get an effect that makes you go to a certain phase, we will already have it handled; just send the right phase the player is forced to go to and we are done! No client-side change needed. 3) The client would send the phase value as response so its simpler to handle on all cases.

[DyXel]

The reason this was discussed in the first place was because of Weather Control; You are forced to do the 2nd battle phase when the OCG text says its optional.

[KingYamato]

Looking at the code, it'll require refactoring if we want to implement phase switching in a less rigid way than what's been done, what's more, this part of the rules seem to be hardly touched during the years, so it's unlikely we'll actually need finer controls over it. Also, the issue with Weather Control not being optional can be fixed with a script change asking if the player wants to apply the second battle phase effect.