It looked to me that the 0, 1, 2, and 3 were getting the data stored at (armormemoryaddress + ArmorIndex + EquippedArmorIndex * 36 + 2 + x) then applying it to characterIDmemory + something.
0 takes data from just weapons, 1 from armors, 2 and 3 return a NULL value no matter what. Unless they changed the code for that function during the port process, but I doubt so.
OK, I see what you're saying now. What happens in this function is that it adds the weapon's atk to the character's strength to get the new attack power and stores it...somewhere (haven't looked into that yet). Then it takes the armor's Def and adds it to the players Vit to get the defense, but it never even looks at the MDef of the armor. For the other things, Atk%, Def%, and MDef% it just uses whatever the weapon/armor has for those values during damage calculation so those never really get stored anywhere on the characters' data. It's starting to make me wonder if there is even a place for "adjusted MDef" on the character's immediate data... That's something else to look into. *sigh* and I was hoping that it was just an incorrect pointer.
It looks like just a small injection might work, but that gets hairy because all the absolute addresses would be changed.
You're right though. Passing 2 or 3 just makes it 0 it's other argument and return. Weird. Maybe at one point there were two accessory slots?
UPDATE: I've narrowed the problem down! The problem IS with that function. That function applies Equipment changes to the variables that damage calculation use for Atk, Def, MAtk, MDef and happens every time a weapon/armor/accessory is equipped.
This is what happens:
1. Character ID and update type (0-Atk; 1-Def; 2-MAtk; 3-MDef) is passed to this function
2. The function does one of four things depending on the update type:
0. It gets the Weapon's Atk and assigns that number to a temporary Atk based on character ID which is later added to str to get the final attack
1. It gets the Armor's Def and assigns that number to a temporary Def based on, etc.
2. It does NOTHING. This is where MAtk WOULD get updated, but since no equipment modifies MAtk (might modify Magic stat instead) this is just skipped and always returns a 0.
3. Same as #2
The case for update type 1 does this:
.text:006C51AD loc_6C51AD: ; CODE XREF: ApplyBonusStats+2Aj
.text:006C51AD mov eax, [ebp+var_8]
.text:006C51B0 mov ecx, dword_919928[eax*4]
.text:006C51B7 imul ecx, 84h
.text:006C51BD xor edx, edx
.text:006C51BF mov dl, byte_DBFDA9[ecx]
.text:006C51C5 imul edx, 24h
.text:006C51C8 xor eax, eax
.text:006C51CA mov al, byte_DBCCE2[edx]
.text:006C51D0 mov [ebp+var_4], eax
.text:006C51D3 jmp short loc_6C51E5
The case for update type 3 SHOULD be this: (ignore the addresses, it shouldn't overwrite condition 1)
.text:006C51AD loc_6C51AD: ; CODE XREF: ApplyBonusStats+2Aj
.text:006C51AD mov eax, [ebp+var_8]
.text:006C51B0 mov ecx, dword_919928[eax*4]
.text:006C51B7 imul ecx, 84h
.text:006C51BD xor edx, edx
.text:006C51BF mov dl, byte_DBFDAE[ecx]
.text:006C51C5 imul edx, 24h
.text:006C51C8 xor eax, eax
.text:006C51CA mov al, byte_DBCCE3[edx]
.text:006C51D0 mov [ebp+var_4], eax
.text:006C51D3 jmp short loc_6C51E5
but of course, it's not. This would require replacing a 7-byte statement with a 40 byte block. I don't know how to safely inject code so it might be better to do it your way, Gemini. An absolute jump to anywhere takes 5 bytes so either followed by two no-ops, or a re-targeted relative jump. So point me to an unused spot in the executable and I can fix it for ya. XD Of course, I'll have to test this theory out.
NEW UPDATE: I have successfully patched the PC executable to account for the MDef of the Armor!
See proof. I have submitted my changes to dziugo who will make it compatible with YAMP. Hopefully, it'll be done this weekend.
I did end up using Gemini's method because code injection's a pain to attempt and this worked just fine. I haven't tested it in battle yet because I don't have a very suitable save to test it. Anyone want to donate a save with the airship and normal stats so I CAN test it?