- Editado
Please tell me required Re-Export won't happen again
To the best of my knowledge this has never happened between Spine updates or Spine.Unity updates. I'm willing to re-export hundreds of files maybe once, but only if I know there isn't plans to do this again anytime soon (or ever really). I realize I can still run spine and the runtimes in an earlier version, but I'd like to still be able to get quality updates like the new auto meshing and alpha masks. So ya, can you assuage my fears and let me know if updating right now is worth my time? Or, assuming this will become a thing moving forward, should I just stick w/ 3.7 and just revert my unity runtimes? Thanks!
That's what I wrote in my other thread too.. I only have 19 characters.. I can't imagine the pain when it gets up beyond that. Hopefully Spine team will come up with an automated function for future updates. Otherwise.. it'll be painful.
well like I mentioned I've been updating both spine and spine.unity for at least over a year now, likely closer to two, and this is the first time it has ever come up (I'm sure you have similar experiences). This update was fairly sweeping tho, so hopefully it is just a one time change associated with the overhaul a lot of the code took, and even more hopefully we can get some confirmation on that so we don't have to worry 
Yea. Well I don't mind the sweeping updates, but hopefully it'll be automated better in the future. 8)
Sorry, this will always happen. Compatibility is done at the Spine project file level. We do not attempt to have runtimes load data exported from all older versions of Spine. Doing that would complicate each of the many runtimes. It is much better to have that complexity in Spine and runtimes support only exports from the matching editor version. Spine can open projects from any older version. Considering there are many hundreds of Spine releases, this is not a simple task and not something that makes sense to put into 50+ runtimes.
If you have many projects, I suggest automating exporting your project files:
Export - Spine User Guide: Command line
For example, here is a script we use to export all the Spine example projects and to create texture atlases:
spine-runtimes/export.sh at 3.8
Nate escribióSorry, this will always happen. Compatibility is done at the Spine project file level. We do not attempt to have runtimes load data exported from all older versions of Spine. Doing that would complicate each of the many runtimes. It is much better to have that complexity in Spine and runtimes support only exports from the matching editor version. Spine can open projects from any older version. Considering there are many hundreds of Spine releases, this is not a simple task and not something that makes sense to put into 50+ runtimes.
If you have many projects, I suggest automating exporting your project files:
Export - Spine User Guide: Command line
For example, here is a script we use to export all the Spine example projects and to create texture atlases:
spine-runtimes/export.sh at 3.8
Hi @Nate,
Yea for sure understand what you mean. I personally prefer having both versions of Spine and Spine Unity Runtimes to be in sync. Just makes things less complicated.
The concern is more about having to re-export everything by hand. For me 19 animations is fine at my current production schedule, but for SoulKarl's situation, it sounds like a labor intensive task. I also might get to that amount of animations in a year or so. I would be crushed if I had to re-export everything when I'm days away from launch or a major milestone deliverable to my publisher.
I asked Harald in another thread, would it be ok to ask for some kind of batch project export function inside Spine? Only if enough people ask for it of course.
But so far it seems like just 2 people (including me) are affected by this update... So just ignore the loud minority I guess. :p
I'm still confused by this Nate, because up until now this has never once come up. Are you saying now moving forward it will always be like this? Or are you saying more along the lines of, it could happen again, similar to how it just happened now, but there could still also be updates that don't require complete re-exports? Thanks!
IndieDoroid escribióThe concern is more about having to re-export everything by hand.
It doesn't have to be done manually. You can and likely should automate it, which will be less work to export and less chance that something is exported incorrectly or is forgotten.
IndieDoroid escribióI would be crushed if I had to re-export everything when I'm days away from launch or a major milestone deliverable to my publisher.
You should never update a runtime or editor version without first being sure it works correctly for you and certainly never before a launch! Updating any dependency is a significant event and should be approached with caution.
IndieDoroid escribiówould it be ok to ask for some kind of batch project export function inside Spine?
You can have multiple skeletons in one project, then you would only need to export one project.
SoulKarl escribióuntil now this has never once come up.
Every single release that changes the binary format has caused exports from older versions to fail to be read by the newer release. The JSON format is much more resilient to changes. Often newer versions can load older JSON, but that is not guaranteed and many times in the past a re-export has been required.
I've been using spine since at least 3.5.19 (about 2.5 years ago i think?) and don't recall this coming up between then and now. I'm just more trying to make sure this won't be a per-update thing and is instead a rare occurrence similar to how it hasn't seemed to have cropped up in these last 2.5 years until this 3.8 update.
Also, you mentioned having multiple skeletons in one project in order to only need to export one project, but what would be the ramifications of having potentially hundreds of skeletons all under one file, both in terms of using spine itself and at runtime in unity? I had never considered this due to the size of some of my files, but if there's actually no cost to doing so this may be a reasonable solution to my problems.
We make changes to the JSON format only when we have to, eg it was required for skin bones and constraints. For changes that are only additive, previously exported JSON is usually OK. Exports in binary format are always invalidated for any change, but IMO that should not be a reason to avoid binary, you'd just need to setup automated exports.
Spine uses minimal resources for skeletons that are hidden. Having only one skeleton visible at a time is roughly the same as having them in separate projects. Saving and loading will take slightly longer, but should still be quite fast. When exporting, each skeleton results in a JSON or binary file, so at runtime the skeletons are all separate.
Thanks I think that answered my question. I'm fairly certain I always export to JSON which would explain why this is the first time I've had an issue.
Also wow I did not realize that on export it would separate them for me. It may be too much in terms of putting a FULL project worth of assets all into 1 spineProject, but I may start compartmentalizing stuff I normally kept separate, like all of the UI could be one file for instance to save me a lot of time should I need to export again. Thanks for all the help Nate!
No problem! :beer: Yep, exports result in one data file per skeleton. You'll also likely find it convenient to switch between skeletons when they are in the same file.
Nate escribióYou should never update a runtime or editor version without first being sure it works correctly for you and certainly never before a launch! Updating any dependency is a significant event and should be approached with caution.
Spine's always auto updated for me. I didn't realize I could go back a version via settings, after the auto update! Thanks for tipping me on this.
Nate escribióYou can have multiple skeletons in one project, then you would only need to export one project.
That is new to me! Hmm but would it make the work space a bit messy? 50 characters with possibly 10 different rigs? :think: