Binary runtime compatibility

Majicpanda

"Runtimes cannot load exported binary file versions that are newer or older than the version it supports."

I hope I'm wrong on this.. but is this saying that every animation in our game has to be re-imported when we update the spine unity runtime? I just upgraded from 3.2.01 and just get a bunch of "error reading skeleton JSON file for ..." errors.

With dozens of animations that would become a major issue having to re-export everything, so I hope I'm missing the verbiage of that message.

Majicpanda

Pharan

That's right, especially between 3.2 and 3.3. That was a major change architecturally that even jsons have to be re-exported.

Normally, when you use json, you're pretty safe across version bumps even with added features.
But binary will always change with every added feature. This has been the case since the 2.x days.

I think the expectation is that you set up a sensible command line batch to export all your spine projects.
Export - Spine User Guide

Majicpanda

Do you guys not suggest binary except for extra large animations? It cut our loading time by quite a bit when I changed to binary when loading in the entire scene, but there are other ways we can load the scene like area of influence that would help more.

22 Aug 2016, 13:54

A super helpful way to do this would be if every import took the settings for that specific spine file and used it during the export.. meaning all you had to do was pass the input .spine file and it would just perform an export just as if you were going to click Export from the drop down menus in the GUI.

Something simple that just allowed us to do:

For /R "C:\RootAnimFolder" %%G IN (*.spine) do ( 
   

   "C:\Program Files (x86)\Spine\Spine.com" -i "%%G" )

Otherwise we have to create a really strict folder structure, read the current folder name and export to unity directories hoping no one spelled anything wrong etc.

Pharan

Sure, large animations are the primary use for binary. We totally recommend that.

What we don't recommend is updating your runtime for new features right before you need to ship, 'cause it takes an unknown amount of extra work on your end.

I'll show Nate your suggestion.

But I think he'll still recommend saving an Export settings file (json) per project.
That allows you to just edit the text in that json so you can change the input/output paths or adjust the export settings, instead of having to open each spine project in case something changed. It's an upfront cost if you weren't doing it already for sure, but saves time down the line. Not sure if that's a perk for you.

I'm also not sure what export settings projects actually store. But I'm sure path typos aren't a problem if you don't actually type them manually.

Unless you're a mac... Can you copy paths as text in OSX?

Majicpanda

Ah ok I think I misunderstood the json settings file.. I don't yet have one at all and now understand how to save it. The main problem would be if some assets are not the same export settings it would just be a mess to deal with all of the differences like scale (really the only difference so far).

If the settings are baked into the .spine file (assuming so) then yea... that could pose some major problems with my suggestion unfortunately.

So really, we don't need to do all this nonsense of finding all the .spine files like I did.. we just put all the export files in 1 folder and call Spine.com -e over all the json files?

If there's actual image updates I'll just manually do those, this is really just for when we update Spine and have to then update all 200 animations in the game.. even far from release that's a small kick in the pants 😉

Pharan

I think there are two kinds of export settings json files:

Texture Packer export settings json, and
Spine Project export settings json (which also happens to include texture packer settings).
The one you want is the second one. You don't need the first one.
I was a bit confused about it myself at first.

But yeah, if you have all those export json files (one for each spine project), then you can just call Spine.com -e for those.
It sucks that the paths have double-slashes though. I'd better complain to Nate about that. 😃

EDIT:
My bad. Paths don't actually need double slashes. Seems to be a quirk of auto-generated paths.
At least in Windows, you can either use "\" or "/".

Majicpanda

Thanks as always for the quick responses. Glad we caught this early, I've just changed our workflow to upload 2 versions of the .spine file.. One the artist can use like spider_v14 for reference to know what's latest uploaded and simply spider.spine so that the exported json never breaks and we are all one big happy family 😉