Sorry Bcats, I'm not able to make sense of your image. I don't know what the red lines are or what the animations are doing.
Pharan's image makes sense. The previous animation continues to be applied as it is mixed out, so its attachment change keys are applied after the animation on track 1 changes the attachment. yookunka has the the same scenario except the slot's attachment is being set via code rather than a 1 frame animation.
To be clear, this is not a bug. The current behavior is that attachment keys are applied during mixing. Issue #621 has a potential solution (#12) going forward. If you want a code change solution for now, that is entirely possible.
What you want is to avoid applying any attachment timelines for the previous animation during mixing. AnimationState has this line to apply the previous animation:
previous.animation.apply(skeleton, previousTime, previousTime, previous.loop, null);
If you look at apply
, it's very simple:
public void apply (Skeleton skeleton, float lastTime, float time, boolean loop, Array<Event> events) {
if (loop && duration != 0) {
time %= duration;
if (lastTime > 0) lastTime %= duration;
}
for (int i = 0, n = timelines.size; i < n; i++)
timelines.get(i).apply(skeleton, lastTime, time, events, 1);
}
So, let's write our own apply function and call it instead of the previous.animation.apply
line, above:
applyPrevious(previous.animation, skeleton, previousTime, previousTime, previous.loop, null);
...
private void applyPrevious (Animation animation, Skeleton skeleton, float lastTime, float time, boolean loop,
Array<Event> events) {
float duration = animation.getDuration();
if (loop && duration != 0) {
time %= duration;
if (lastTime > 0) lastTime %= duration;
}
Array<Timeline> timelines = animation.getTimelines();
for (int i = 0, n = timelines.size; i < n; i++) {
Timeline timeline = timelines.get(i);
if (timeline instanceof AttachmentTimeline) continue; // No attachment changes.
timeline.apply(skeleton, lastTime, time, events, 1);
}
}