Credits to @AlfredKamon for discovering this. From some testing that he and I have done in regards to expanding the number of classes you may have, it seems that there may be a “cap” on the maximum amount of standing map sprites. It seems you may only have up to 128 standing map sprites. In other words only indexes 0x00 through 0x7F are valid for standing map sprites. Using a standing map sprite with an index over this value will cause the map sprite to not load/it seems to load a broken version of which ever map sprite would come next if the array looped around. So using index 0x80 for a standing sprite causes a broken version of entry 0x00 to load instead.
Moving map sprites do not have this “cap.” This has only been tested in FE8, but I imagine this holds true in all FE games, possibly explaining why FE8 removed so many map sprites from FE7/why some classes share map sprites.
For reference, to my knowledge there are at least 165 standing map sprites publicly available in the community at the moment(this includes custom ones found in the FEU thread). For those of you planning to take advantage of Icecube’s class expansion patch, keep this in mind.
Setting all those addresses from 7F to FF at least fixes the loading problem that occasionally popped up, but animations don’t play(so it only loads one of the three standing frames and sticks with that one frame). Also anything beyond entry 0xD0 seemed to load either the top part of the… next map sprite a unit on the same team had? The entries at 0xE0 or higher just loaded the whole map sprite of said team unit.
By all possibilities do you mean that some of those offsets may not have to be changed to 0xFF?
@Blademaster: Found the problem. Changing 26A52 to 2000 fix the animation problem (IMO, that’s the problem. The point is to make r1 = 1 to execute the animation). @MisakaMikoto: What ROM is it? AFAIK, 25C48 is 00 28 1E D1 (FE8 US)
@Icecube I’ve edited all of those to FF and wrote 2000 at 26A52, but it still isn’t working.
I’m using the standing sprite 0x88, and it just loads a… shadow, I think?
I tested according to my discovery and found that even if I broke the limitation there was a glich like what @Blademaster said, and then I found that: the highest bit of index is not useless as you imagined. In fact, it determines whether the animation can play: 1-cannot, 0-can. I know it may sound absurd but you can do a simple test to find it out yourself. To conclude, the highest bit is a control bit, while the least 7 bits are index bits.
@Icecube Nevermind, it works now!
I’ve double checked it and it seems I had missed one of the offsets before, since I was in a hurry.
Huge thanks, icecube!