Updating Spine 4.0.0 to Latest

lucky

Hi there,
We're currently in the process of looking to update spine and all of our animations with it from using 4.0.0 runtime to the latest 4.2 package.
We wanted to ask, should we update the runtime from 4.0 to 4.1 and then 1 to 2 ,or is it safe to directly swap from 4.0 to 4.2 .

Or if there are any things to be aware of outside of the update notes here.
I can only see the how to update 4.0 to 4.1 on the forum here, which we'll use as a guide 🙂

Thanks for your time

Spinebot

To update from Spine 4.0.0 runtime to the latest 4.2 package, it's generally recommended to follow the upgrade guides sequentially to ensure compatibility and to address any potential issues that may arise during the update process. This means you would first update from 4.0 to 4.1, following the guidelines provided in the Spine-Unity 4.0 to 4.1 Upgrade Guide, and then proceed to update from 4.1 to 4.2, adhering to any specific instructions or notes provided for this transition.

It's important to back up your project before starting the update process to prevent any potential data loss. Additionally, you should re-export your Spine projects with the corresponding Spine Editor version to ensure compatibility with the updated runtime. Be aware that there might be changes in the API or functionality between versions, so reviewing the CHANGELOG.md and any upgrade guides thoroughly is crucial to identify any adjustments needed in your project.

While direct updates (skipping intermediate versions) are sometimes possible, they are not recommended due to the risk of missing critical changes or updates that could affect your project. Following the sequential upgrade path allows you to address these changes incrementally, reducing the risk of significant issues.

lucky

Could we update the library runtime sequentially , but leave the animations broken so we update the animations from 4.0 to 4.2? or not recomended. So we skip re-exporting and reimporting a lot of linked files twice.

Misaki

lucky I think it is possible, but not recommended. It would be difficult to determine what is causing the animation to go wrong after the upgrade to 4.2 is complete. Re-exporting skeleton data is easy with the shell scripts we have made available, and we encourage you to use them: Blog: New export shell scripts

Harald

@lucky In general we always recommend setting up automated (scripted) exports of your skeleton assets, so that re-exporting all your assets and copying it to the target asset directory in a new version is no work at all (as Misaki mentioned above).

Since you explicitly asked: you can skip exporting your skeletons as version 4.1 and directly upgrade from 4.0 to 4.2. You probably get the best of both worlds by first upgrading your Unity project code-wise to spine-unity 4.1 (following the 4.0 to 4.1 upgrade guide) and copying this 4.1 project away for later testing. Then upgrade the project to 4.2 and paste all re-exported 4.2 skeleton assets there. If you now encounter any issues with a specific skeleton and don't know which upgrade broke it, you could still test if re-export of only the problematic skeleton as 4.1 works in your 4.1 Unity project or not.

lucky

Thank you both for your response!
We're in a phase where we have export settings for some but not all files, and most of the files go to different places so we can't use a unified export unfortunately. Now that said we're working on having export settings for all files so the next time we can and will use the shell script and thank you for making it!

We'll do as you suggested Harald, and have the script as part of our internal process as well as mandatory of saving export settings per file.

As a wishlist item ,it would be cool if one could reverse engineer binary or json export settings, such as fetching the scale size, if premultiply alpha is on, edge padding etc then we could reverse engineer already exported files faster than guessing at settings(specifically with scale and white space + premultiply alpha).
But either way we'll make the settings now for the missing files 🙂

Thanks for all the hard work yall have put into it!

Harald

lucky As a wishlist item ,it would be cool if one could reverse engineer binary or json export settings, such as fetching the scale size, if premultiply alpha is on, edge padding etc then we could reverse engineer already exported files faster than guessing at settings(specifically with scale and white space + premultiply alpha).

In case you didn't already notice, the exported .atlas.txt files already contain PMA and scale info, like
pma: true scale: 0.5

lucky

Harald
I didn't! That's super useful, thank you!

Harald

Glad to hear it helped, you're very welcome! 🙂