• Runtimes

  • Swapping skins swaps all attachments/slots EXCEPT type: mesh

We're using pixi-spine.

We set a skin like the following:

skeleton.setSkin(null)
skeleton.setSkinByName('harold')

Thus we see our whole character. However, if we try to change to a new skin that overwrites all attachments/slots, like so:

skeleton.setSkin(null)
skeleton.setSkinByName('bob')

All regions update to display what we see in the spine editor when we click that skin, EXCEPT slots that are of type "mesh" or of type "linkedmesh." For example, the color of the mesh will show RED for 'bob', and BLUE for 'harold', but if we switch from harold to bob, the mesh stays blue instead of changing to red.

Not sure what's going on here, how can we swap over meshes as well?

Related Discussions
...

Cheers, badlogic. We've experimented with that as well, but we're not clear on what "set base attachments" means. Where do we define "base attachments?"

Furthemore, adding the skeleton.setSlotsToSetupPose() invocation doesn't solve the issue with meshes, unfortunately.

Actually, I forgot - on the note of skeleton.setSlotsToSetupPose(), if we try to do something that only touches some of the slots, i.e. add pants to our character, it nukes the rest of the avatar and only shows the pants... but keeps animated, hilariously. Perhaps this is because we don't understand how to set base attachments?

Based on this thread: Problem with SetSkin() to change skin at runtime (Unity) I've also experimented with mucking about with the setSkin function, like removing the final null checker and etc. That does... very strange things to the animations, but we're running out of things to try to get this working.

The problem was that our assets were using PATH, rather than NAME, to find their assets.

Both will "show properly" in spine, but only one is the "right way" to do things in the spine editor to have things work right in the runtimes (as evidenced by issues like this).

I'm not fully clear on exactly what that looks like in the editor or how to explain it, but our designer will have a more detailed run down of what caused this issue sometime this week.

Thanks for your help.