There's a lot of information so I'll try to break it up as best I can:
0x920A8C (0x51F48C)
Here's where the text for the menus resides. There's a duplicate table nearly elsewhere, but it's not used.
Don't be fooled by the references to 0x920A80 (0x51F480), that doesn't reference the text "Nothing", "Normal", etc. It's actually back at 0x9209A8 (0x51F3A8) that skips ahead 19 entries to get to those strings.
This happens in eight places in four chunks.
0x706073
0x706090
0x70623E
0x70625C
0x7069EF
0x706A0C
0x706BB5
0x706BCD
The offending (offensive) code is:
[mov ecx, AP_Growth_mult ;retrieved from the weapon.armor data]
add ecx, 13h
imul 0Ch
add ecx, offset_9209A8
This is more than slightly absurd. If we change it to this:
[mov ecx, AP_Growth_mult ;retrieved from the weapon.armor data]
add ecx, 0 ;we could NOP these three bytes.
imul 0Ah
add ecx, offset_920A8C
Then we'll directly reference that array of words as well as have room for two more. ONLY two more. There are exactly 60 bytes between the start of that and the next set of data. Then we'll have to change the array's dimensions from 5,12 to 6, 10 (again, at 0x920A8C (0x51F48C) ). That's a change of three bytes per section.
The string array will have to be changed too. 0x920A8C (0x51F48C) is this (using the FF7 characters:
Nothing'\n'____
Normal'\n'_____
Double'\n'_____
Triple'\n'_____
'\n'___________
You can change it to:
Nothing'\n'__
Normal'\n'___
Double'\n'___
Triple'\n'___
Quadruple'\n'
Quintuple'\n'
We'll call that all 60 bytes of change. We're getting rid of the blank one, but the next change will account for that.
There are four other related blocks that need to change:
0x70604F
0x706217
0x7069C8
0x706B88
The code block here is:
mov eax, AP_Growth_mult ;from weapon/armor data
mov var_64, eax
cmp var_64, 0 ;lower bound
jl short loc_706XXX ;depending on where this code is
cmp var_64, 3 ;upper bound
jle short loc_706XXX+2 ;depending on where this code is
jmp short loc_706XXX
jmp short loc_706XXX+7
mov AP_Growth_mult, 4
This is a reality check that will set the growth rate text to "" if it gets something less than 0 or greater than 3. That's stupid because the game treats all other numbers as normal growth. So we can change it to this:
mov eax, AP_Growth_mult ;from weapon/armor data
mov var_64, eax
cmp var_64, 0 ;lower bound
jl short loc_706XXX ;depending on where this code is
cmp var_64, 5 ;upper bound
jle short loc_706XXX+2 ;depending on where this code is
jmp short loc_706XXX
jmp short loc_706XXX+7
mov AP_Growth_mult, 1 ;"panic" value
And that will give us six text stings to work with only changing two bytes in each of these sections.
Now we have to actually implement these growths, don't we?
Weapon AP multiplier is set starting at 0x5CAE4A (0x1CA24A).
Armor AP multiplier is set starting at 0x5CAFF9 (0x1CA3F9).
These blocks are needlessly long and inefficient:
pseudo-code
if (multiplier = 0)
{
}
elseif (multiplier = 2)
{
Materia_AP += (AP_Gained & FFFFh) * 2;
}
elseif (multiplier = 3)
{
Materia_AP += (AP_Gained & FFFFh) * 3;
}
else
{
Materia_AP += (AP_Gained & FFFFh) ;
}
What it SHOULD read is:
pseudo-code
if (multiplier > 3) ;upper bound here again too
{
multiplier = 1
}
if (AP_Gained > 65535)
{
AP_Gained = 65535
}
Materia_AP += AP_Gained * multiplier
Anyone disagree that this is a MUCH better idea? Didn't think so. If it happens to go above the upper bound, slap it down to "Normal". That's 79 bytes per section that are now forfeit and reduced to 51 bytes each.
Let's add the changes:
3 * 8 + 60 + 2 * 4 + 79 * 2 = 250 total bytes changed! That's really not that much. If that doesn't seem too involved let me know and I'll provide more details. I just wanted to let you know the scope of changes that would be involved.