...wow. Just all I will say is "wow". Still haven't found the cause of the animation bug, but I did find this:
for (unsigned int i = 0; i < m_Directions.size(); i++)
if (strcmp_ci(direction.c_str(), m_Directions[i].name.c_str()) == 0)
{
d = i;
// stop immediately.
i = m_Directions.size(); // <-- wtf
}
Traditionally most people early-terminate a
for loop using a break statement...
Edit: Here are the results of my tests: COMMAND_ANIMATE seems to work fine. Your Blockman sprite has a delay of 4 on each frame, so I did the following:
SetPersonSpriteset('robert', LoadSpriteset('blockman.rss'));
for (i = 0; i < 5; i++) for (j = 0; j < 4; ++j) {
Console.writeLine("Frame: " + GetPersonFrame('robert'));
Console.append("i = " + i);
Console.append("j = " + j);
FlipScreen();
QueuePersonCommand('robert', COMMAND_ANIMATE, false);
UpdateMapEngine();
}
It correctly cycled through all the frames (originally there was some log output here but it was a waste of space). Sphere 1.5 was somewhat odd as it stayed on frame 0 twice as long the first time around (8 frames instead of 4), but otherwise cycled through all 5 images as normal.
Are you sure your issue wasn't with SetPersonFrame() and not COMMAND_ANIMATE? Because that was the only difference I could find between 1.6 and minisphere, minisphere's SetPersonFrame wasn't resetting the animation frame counter.
Edit 2: Yeah, it was SetPersonFrame. Sphere 1.5:
m_Persons[person].frame = frame;
Sphere 1.6:
m_Persons[person].frame = frame;
m_Persons[person].stepping_frame_revert_count = 0;
m_Persons[person].next_frame_switch = p.spriteset->GetSpriteset().GetFrameDelay(p.direction, p.frame);
1.6 resets the frame counter when the frame is set explicitly, 1.5 doesn't. minisphere follows the 1.6 implementation now.