Esoteric Software

[Nate]

In case you haven't noticed the blog and aren't on the Kickstarter mailing list, please note that the export format has changed. See here for more information:
http://esotericsoftware.com/spine/cocos ... at-change/

Also note we are changing the default project file extension from ".project" to ".spine". The file extension is just a visual thing of course, you can name your files whatever you want, but we are doing this so we can have file associations start Spine.

There is one small piece of functionality this loses. Previously you could export an animation from skeleton A and import it to skeleton B. This would actually work if the skeletons had bones with the same hierarchy and names. You now import a whole new skeleton, you can't just import an animation to an existing skeleton. If we want to support moving an animation from one skeleton to another, we can add proper drag and drop support in the tree for doing this.

[Chounard]

So the spine-cpp runtime was completely removed in favor of the spine-c runtime?

[Nate]

Yes. It wasn't worth supporting a whole codebase when spine-c provides the same functionality. Actually spine-c has a number of improvements over spine-cpp and is easier to extend. It usually takes only ~250 lines of code to extend spine-c for a specific game toolkit, such as cocos2d.

[Chounard]

Sounds good. Just wanted to make sure I wasn't overlooking it. I'll swap it out in my code immediately.

[ammarz]

and I was trying to figure out why my animations aren't taking effect, until I figured out they're not getting exported at all so decided to come and whine about here!

[ArtizensAnimator]

Hey I got a little confused too when Spine updated it self.

But the format change does hinder our ability to export animations and then reimport them into a spine project, or between spine projects.

Anyone else having this problem?


edit: sorry just read your post, (as i should have !) but yes we definitely need to add proper drag and drop support in the tree for doing this!

[Lazrhog]

Time for a bunch of rework on my workflow

[Magnesus]

Well, the update should save me class fields I have for every different animation.

[Dan]

do these changes also apply to the binary format and if so has the official libgdx runtime been updated? I will need to review the changes and port them to the pascal runtime.

[Nate]

Lazrhog, how would your workflow change?

ArtizensAnimator, can you give an example of when you would want to move an animation to a different skeleton?

[Lazrhog]

Nate,

I had recoded the existing runtime in obj-c, but now there is no reason not to use the c runtime with obj-c

i use a custom gles2.0 shader for the sprites for speed, and i had incorporated texture packer very neatly too. runs real fast, did you see my video ?

[Nate]

Oh I see, I thought you were changing your workflow as a result of the export format change. Yep, saw your stuff, very cool!

[jb.tellez]

Hi Spine,

I'm trying to wrap my head around new workflow with these changes. On my team we have ~20 animations per skeleton, often worked on by separate designers. Previously an new/edited animation would be imported into the "master" file as they were completed and that worked fine. Now there is no more "import animation" option, only import skeleton with included skeletons. In my case we want to import just a certain animation. I'm not sure how to do that now. ArtizensAnimator - it sounds like you're facing a similar challenge, did you find a work around?
Thanks

[ArtizensAnimator]

Hey!
Yes, jb.tellez that's similar to the issue I'm having, and I havn't been able to find a work around yet.

I tried importing an older JSON animation file, but alas, it was not allowed!

It seems like we'll have to wait for Nate's magical fingers to code the Drag and Drop function in the animation Tree.

[gamebuilders]

I can see the benefit of using just one file for skeleton and animation data but couldn't this have been just an export option to combine the data into one file instead of eliminating the separation all together?

I haven't seen the new format yet but I would think it would just be a case of:

<file>
{ Bones [] },
{ Slots [] },
{ Animations [ walk { [...] }, jump { [...] }] }
</file>

[ArtizensAnimator]

Yeah it would have been a cool thing to be an option rather than cut off entirely.

I've got an older version of Spine working now, one that another of our team didn't open so it didn't auto-update. So I was able to export all my animations individually....But when you re-import the animation files, it loses the Spline Curves and the slot visibility!

Which is a bit of a problem to say the least.

How long do you think it will be before we can drag n Drop animations from one skeleton to another?

[Nate]

More options isn't better. Fewer options that still handle all the use cases is always better. I didn't want multiple export file formats, the simplicity of one file format was the whole point of the change.

Thanks for explaining your use cases. I see how you guys are using animation import to spread work across your team.

Import was implemented to allow data to be pulled into Spine from other tools. Eg, someone used this to migrate data from Spriter to Spine. Import wasn't intended as a way to move skeletons and animations from project to project or skeleton to skeleton.

I've implemented a new feature: Import Project. This allows a skeleton or an animation to be imported from a project file into your current project. This can be used in your workflow described above to pull animations into a "master" project.

Animations imported this way can be imported to a skeleton different from the one the animation was originally designed. This only works if the bones (and slots and attachments if keying slots or attachments) have the same names in both skeletons. If not, you will get warnings showing what could not be imported. Eg, try importing the dragon "fly" animation on top of Spineboy. Only the "head" bone is the same, the rest will give warnings. The import still works, it is just partial.

As a bonus, due to the way importing from a project had to be implemented, you now have "Duplicate" buttons for bones, slots, attachments, and skin attachments. Enjoy.

This new stuff is in v1.3.0+, available now. I tested it pretty thoroughly, but there may be issues. Always keep a back up of your data!

[jb.tellez]

Thanks Nate! My team will try out our "spread out" work flow with latest Spine and report back.

[ArtizensAnimator]

Thanks Nate!!
I've been using this for the last few hours and it's exactly what we needed.

Hope it's working for you jb too.

[chrismweb]

I'm a little worried about opening a project I haven't touched for a few weeks... There is no way to have archived versions of the editor? So if I have minor additions to an animation that hasn't been touched in awhile, it won't require redoing a lot of small/custom changes in the older runtime?

I could always block spine from internet access so that it will never update, but it might be nice to be able to use the older version, in case a quick update of the project might turn into a much longer update in the runtime too.

[Nate]

Old project should always be able to open with a newer version. Auto update is relatively new, there is no way to archive older versions of Spine. What you can do is click the cancel button when Spine is downloading a new update (you might need to be fast if you have a super fast connection). This will cancel the download and Spine will run with whatever version you had. You could also block Spine from the internet. But it's really best if everyone is running the latest version.

[terrymisu]

I have updated spine-python to take advantage of the new format. All of the examples for pyguts have also been updated.

There are tarballs on pypi.org and source on github (search for spine-python).

Cheers