FE6 Negative Growths

Projects
,
1

Here is the last entry in the negative growths trilogy. It’s been a while since the last installment but I was asked to complete an FE6 version so I went ahead and did it. I would like to shout out Geene for requesting this and helping test it. He is also the first person to my knowledge to beat FE8 Negative growths, at least on camera. Check him out if you’re interested in seeing him attempt FE6.

Be aware that if you want to use a translation patch to play this you must use an older patch. I have put a patch that uses the compatible translation in the download link. The reason for this is that later translation patches introduced a glitch that does not play well with decreasing growths. You can find more information on that glitch here: https://forums.serenesforest.net/index.php?/topic/91730-trying-to-help-gather-info-about-the-hugh-glitch/

There are still visual glitches during level-ups under certain circumstances similar to the other versions but don’t let it worry you, your stats will be fine after the level-up is over.

Have fun!

Download:

2 Likes
2

I never thought I would see my hughglitch thread be referenced in any way ever. Anyways, what exactly about it clashes with negative growths? Just wondering.

3

I don’t fully know to be honest, but it probably has to do with the fact that I ended up doing the stat lower bound check in a different place than the other hacks. I did it after the stat changes were applied instead of before. Saving and reloading after getting a level below 0 caused an underflow. It was fine in-game until you reset, so it must have been stored in sram as it was before my check and loaded back as an unsigned int after the reset. The game for some reason uses signed ints until it reloads a save, so I check that to see if a stat went negative. Once it’s not negative it eventually get reduced to it’s cap. I don’t completely understand how the hugh glitch works but the problem in negative growths only happened to stats that had class bases that would become negative and that the problem disappeared without a translation patch, so I’m fairly certain it is the same glitch.

4

I’m almost certain this has nothing to do with the way you enforce lower bounds on stats.

If we take what the person said in the thread at face value, (and from my testing it does seem to be the case) then this is what happens.

At some point in time, for an unknown reason the patch that the gringe patch is now based upon has added a piece of code to the way stats get saved.

In the normal JP variant of FE6 and also the other patch that you included, when the game saves it just saves the current stat into the SRAM, that then gets loaded so there is no problem, even with negative growths.

Now that injected piece of code changes it so that instead of saving the current stat, you save the current stat - the personal base in that stat.

Lets take Bors as an example, since he is the first one where I saw it in this case.

The stat that is most likely to underflow is his speed, now the question is why.

At base level Bors has 3 Speed, The Knight class has a class base in speed of 0, so we know all 3 speed he has are from his personal base stat.

In JP FE6 & the non-gringe english patch, when he levels up in speed, his new base speed of 4 gets saved to the sram.

In the gringe patch, it will instead save current Speed stat - personal base stat.

The saved stat is equal to his class base speed (0) + all speed points he has gotten from level ups (1).

When it then loads the game it takes his personal base stat (3) + the stat saved to the SRAM (1) adds those together and we get 4, which is correct.

Now lets use this example in the context of negative growths.

Bors gets his first speed level up and goes from 3 speed to 2 speed.

When we now save the game, it will save the current stat (2) - personal base stat (3). This results in it saving -1 to the sram.

When it saves -1 according to the person in the thread this happens during loading:

But if you haggle twice, now the bug rears its ugly head,. 11 - 12 = -1, -1 is represented in binary form as “11111111”. When the original game takes over and smush everything together in SRAM, it only uses 5 bits of each stats, so 11111111 becomes 11111, or 31 in decimal, instead of -1. Now when you reload, the injected code doesn’t check for this kind of overflow, and just add the character’s base stats as always. So 31 + 12 becomes 43.

Now, because of the way the glitch occurs (subtracting the personal base stat from the current stat) the glitch is easies to see when a character has a much higher personal base stat than the class base with the exception of luck which for some reason allways seems to be unaffected.

For characters with good class bases such as Marcus this will still happen, but it takes a lot more level ups for each stat so that personal base stat > current stat