Ok, I was able to reproduce the bug with the death animation, where some frames aren’t correct / the animation doesn’t loop correctly (I wasn’t able to reproduce the problem with the misplaced items, though).
Here’s a PG that seems to work:
I’ve forced the death animation to play more often than the others in this PG, and I’ve also reset the animation to “idle” after 2s, so that it can be tested more easily.
Problems I spotted:
- it seems that the knight/rat death animation is one frame too long, and the mage/rogue animation is 3 frames too long. I’ve corrected the “to” value lines 346/350. You should check all VAT animations to make sure the range (from, to) is correct, there may be other animations that have this problem.
- when a VAT animation is looped, it is looped from
from+1, notfrom, to avoid artifacts. So, to loop the death animation over the last frame, we need to definetoFrame - 1andtoFrameas thefromandtoframes of the VAT vector, respectively. - The biggest problem was that setting
vat.time = 0at the end of the death animation caused all other animations in progress to jump to their first frame, instead of continuing their animation. Instead of resettingvat.timeto 0, an offset should be calculated each time an animation is started, so that the first frame calculated for the new animation is actually frame #0. To do this, we calculate the frame corresponding to the current vat time, and use as offsettotalFrames - frameCurrentVATTime(see lines 673-678). In this way, when the current frame is calculated for this animation at the next tick, the vat shader will calculate the current frame (which will be equal toframeCurrentVATTime) and add the offset, givingframeCurrentVATTime + (totalFrames - frameCurrentVATTime) = totalFrames. This corresponds to frame #0, as there is a modulus operation withtotalFramesafterwards.
I think this explains most of the changes I’ve made to the code.
Don’t hesitate to ask questions if something isn’t clear!