ub fix for OOB access with gActiveBattler

[cawtds]

Description

The first call of CheckMoveLimitations each battle (except for the first one each load) is done with gBattlersCount from the previous battle, which is either 2 or 4 and in most cases OOB.
Since the first call after loading the game is always done with 0, setting gActiveBattler = 0 is presumably safe.

Discord contact info

.cawt

[GriffinRichards]

Most of the battler arrays are explicitly sized to MAX_BATTLERS_COUNT, do you have an example of where it can go out of bounds? That's not to say reading those elements is correct, but it'd be helpful to clarify what's actually going wrong here. If gBattlersCount is incorrect at the start of a battle why is that left unchanged?

[cawtds]

SetUpBattleVarsAndBirchZigzagoon -> BattleAI_HandleItemUseBeforeAISetup -> BattleAI_SetupAIData ->. moveLimitations = CheckMoveLimitations(gActiveBattler, 0, MOVE_LIMITATIONS_ALL).
At this point gActiveBattler has not been set yet, so it contains the last value of the previous battle, which is either 0 (after a reset), 2 (single battle) or 4 (double battle) due to gBattlersCount being the for-loop limit. There is multiple accesses of gBattleMons which is of size 4 with battler, so the first call of CheckMoveLimitations after a double battle has OOB reads.