IIRC a while ago, it seems to be hit and miss on whether these worked or not. I have a case where I need to play an animation (on track >=1, as track 0 is changing) I have stepped through, and the animation gets added to the correct track. I added break points to check that it wasn't being removed (via clearTrack), When I did this the attachment disappeared!

-however it reappeared the frame after. Although the animation on track 1, does key the attachment on, it is on frame 0, and no keys exist anywhere else.

Pharan wrote

I had to look up "IIRC".

Did you keep track of the value of slot.attachment? (as opposed to what the render looks like)
It may be useful so we know if it's the underlying spine-csharp that's misbehaving, or the spine-unity renderer.

the physical render of the spine object, As I 'continue' the code after a break point, the next frame* it hit another break point (setting animation on track 0) at which point the attachment was not visible. then, on the next `continue of the code and breakpoint hit' the attachment was visable again.

This repo's 100% of the time, so I will see if I can look at the slot's value

*I assume, previously animation current time was -1. now it is 0f, the length of the animation is also 0f

I forgot to say the rest of mny IIRC sentence :rofl: :bang: , iirc a while ago, this was a thing

I have isolated the problem:

Here we can see the slots turn off and on (which will get undone)(taken from attachmenttimeline apply)

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

And then the next frame It plays the previous animation from the code in animation state:

public void Apply (Skeleton skeleton) {
         ExposedList<Event> events = this.events;

     for (int i = 0; i < tracks.Count; i++) {
        TrackEntry current = tracks.Items[i];
        if (current == null) continue;

        events.Clear();

        float time = current.time;
        bool loop = current.loop;
        if (!loop && time > current.endTime) time = current.endTime;

        TrackEntry previous = current.previous;
        if (previous == null) {
           if (current.mix == 1)
              current.animation.Apply(skeleton, current.lastTime, time, loop, events);
           else
              current.animation.Mix(skeleton, current.lastTime, time, loop, events, current.mix);
        } else {
           float previousTime = previous.time;
           if (!previous.loop && previousTime > previous.endTime) previousTime = previous.endTime;
           previous.animation.Apply(skeleton, previous.lastTime, previousTime, previous.loop, null);

When this happens

int frameIndex = (time >= frames[frames.Length - 1] ? frames.Length : Animation.binarySearch(frames, time)) - 1;

returns 0. So despite The previous animation being 30 frames long, it plays the first frame, which is the frame the attachment get turned on.

time = 1f
frames[frames.Length - 1] = 0
frames.Length = 1

And here is the timeline where it turns it on

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

15 Jun 2016, 08:05

so... is this being looked into or?

23 Jun 2016, 16:52

I FIXED THIS by clearing the track before playing the animation. However I can not do this due to other reasons, hello@

That is correct @[deleted]

Animation 1: turns an attachment A on (20frames)
Animation 2: Does other stuff (20 frames)

Animation 3: Turns attachment A off.

I play animation 1. - keys the attachment on frame 0 - track 0

10 frames in:
Interrupt track 0. with animation 2
play animation 3 on track 1

attachment A stays visable.

24 Jun 2016, 09:37

Soo, I isolated the bug, and was planning on sending it to you.

However, I was unsure how to export just a scene rather than the whole project. So I made a new project with the latest stuff. And it doesn't happen! It is either the old runtime, or the modifications to that runtime that has caused this :sweat:

24 Jun 2016, 09:53

:doh: :angel: :clap: it is not our changes. this must have been fixed in the newer versions of spine

Nate wrote

There is no bug? My favorite kind of bug! :clap:

there was a BUG! IN THE past, you got lucky (punk) with new runtimes

06 Jul 2016, 14:26

Nope. I was wrong! it still happens.

What do you need from me to help investigate this issue.

I cant get the bug to happen when break pointing now, so I'm stuck with debug logs,

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

Here I have one animation running, Attack_Knife_intro (60 frames track 0). Then I interrupt that animation (I damage the character) and it plays an animation TakeHit_Upper ( 30 frames track 0). On the same frame, I play animation Attachment_Knife_Off (1 Frame, track 1)

Attack_Knife_intro Turns Attachment knife_a ON, in slot WeaponA - first frame.
TakeHit_Upper DOES NOT ALTER slot WeaponA, At all.
Attack_Knife_intro Turns Attachment knife_a OFF, in slot WeaponA - first frame.

The above image shows the following, the current anuimation playing (_anim_) and any time an attachment is set, in the format slot: current image to new image currenttime

06 Jul 2016, 14:45

I have repo'ed it in a project using latest unity runtimes and goblin-mesh (altered)

It uses the script animationstuff to handle playing of animations,

https://drive.google.com/file/d/0B5ElW0WUt28eMG1UWlgtTGFoUXM/view?usp=sharing

06 Jul 2016, 14:54

its in the goblin scene

06 Jul 2016, 16:50

I have narrowed down the problem to

previous.animation.Apply(skeleton, previous.lastTime, previousTime, previous.loop, null);

line 119 Animation state. bug is fixed by removing it.

However, I am unsure why this line even exists. All this does is play the previous animation.

Take the attachment time like (only visable one causing a problem)

public void Apply (Skeleton skeleton, float lastTime, float time, ExposedList<Event> firedEvents, float alpha) {
   float[] frames = this.frames;
   if (time < frames[0]) return; // Time is before first frame.

   int frameIndex;
   if (time >= frames[frames.Length - 1]) // Time is after last frame.
      frameIndex = frames.Length - 1;
   else
      frameIndex = Animation.binarySearch(frames, time, 1) - 1;

   String attachmentName = attachmentNames[frameIndex];
   skeleton.slots.Items[slotIndex]
      .Attachment = attachmentName == null ? null : skeleton.GetAttachment(slotIndex, attachmentName);
}

for any timelines' frame < current time, it will apply it. However, this does not account for the current state of the attachment. I.e. if another track has turned it off.

I have noticed that you don't check the timeline's frame time against lastTime. Is this so it never misses an attachment keyframe?

06 Jul 2016, 17:05

I changed the code to:

public void Apply (Skeleton skeleton, float lastTime, float time, ExposedList<Event> firedEvents, float alpha) {
         float[] frames = this.frames;
         if (time < frames[0]) return; // Time is before first frame.

     int frameIndex;
     if (time >= frames[frames.Length - 1]) // Time is after last frame.
        {
            if (lastTime >= frames[frames.Length - 1]) // you missed your chance 
                return; //now bugger off
              frameIndex = frames.Length - 1;
        }
        else
        frameIndex = Animation.binarySearch(frames, time, 1) - 1;

     String attachmentName = attachmentNames[frameIndex];
     skeleton.slots.Items[slotIndex]
        .Attachment = attachmentName == null ? null : skeleton.GetAttachment(slotIndex, attachmentName);
  }

It works, but I am unsure what knock-ons it will have.

Nate wrote

We recently changed back to always setting the attachment rather than using lastTime. This allows 2 tracks to key attachment changes and the higher track wins since it is applied last. If we checked lastTime to trigger the attachment change then the most recent track to set the attachment wins, which doesn't make sense as the higher track wins for all other types of keys.

So what is the solution here?

Maybe it should just ignore the attachment timeline when mixing (I assume that's why you are doing previous.apply)?, or it should not apply any keys before the mixing happened?

Nate wrote

If we checked lastTime to trigger the attachment change then the most recent track to set the attachment wins, which doesn't make sense as the higher track wins for all other types of keys.

I am unsure what you mean by the most recent track to set the attachment. If you mean that the most recent attachment-key to be fired( regardless of what track it is on ) to be applied, this is what you want... isn't it?

Nate wrote

BinaryCats, honestly I'm still not sure what problem you are having. I need it to know 1) what you are doing, 2) what actually happened, and 3) what you expected to happen. If you can do that as concisely as possible that would help. If you leave out any of those, it is hard to guess at the problem and then confusing if I guess wrong.

BinaryCats wrote

I am unsure what you mean by the most recent track to set the attachment.

Track 0 is applied, then track 1. If both key an attachment, track 1 will be the most recent track to set the attachment.

....
I Have provided a download link to a unity project and provided the spine file which has isolated the bug.

I will try to make it clearer when I get home (although I think I have outlined it in its simplest form)

07 Jul 2016, 19:49

If you have an animation playing that keys on an attachment in a slot, then interrupt that animation (by setting an animation on the same track) and simultaneously play an animation on a different animation that keys off THAT SAME ATTACHMENT, IN THE SAME SLOT. The attachment will turn off for ONE FRAME, then the next frame That attachment, due to mixing, will be keyed back on. Even if it happened a long time ago.

The attachment should remain off. Attachment keys outside of the mixing time SHOULD NOT have a say on if a slot is turned on or off.

07 Jul 2016, 19:52

I think: One Frame Attachment Animations explains it pretty well in a step by step