fit long z-moves names on battle textbox

[DizzyEggg]

Fixes #2351

[Jaizu]

I think this is fine but we have to be way more careful about text-windows in the future. The ideal solution should be to add a new window called zmovesmovename that uses the same with as move name 1 + move name 2.
To make it more clear, you made the text-window larger but you didnt make the next text windows start on a later baseblock.
Atm it's 12 * 2 = 24 = 0x18 in hex. Current baseblock is 0x300, move name 2 baseclock is 0x318.
To make this correct, we should make the next baseblock have a higher value, including all the other windows that start after that baseblock, otherwise we might overwrite windows in the vram.

[ghoulslash]

I think this is fine but we have to be way more careful about text-windows in the future. The ideal solution should be to add a new window called zmovesmovename that uses the same with as move name 1 + move name 2.
To make it more clear, you made the text-window larger but you didnt make the next text windows start on a later baseblock.
Atm it's 12 * 2 = 24 = 0x18 in hex. Current baseblock is 0x300, move name 2 baseclock is 0x318.
To make this correct, we should make the next baseblock have a higher value, including all the other windows that start after that baseblock, otherwise we might overwrite windows in the vram.

Iirc it doesn't matter because the move names on the right are drawn after those on the left, so it would only overwrite anything if your regular moves have more characters than fit in the regular window, so what you propose is technically just eating into vram unnecessarily

[DizzyEggg]

Exactly what ghoul wrote

[Jaizu]

Ghoul is totally right, I don't know why I didn't consider wasting VRAM with my approach an issue.