Possible BUG in Unity with JSON export

SuperDacapo

Hi!

We ran into a problem while trying to get a spine export to work in Unity, we ran into problems with Binary export (out of bounds), I will post a troubleshoot of it later if we cannot solve it.
So I wanted to validate that the problem is about Binary export and so we made a JSON export.

I kept getting error that "extension seems to be skel.bytes but content looks like json".
On a JSON export.
So I started digging.

SkeletonDataCompatibility.cs on line 91 has a check

bool hasBinaryExtension = asset.name.Contains(".skel");

which will always return true, as the filename is unity seems to always be ".skel", regardless if it's binary or json.

So I changed the check into

bool hasBinaryExtension = asset.name.Contains(".skel.bytes");

and it started working, well after I added the same change in two other locations at:
SkeletonDataAsset.cs line 166

bool hasBinaryExtension = skeletonJSON.name.ToLower().Contains(".skel");

and
AssetUtility.cs line 120

if (skeletonDataPath.Contains(".skel")) {

After these changes, the JSON import worked correctly.
However, it obviously breaks our earlier binary animation that we had, as it is not flagged as binary now.

We are using Spine 3.8.xx (have to check our animator which exact version he is using) and latest 3.8.0 unity plug in as of date of this post.

Our Unity version is 2019.4.25f1

The files in file explorer show them as "skel.bytes" and "skel.json".

EDIT:
I changed the code for now to check for naming convention for JSON, so we can work with JSON file and binary files. We'll just have to add "JSON" to the end of our work asset's name. It's not pretty, but works for now.

SkeletonDataCompatbility.cs line 91:
bool hasBinaryExtension = !(asset.name.Contains("_JSON")) && asset.name.Contains(".skel");

UtilityAsset.cs line 120:
if (!skeletonDataPath.Contains("_JSON") && skeletonDataPath.Contains(".skel")) {

SkeletonDataAsset.cs line 166
bool hasBinaryExtension = !(skeletonJSON.name.Contains("_JSON")) && skeletonJSON.name.ToLower().Contains(".skel");

Harald

While you can modify the spine-unity runtime to adjust to your custom asset workflow, we would rather recommend to try out the intended workflow and naming conventions first 🙂.

As the documentation page section Spine Unity Export for Beginners suggests, you should name your skeletons either with extension .json or .skel.bytes, not a mix of both:
spine-unity Runtime Documentation: Spine Unity Export for Beginners
spine-unity Runtime Documentation: Binary Export for Unity

SuperDacapo

Ah.

Thank you for pointing that out, I had a call with our artist and we went through the process. We had accidently included the ".skel" extension for JSON as well.

I would suggest that the Extension in Spine2D could be changed into dropdown list in order to reduce errors due to human mistake.
It was especially weird when this mistake led to Error messages telling us that "this JSON file is not a JSON file but it looks like a JSON file" 😃

Harald

SuperDacapo schrieb
I would suggest that the Extension in Spine2D could be changed into dropdown list in order to reduce errors due to human mistake.

Thanks for the input, we will consider that, or adding a check and issueing a warning upon export with the wrong extension. I'm afraid this will again lead to the universe producing humans even more capable of making errors. 😉

SuperDacapo schrieb
It was especially weird when this mistake led to Error messages telling us that "this JSON file is not a JSON file but it looks like a JSON file" 😃

It would really be confusing if it said .json three times :nerd:. It actually reads:

"Failed to read 'spineboy-pro.skel'. Extension is '.skel.bytes' but content looks like a '.json' file."

Unfortuantely the extension is not included in the asset.name string that we checked in the code by the Unity asset API, so this naming scheme was a creative way to slip through the checks. Your posted code changes from asset.name.Contains(".skel"); to asset.name.Contains(".skel.bytes"); in the first posting actually broke the line from working, as this statement will never be true. So in general we would advise you not to "fix" the code if basic things do not work, but instead having a look at the example scenes or documentation pages first.