FE6 Lance's speed stat resets from 28 (0x1c) to -4 (0xfc) on game load at mission 16

[Lord-Nightmare]

Noted as happening on Keizaron's stream at ~5am on Sunday, Feb 9 2020. A negative int8 speed stat value will appear as "--" which has been noted as happening before in issue #184.

If the pre-mission incorrect speed stat is fixed in a debugger (tested in MAME mame0217-547-g819af3ced9) and saved again, pre-mission, on next load the stat will seemingly be clamped from whatever value it was set to, to that value AND 0x1F, sign extended, effectively clamping it to the range -16 to 15. (Note I only tried a few of these values and did not try a value which ended up with -16)

I've attached a UPS patch (to be applied on the 16777532 (0x100013c) bytes long FE6_English.gba, which has a CRC32 of 99B8B6D7, SHA1 of 32605FD456677EF740F8D521E9A3894ACE4BC59C, SHA256 of 306123D412BA0AEE6701973EDB8844505CECDE290A645F8C191D10BABB836C6A ), and attached both the original savegame (which has lance's speed set to -4 so '--') and a patched savegame done with MAME in the debugger with the value set to 0x0F instead, which doesn't wrap. This particular UPS patch does NOT have Zeiss-turned-Allen's unit type and inventory changed back to stock Zeiss' unit type and inventory, so it will softlock on the second enemy turn, see #193 .

Lets_Try_Again.zip

[lushen124]

What's interesting is that this, alongside what you said for #184 as well as another ticket #195 all sound like the same issue, and they seem to happen when you get up near the cap and they all seem to happen around the same area, though that might just be because this is probably when you might even come close to capping something. Considering this doesn't happen with the original Japanese ROM, I'm guessing the subroutine to read the stats isn't masking the result properly. If I recall correctly, the highest stat the game is even capable of storing is 31 (5 bits).

My first stab would be to be able to force it to happen to see if that sheds light on things.

[lushen124]

So I've tried to force it to happen in Chapter 1, but I couldn't get it to overflow, so it doesn't seem to be a matter of the stat being a specific value (which I guess I should have known since you're seeing it with a value of 28 while every other case thus far has been reaching a cap of 30). I don't expect that to make a difference regardless, since any value above 16 should be sufficient to trigger any sign extended negative value.

That said, the other commonality I mentioned was that they happen in Chapter 15/16. I wonder if the report from chapter 15 actually got the chapter wrong, because I can definitely see something weird happening in Chapter 16. There are already known issues about Hugh's stats being wonky with the translation patch, even though we never knew why that was. If something is accidentally modifying stat values, there's a chance that that also causes issues with other characters.

I'm not sure how to reproduce it. The save file you provided helps, but I wish I had a save from the chapter prior so that I could maybe track memory values to see what was updating it to the wrong value. I'll punt on the issue for now until I can get my own save (or if you're willing to get a save up to chapter 15 that will exhibit the issue in chapter 16).

Also, just to make sure, since I can't quite tell: were classes and/or recruitment randomized? I couldn't tell if Lance started as a myrmidon or if he also replaced somebody else's spot.

[lushen124]

I'm hoping #330 fixes this by updating to the new localization patch. I'm not sure what could have caused it from the randomization logic, so for the time being, I'm going to close this. If it continues to happen with the new localization patch, please file another bug.