Spine Integration Issue: unable to remove attachment

Hello,
I’m using cocos2d-JS with both WebStorm and the CcosIDE to create a simple game.
One of my scenes has an avatar that is generated using a Spine skeleton, which is provided by the Spine runtime.

I’m trying to remove an attachment from a slot by setting it as null :

this.skeleton.setAttachment("SlotName", null);

The code works fine when I test the app with Webstorm through a browser, but when I run it
with the CocosIDE on an emulator (win32 or Android) I get the following error:

Error: js_cocos2dx_spine_SkeletonRenderer_setAttachment : wrong number of arguments

I’ve already tried to set the attachment to 0 instead of null, as it was suggested in Show/Hide bones or slots in animation. That way I don’t get the error but the attachment is not removed.
After some further testing I’ve found that if try to access a slot by using the method skeleton.findSlot(slotName) the whole app crashes.

Anyone who has experienced something similar or has worked with spine skeletons knows what am I doing wrong?

EDIT (1):
I’ve found a temporary solution to my issue.
Instead of setting a node’s attachment to null I’m setting it to a transparent attachment that I’ve previously created and added to the skeleton.json and skeleton.atlas files.
Now I can “remove” an attachment by simply setting it to the transparent one :

skeleton.setAttachment("SlotName", "transparentAttachmentName");

The only thing to keep in consideration is that the transparent attachment must be set in the skeleton.json file for every slot that may need it.

1 Like

If i remember well, setAttachment with null didn’t work for me either ( in c++)

So i did this:
spSkeleton_setAttachment(skeleton->getSkeleton(), “head”, 0);

Not sure if you can do it in js.

@milos1290
First of all, thanks for your suggestion.
Unfortunately it doesn’t seem to work in JavaScript :pensive:
this is how I tried to implement your C++ fix in my code:

this.skeleton.setAttachment(this.skeleton.getSkeleton(), "Hats", 0);

but i get the same error generated by setting the attachment to null.
I’ll guess I’ll stick with the transparent “fix”.