Hi there

I have a related problem:

After updating the runtime all animations of images did not work anymore. I used to use the same value for Animation.apply 'lastTime' and 'time'.
I fixed it by using -1 for 'lastTime'.

But I could not solve my second problem:

I run two animations with AnimationState on track 0 and 1:

_dragonState.setAnimation( 0, _wingFly, true ); //always flying
_dragonState.setAnimation( 1, _wingBreak, false ); //break from time to time

If both animations have keyframes for the same attribute (like 'scale' or 'translation'), the one of the animation on track 1 "wins". Even if there is only one keyframe, it's state will remain as long as the animation on track 1 runs. right?

So far so good.

But since the last runtime update this is not true for animated images (changing the attachment image of a slot) anymore. The keyframes of both animations seem to be considered: Setting a keyframe on the animation on track 1 will be overwritten by the animation on track 0! (which in my case causes ugly flickering between the both animations)

Is this behaviour intended?

Both the problems above are caused from this change:
https://github.com/EsotericSoftware/spi ... 51ee82L487
The issue that triggered the change is here:
https://github.com/EsotericSoftware/spi ... t-42985905

Sorry that diff is hard to read. The idea is to set the attachment only when the attachment key is encountered. Previously it would set the attachment every frame, using the last attachment key found before the current time. I can see now this can cause an issue when animations are on different tracks and you want the top most one to override image keys on the bottom one.

I would like to avoid calling skeleton.getAttachment every frame, which does a map look up. If someone keys every image on a skeleton, this causes that many map look ups every frame, which could be a lot. I will give it some more thought.

Thanks nate for the reply and for thinking over the issue again! The issue link is very interesting.

Ok, it's a feature, not a bug... hmm... in my opinion the lack of overriding of image keyframes is inconsistent.

I must confess that I use spine mostly for image-animation which is not the main purpose of spine. So if I am the only one who complains, I'll find my own solution (write my own AnimationState or fall back to the old runtime).

However I can imagine a lot of situations, where the same problem will appear:

Whenever you have "standard" loops and individual short animations which both affect the images of the same slot, for example:

• a flapping cape (or hairs or beard,...) while running, which moves up or down when jumping.
• a little computer display which runs a noise loop, but sometimes an icon
• whenever you have little characters which aren't worth to be animated by bones like little helper animals on the shoulder of a character