statsutil - Modified stat growth causes all pokemon to "level" to 100 instantly

[DeviPotato]

When I export, modify, and re-import pokemon stats to the PMD sky ROM and try to play it, both my player pokemon and partner pokemon instantly level to 100 after knocking out a single pokemon in the first dungeon. Additionally, they don't gain any stats from these levels, and remain at their base stats.

Moveset changes work perfectly fine, only the level XP/stat growth seems to be affected.

The only pokemon data I directly modified was shaymin (who i modded to be a starter pokemon), but it affects my partner as well no matter what species they are in testing.

Here is my modified shaymin xml file (the changes I made are changing its first learned move from growth to tackle, and modifying its stat growth from levels 2 through 30). I didn't modify any other xml files. http://pastebin.com/3kW4mn1a

This occurs both on the 0.21a release version of statsutil, and the latest commit of statsutil compiled from source.

I am using Sky Editor's generic mod feature to patch the rom with the modified files, if it makes any difference.

Thanks for your hard work and research!

[PsyCommando]

Sorry for the late reply. I thought I was receiving notification from github, but apparently not...

You can always poke me at the PP forums or just post in the research thread to get a quicker response if this happens again : here

Anyways, it could very well do a big difference if you're using sky editor to patch, and combined it with a starter mod. What version of SkyEditor did you use? I know evan and I'll ask him if he ever heard of that.

The pokemon level-up data is stored in a single file named m_level.bin, under the BALANCE directory in the rom. Its completely separated from the rest of the pokemon data. Which explains why the exp for all pokemon is messed up.

But yeah, thanks for the feedback! I'll try to investigate this. I've been doing a big rework of statsutil lately, and I've had to deal with a major compiler bug in vs2015 specifically with statsutil.. So I'm right into it right now.

And glad you like my work! And again sorry for not seeing this sooner.. ^^;

[DeviPotato]

Hey! Thanks for the reply.

Here's what I found out after playing with it a bit. This might help you locate the issue.

It actually seems like statsutil doesn't correctly repack m_level. bin specifically. You can sort of see this in that the original m_level.bin is actually several bytes smaller than one modified with statsutil--I didn't really investigate the repacked file further than that, but you might find that useful as a starting point.

When I unpack the repacked file, shaymin's data /appears/ to be correct, so the file might be corrupted in some other way. The way the stat growths are calculated, the symptoms suggest that the entire level table is being treated as though it's all zeroes/null (which might just be the game dropping the improperly formatted table)

What I ended up doing was using your other utilities (which work great!), specifically packfileutil and unpx/dopx, to unpack m_level.bin and modify shaymin's stat growth directly using a hex editor (thanks for a well-documented wiki on that as well!) . Doing it this way worked flawlessly, and skyeditor correctly patches m_level into the ROM and my changes don't present these symptoms. Because it worked using this method, I don't think the problem is with skyeditor, but rather something to do with statsutil.

That's what I figured out with this issue. Hope that helps!

[PsyCommando]

Yep, this is a bug in statsutil. I could reproduce the bug on my end. It does it when simply repacking the m_level file..

I fixed it, it was something extremely dumb.. The sections of each SIR0 files weren't properly aligned on 16 bytes. So the game wouldn't seek and read properly through the data. Which explains why the file was readable by my tools, but not by the game.

One day, I apparently decided that my method of calculating padding length was too complicated for nothing(which it truly was for some reason..) But then, when I replaced it with something simpler, I had a huge brainfart and simply did "size modulo 16" to get the padding length... Which it wasn't at all..

So, in order to fix it, I simply replaced the line with an inlined function for calculating padding length that I'll just use everywhere instead of risking stuff like this to happen again..

    template<typename _SizeTy>  
        inline _SizeTy CalculateLengthPadding( _SizeTy length, _SizeTy alignon )  
    {  
        return ( (length % alignon) != 0 )? (alignon - (length % alignon)) : 0;  
    }  

It also handles the case when length%alignon == 0, so it doesn't just append 16 bytes whenever the length is properly aligned!

I think this might actually also affect some of the other tools in the master and dev branch. But I think most other releases are so old they shouldn't be affected, which is probably why you managed to do it with the other tools!

I'll try to get a fixed release of statsutil out as soon as possible.

And I'm glad you were able to get that sorted out on your own side! And thanks for the compliments! ^^ If you have any more feedback or even requests feel free to mention those!

[PsyCommando]

Ok, the issue should be fixed in this build : https://github.com/PsyCommando/ppmdu/releases/tag/ppmd_statsutil_0.22a

I ran some tests and it seems to be working in game.

[PsyCommando]

Closed since its been a while and it seems to be fixed.