• RuntimesUnity
  • Two animations at once minor issue.

Erika There are no hurt eyes, legs or otherwise. The hurt animation is a single sprite that is shown. The Rigging new poses tutorial is nice, I will keep that in mind. Thank you for it.

Harald The track index is already being used the way you describe:

All animations are at default played on track 0, while hurt is played on track 1, which also shows on the screenshot I provided, since the attack attachments is behind while the hurt sprite is in the front. That the keys in that higher track animations overrides the ones in a lower track animation seems not to be true, but you might refer to another function than SetAnimation.

Option A have been tried. As said in my last sentence, every frame has the attachments disabled, keyed and all, which to my bafflement didn't work either.
Option B fixed the issue! I didn't think of this, thank you very much.

    Related Discussions
    ...

    JonathanAndersen That the keys in that higher track animations overrides the ones in a lower track animation seems not to be true, but you might refer to another function than SetAnimation.

    No, I do refer to animation blending via AnimationState.SetAnimation()

    JonathanAndersen Option A have been tried. As said in my last sentence, every frame has the attachments disabled, keyed and all, which to my bafflement didn't work either.

    Then something with your animations or attachments must be set up incorrectly.

    You can send us a minimal Unity project that still shows the issue if you like. You can send it as a zip package to contact@esotericsoftware.com, briefly mentioning this forum thread URL so that we know the context. Then we can have a look at what's going wrong.

      Harald Then something with your animations or attachments must be set up incorrectly.

      Could be. The project contains as said 11 skins, with bones and attachments in each of them.

      I will take up your offer and send a small snippet of the project centered around the issue. I have already send an email to the email address, together with the spine project.

        JonathanAndersen Do note that the spine project is already set up with the new solution of changing color opacity during the hurt animation. So importing that file will fix the issue.

        @JonathanAndersen Thanks for sending the reproduction project. We will get back to you here on the forum once we've figured out what's going wrong.

        @JonathanAndersen The problem was that you've enabled Animation clean up. As I've mentioned before:

        Harald Also be sure to disable Animation clean up in your export settings, otherwise keys identical to the setup pose will be removed.

        I guess you've missed those lines in my previous posting 🙂.

          Harald cleaning the animation only removes the last row of keys in the hurt animation. I didn't miss those lines either, as I do still get the same issue even when I uncheck the "Animation clean up" in Export, which is why I didn't regard it.

          Did you remove the color opacity keys I had set in the Hurt animation before exporting it?

            Also I meant to say column and not row.

            JonathanAndersen Harald cleaning the animation only removes the last row of keys in the hurt animation. I didn't miss those lines either, as I do still get the same issue even when I uncheck the "Animation clean up" in Export, which is why I didn't regard it.

            It behaves differently on my Spine Editor installation than what you are describing. Using either Animation clean up during export, or Clean Up when selecting the Hurt animation in the tree view both deletes the required key of the attachment Eyes closed (which is identical to the setup pose, thus removed). You can see the screenshots:

            Before Clean Up:

            After Clean Up:

            Are you perhaps using an older 4.1 version of the Spine Editor? There might have been a bugfix which makes it work as expected on my installation while not behaving correctly on yours.

            JonathanAndersen Did you remove the color opacity keys I had set in the Hurt animation before exporting it?

            Yes.

            BTW: From your skeleton setup I can see that your usage of slots seems not quite as intended by design: You have separate slots Eyes, Eyes Angry, Eyes Angry2 and Eyes Closed with one attachment each, which seem to be exclusively showing only one at any time. If they are indeed exclusive, you could be using a single slot Eyes and have multiple attachments (or skin placeholders) under it for Eyes, Eyes Angry, Eyes Angry2 and Eyes Closed. This could automatically save you any issues with forgetting to disable all but one attachment, since only one can be active under a single slot anyway. Also programmatically, you could access a single Eyes slot and set its color, instead of setting colors of four or more slots, where the code or components needs to be updated when new slots for eye states are added.

            You can check out the other Spine example projects for reference like Spineboy, where there is one slot mouth with three attachments mouth-grind, mouth-oooo and mouth-smile.

              Harald It behaves differently on my Spine Editor installation than what you are describing. Using either Animation clean up during export, or Clean Up when selecting the Hurt animation in the tree view both deletes the required key of the attachment Eyes closed (which is identical to the setup pose, thus removed). You can see the screenshots:

              Which is exactly what I said: cleaning the animation only removes the last row (column) of keys. The only difference is that the color keys are still in your screenshots. However, I might misunderstand the application here: if the first column that disables the attachments exist, but the last column doesn't, can another animation then during its duration overwrite that even if it's on another track? Because the columns are identical, and as far as I'm concerned, as long as the first one goes through, it should be fine.

              Harald BTW: From your skeleton setup I can see that your usage of slots seems not quite as intended by design: You have separate slots Eyes, Eyes Angry, Eyes Angry2 and Eyes Closed with one attachment each, which seem to be exclusively showing only one at any time. If they are indeed exclusive, you could be using a single slot Eyes and have multiple attachments (or skin placeholders) under it for Eyes, Eyes Angry, Eyes Angry2 and Eyes Closed

              This has been due to both the draw order hierarchy, skins and editions wished by the game designers, and I should indeed be better organizing that, its definitely something that can be tightened up. Thanks for pointing it out, however that is not the issue I request assistance on.

              Key point is: uncheck clean up haven't worked in fixing the issue, for me at least and our programmer, but the color opacity change have, which you do still have in your screenshots.

              I wanted to dig a little further to get more knowledge of the issue, but I do feel guilty of taking much of your time and patience already. If furthermore, consider the issue solved by your suggested solution of changing color opacity, which I thank you very much for.

                JonathanAndersen Which is exactly what I said: cleaning the animation only removes the last row (column) of keys.

                From your wording I think you didn't understand at all what I was pointing out above.

                I was talking about the entirely missing key row of Attach: Eyes closed. It's present in the first screenshot, but was entirely removed in the second screenshot after cleanup. I was not talking about the last two removed columns, please read my text carefully again:

                Harald Using either Animation clean up during export, or Clean Up when selecting the Hurt animation in the tree view both deletes the required key of the attachment Eyes closed (which is identical to the setup pose, thus removed). You can see the screenshots:

                This removed key is causing the problem, after having been removed by animation clean up, I see a leftover enabled attachment "Eyes Closed" in the Unity project. Without this key being removed, the attachment stays disabled as desired in Unity (and it's not just colored transparent with alpha=0).

                JonathanAndersen The only difference is that the color keys are still in your screenshots.

                That's not what the screenshots are about. They show your problem of the removed last row of keys.

                If you think that I didn't remove the color keys: I removed them from the exported .json file, not from the Spine project. And before you ask: I also verified in two ways in Unity that the attachments are disabled (via the Skeleton Debug View and by viewing the mesh). Please always carefully read the words that I write what you should look at in the screenshots.

                JonathanAndersen However, I might misunderstand the application here: if the first column that disables the attachments exist, but the last column doesn't, can another animation then during its duration overwrite that even if it's on another track? Because the columns are identical, and as far as I'm concerned, as long as the first one goes through, it should be fine.

                I'm not quite sure what you mean with the above sentence. Keys on higher tracks overwrite lower track's keys, no matter how many times the same identical state is keyed on a single track, or how long ago that was.

                JonathanAndersen This has been due to both the draw order hierarchy, skins and editions wished by the game designers, and I should indeed be better organizing that, its definitely something that can be tightened up. Thanks for pointing it out, however that is not the issue I request assistance on.

                I'm fully aware that you didn't request assistance on that. If you're aware that better ways exist, that's fine. It just looked as if the basic principles were not understood, which leads to more time spent on problems from both the user's and our side, which I would like to avoid.

                JonathanAndersen Key point is: uncheck clean up haven't worked in fixing the issue, for me at least and our programmer, but the color opacity change have, which you do still have in your screenshots.

                Did you update the Spine Editor to 4.1.24 and retry exporting with Animation clean up disabled? It would be very strange if the same version works as intended on my machine and not on yours.