It was pretty confusing.
I didn't even know where to look in the project.

Anyway, I found it.
The "bug" is that this is how AnimationState and Animation.apply is currently designed to behave.
I'm drawing it so Nate understands the problem at a glance.

Image removed due to the lack of support for HTTPS. | Show Anyway

I can't really offer much on my end to actually solve the problem for your setup except to hack away at AnimationState and AttachmentTimeline.apply so it suits your needs, or inconveniently key the attachment off in every animation that possibly comes after the animation that turns it on.

In the larger scheme, we know you particularly have many issues with AnimationState and Nate is aware of it too, as AnimationState in all runtimes has known issues and is due for updated logic: AnimationState improvements · Issue #621 · EsotericSoftware/spine-runtimes · GitHub

These use cases are informative.

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);
   }
}

It would be a with the current implementation, because when an animation is applied, all the state that is keyed gets applied.

Image your keys were for rotation instead of attachment visibility. At the black ? line, would you want the rotation for a or the rotation for c? If you want c, does it make sense for attachment visibility to work differently than rotation or other key types?

Another code change option would be to change AttachmentTimeline to only apply keys encountered since the lastTime. It's still a runtime change though.

You could make your runtime changes and save them as a Git stash. Then you could update your runtimes and apply the stash and you'd only have to fix up where there were conflicts, if any. I suggest SmartGit, which makes this easy: Repository -> Clone spine-runtimes, make your changes to the spine-runtimes files, Local -> Save Stash.

lastTime for attachment changes goes against how every other property is applied. The tracks are intended to be layered, with higher tracks overriding lower tracks. Track 0 is applied and configures the skeleton a certain way, then track 1 is applied and can override changes that track 0 did. Imagine if track 1 shows attachment a, then track 0 shows b for the same slot. When using lastTime then b would be shown. This results in track 1 not being able to override attachment changes in lower tracks (track 0), which goes against how we intended tracks to work.

I'm a bit confused why BinaryCats can't do what I did on my project.

[Track 0] - Major Body motions
[Track 1] - [ActiveWeapon] Start -> Loop -> Disable - [NextWeapon] Start - Loop - Disable
[Track 2] - Any instantaneous overrides

This way, Track 1 is keeping track of which attachments are currently running. I will confess, I did expect the ability to have a 'Sticky track' that could be written to which would allow any number of state changes to be instantaneously written and preserved, but in the end, this solution ended up looking and acting better.

???

Would it be possible for you to simply keep the track 'running' but not looping on Track 2?

It makes sense. Are you an independent contractor or a full-time dev at your studio?

BinaryCats wrote

Regarding the problem in the thread. once mixing starts, that previous animation is no longer playing. The Track entry name is the next animation's name, but keys are still being fed through from before the mix time.

I agree, in some scenarios it may be odd for attachment changes from the previous animation to be applied. If the new animation keys the slot, the new animation's attachment changes would override the previous animation. If the new animation doesn't key the slot, then whatever the previous animation does during the mix will stay that way. This makes sense in some cases, like maybe the attachment visibility changes are frame-by-frame images for a fan that should keep spinning during mixing and then stop one completely mixed out. I have a feeling both have use cases, so we need a TrackEntry setting so the behavior can be configured on a case-by-case basis.

Weeeee! 8)