Ok, wow, I guess the files are fairly big!

I'm probably more interested in the Spine animation files than the skins, but maybe I'll change my mind after I see them

Your videos on YouTube looked very interesting and as I have a platformer side project in mind, the animations probably would work for me.

I can let you know my thoughts after I get a chance to play with the animations/skins.

Yono

Yes, that would be great!

Thanks,
Yono

Just sent the money via PayPal from yono@toojuice.com

Thanks for being flexible!
Yono

Hi, do you have a way to sell the assets outside of the Unity Asset Store? I don't use Unity for my games and am not so interested in creating an account.

I second clandestine's sentiments!

Thanks for the info

I'd like to request a feature - version control within Spine. It would really help in situations where you have multiple people working on the same Spine files simultaneously.

This might be too complicated or not worth while, as there are ways around it, but I wanted to throw it out there.

On a related issue, if I were to version control the JSON exported data, is the output order of the JSON guaranteed to be the same each time?

Ok, admittedly this is a very bizarre bug and there is a work around. I also don't think it's doing any permanent damage to the Spine files unless the file is saved.

I have a skeleton setup, where some bones have multiple slots on them (for instance, bare foot, foot with shoe, bottom of foot, etc). These slots are switched during certain animations. I've found that, while an animation is playing that switches these slots, if I switch Spine files, it can corrupt the setup pose under specific circumstances. This corruption will NOT be permanent unless you save the file

which could happen if you're not paying attention.

To reproduce (you need a skeleton with multiple slots on a bone that are changed by an animation):

1) Open uncorrupted spine file
2) Switch to "Animate" mode
3) Play animation that includes switching slots for a bone
4) While the animation is playing, click the Spine menu and open a different Spine file (click continue without saving, if the option appears)
5) Play any animation in the new Spine file
6) While the animation is playing, click the Spine menu and open original Spine file
7) Setup pose will show the slots that were attached while the original animation was playing. This will now affect all other animations

WARNING: do not save

I have added a couple of screen shots that show 1) the original setup pose, 2) the corrupted setup pose, and 3) the configuration of the slots under one of the bones that exhibits this behavior.

Is the setup of the slots under the bone ok? Or is that causing this weird behavior? If necessary, I can send the whole Spine file, but would prefer to do so privately instead of publicly on the forum.

A faster way to reproduce this bug is to skip steps 4 & 5 and just reopen the currently open spine file. This is just less likely to happen during normal use, I thought

EDIT: The workaround is just to reopen the spine file with the corrupted setup pose while the setup pose is being displayed. If you haven't saved the file, it will show the original setup pose.

Actually, v3.2 is also using a fairly old version of the runtime. If you want to update to the latest, you can clone the git repository and replace the files in cocos/editor-support/spine/ with the ones from the spine-c AND the spine-cocos2dx runtimes. Then make sure that the files are added to the project.

Of course, silly me. My apologies.

I'm not sure if you are aware, but the runtime has evolved quite a bit since the stock version that came with cocos2d-x 3.0. For instance, IK support has been added since then. Additionally, the animation listener has been broken out into 4 listeners plus 4 track listeners (one for each type of event).

I tried to look at the runtime files in the v3.0 release and couldn't find why you would get those values sent to your animation listener. At first glance, at least, it looks like every time the animation listener is called with the ANIMATION_END event type, the event parameter is null and the loopCount is 0. event is only non-null, if type is ANIMATION_EVENT.

Is the spineboy.json you're using the one that ships with cocos2d-x, or with a more recent version of Spine? Or have you modified it? What I'm getting at here, is that you should double check that the animation has an Event timeline.

Which version of cocos2d-x are you using?

Did you check to see what type is? If it's not SP_ANIMATION_EVENT, I don't think event will be anything.

Very nice!

Yes, cocos2d-x has a built in way to do this. If you want to pause everything the character is doing you can simply use:

SkeletonAnimation *_character = ...

...

// pause
_character->pause();

// resume
_character->resume();

NOTE: this also pauses any actions being performed on the character. If you want to continue the actions, but just pause the animation, do this instead:

// pause
_scheduler->pauseTarget(_character);

// resume
_scheduler->resumeTarget(_character);

_scheduler is declared in the Node class, so all classes that inherit from it have access to it.

For a confetti explosion, a particle system would probably be a better way to go. Is there a reason you can't use a particle system in your code?

That sounds much simpler and cleaner than my proposed solution. Thanks, Nate!

Yes, I was looking into this. Unfortunately, since my code knows nothing about the animations that will be played (it's reading from a database and generating the on-screen content), hard coding a scale for a bone prior to transitioning is out of the question.

My next thought was to search the "to" animation's scale timeline for keyframes that don't match the "from" animation's scale timeline and where the graph used is a step graph, preset those bones to the "to" animation's scale. Does this sound reasonable? I've only started digging through the nitty gritty of the runtime to see how feasible/easy it would be to do.

I second the request for a screenshot/video! I would love to see how the effect turned out.