Allow for growth beyond triple, alternative growth rates

[Tenko Kuugen]

I'd like to give one specific armor or weapon per characters a triple and maybe quadruple
I assume this is likely unproable, but it was worth asking anyway.

So, does anyone know if that's possible?

 

[nfitc1]

I found this once. Like always, don't take my word for it, but it shouldn't be a hard thing. The only issue is the text indicating the growth won't read correctly. I'll have to look it up tomorrow though.

 

[Tenko Kuugen]

I found this once. Like always, don't take my word for it, but it shouldn't be a hard thing. The only issue is the text indicating the growth won't read correctly. I'll have to look it up tomorrow though.

It should be possible to change "Double" or "Triple" into other words to go with the new rates, no?

 

[nfitc1]

How high are you wanting to make this? It's an easy modification, but there are lots of little things that will need to be modified. None of it is complicated, but there will be at least a dozen things that have to be tweaked to add more words.

 

[Tenko Kuugen]

I think one, maximum two more is all that I need
i.e. x4 and x5
anything above is ludricous
Instead of Quadruple, I'll just call it Quadra and Quint

 

[nfitc1]

There's no reason not to say "Quadruple" and "Quintuple". That will make it more clear and separate it from "Quadra Magic".

You can safely go as high as x252 without running into problems.

 

[Tenko Kuugen]

this is mostly for special weapons with 1-2 slots maximum. as there are weapons with 8 slots and double ( for example, Yuffie's Taiou no Maou ) I kinda need weapons with few slots and above triple
quadruple and maybe 1-2 weapons in total for quintuple are enough

 

[nfitc1]

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:
Code: [Select]

[mov ecx, AP_Growth_mult ;retrieved from the weapon.armor data]add ecx, 13himul 0Chadd ecx, offset_9209A8

This is more than slightly absurd. If we change it to this:

Code: [Select]

[mov ecx, AP_Growth_mult ;retrieved from the weapon.armor data]add ecx, 0 ;we could NOP these three bytes.imul 0Ahadd 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:
Code: [Select]

Nothing'\n'____Normal'\n'_____Double'\n'_____Triple'\n'_____'\n'___________

You can change it to:
Code: [Select]

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:
Code: [Select]

mov eax, AP_Growth_mult ;from weapon/armor datamov var_64, eaxcmp var_64, 0 ;lower boundjl short loc_706XXX ;depending on where this code iscmp var_64, 3 ;upper boundjle short loc_706XXX+2 ;depending on where this code isjmp short loc_706XXXjmp short loc_706XXX+7mov 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:
Code: [Select]

mov eax, AP_Growth_mult ;from weapon/armor datamov var_64, eaxcmp var_64, 0 ;lower boundjl short loc_706XXX ;depending on where this code iscmp var_64, 5 ;upper boundjle short loc_706XXX+2 ;depending on where this code isjmp short loc_706XXXjmp short loc_706XXX+7mov 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:
Code: [Select]

pseudo-codeif (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:
Code: [Select]

pseudo-codeif (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.

 

[Tenko Kuugen]

I'm sorry to say that that went way over my head.
Cloudiar wanted to know about this first of all, ( and I thought I'd use it too ) but you're trying to explain this to someone who just about knows how to use editors and change some hex values
I don't actually know how to read code.
stuff like

Code: [Select]

[mov ecx, AP_Growth_mult ;retrieved from the weapon.armor data]add ecx, 13himul 0Chadd ecx, offset_9209A8

Code: [Select]

[mov ecx, AP_Growth_mult ;retrieved from the weapon.armor data]add ecx, 0 ;we could NOP these three bytes.imul 0Ahadd ecx, offset_920A8C

is really beyond me. I wouldn't even know how and what to do where.
I could maybe figure out changing text on my own, but that'd be really it.

 

[nfitc1]

I could tell you exactly what, where, from and to of bytes to change. Just focus on the last few sentences of that post and I can tell you how to do it if you'e interested in a list of the 250 changes that would need to be made.

 

[Tenko Kuugen]

yeah, that sounds like something even a dog could do. I should be able to do that
saving space,
0xYYYYYY ZZ
where as YY is the .exe address and ZZ the value that needs to be written is probably easiest on you

 

[dziugo]

These blocks are needlessly long and inefficient:
Code: [Select]

pseudo-codeif (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:
Code: [Select]

pseudo-codeif (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?

Me! That would be changing the mechanics (limiting the AP_Gained thing different way)

 

[nfitc1]

Me! That would be changing the mechanics (limiting the AP_Gained thing different way)

Vanilla already limits the AP. BUT, instead of pushing it down to 65535, it ANDs it with FFFFh. This can cause an AP overflow issue. So if a battle has more than 65535, say 66K AP, then it will give the modulus answer. Instead of 66K, you'd only get 464 AP. The battle reward screen doesn't account for this (I don't think) and it won't tell you that's what happened.
If that's what you want then shame on you.

 

[dziugo]

I know how it works, just saying that you changed the way the overflow is handled. You won't find a single battle in vanilla FF7 with more that 65k AP anyway.

Edit: The value seems to be stripped to 16bit before even calling the function, so the overflow would never be handled at that point - you could simplify it even more... Anywayz, digressed, sorry for disrupting your thread, please carry on with the productive actions.

 

[Tenko Kuugen]

we're modding the game though so battles >65k AP become a possibility

 

[nfitc1]

The value seems to be stripped to 16bit before even calling the function, so the overflow would never be handled at that point...

Well what do you know. 0x4372FF dumps the AP reward into a 16-bit register space. Didn't notice that before. Still, that has the same overflow resolution problem. Making it eax instead of ax would make that part go away. Just changing the 66 to a 90 would fix that.

 

[Tenko Kuugen]

can you give me the addresses I need to change?

 

[nfitc1]

I just PM'd you.

 

[Tenko Kuugen]

I did the changes as you wrote them down, all of them ( you got quadruple as quakruqle and quintuple as quintuqle but thats just text, easily fixed )
but when i give a weapon higher growth than 3, it just turns into 1

 

[nfitc1]

( you got quadruple as quakruqle and quintuple as quintuqle but thats just text, easily fixed )

What's wrong with that? I thought you'd appreciate a little originality.

but when i give a weapon higher growth than 3, it just turns into 1

Does it say "Normal" or does it say what it should, but not provide (perhaps vice versa)?