I'm getting this warning every time I re-open a project on 2020.2.0f1

"No script asset for SpinePreferences. Check that the definition is in a file of the same name and that it compiles properly."

And then an error:

"ReleaseAllScriptCaches did not release all script caches!"

No other messages, no idea where the error is coming from.

This is reproducible by creating a new URP project, importing the latest Unity runtime then quitting and re-opening the project.

Thanks for posting foriero, glad to hear that.

Sorry for the trouble and thanks for reporting Aurigan! We are already aware of the second error, but not yet of the first one.
You can find the corresponding issue ticket here:
https://github.com/EsotericSoftware/spine-runtimes/issues/1779
We will let you know once the issues have been resolved.

The first one is a warning. I have the same issues.

Aurigan написал

This is reproducible by creating a new URP project, importing the latest Unity runtime then quitting and re-opening the project.

By creating any new project :-)

Holygoe написал

The first one is a warning. I have the same issues.

Thanks for the hint, I must have had -Werror / /WX enabled while reading your posting .

I got the same issue and from some investigation on my side it looks like that the Asset Database is not fully initialized during the editor startup at [InitializeOnLoad]. This causes some weird breaks when SpineEditorUtilities tries to load SpinePreferences as it seems the settings asset is not loading (but gets recreated after with the default values). The wierd stuff was that call was causing breakage in the URP settings asset sometimes...

I did a quick fix/workaround:

---

 a/Assets/Spine/Editor/spine-unity/Editor/Utility/SpineEditorUtilities.cs
+++ b/Assets/Spine/Editor/spine-unity/Editor/Utility/SpineEditorUtilities.cs
@@ -97,7 +97,7 @@ namespace Spine.Unity.Editor {
 
 #region Initialization
                static SpineEditorUtilities () {
-                       Initialize();
+                       EditorApplication.delayCall += () => Initialize();
                }
 
        static void Initialize () {

This seems to be working properly, with the only side effect i have noticed being that warnings for textures are logged in the console about part of a second later (due to the delay call).

P.S.
I believe something similar was happening on 2019.4 too. There were sometimes when the spine settings asset was reset to the default values from time to time, but I never payed much attention to this as I was just checking out the file when these modifications occurred and they were rare enough to not cause a big trouble.

foriero написал

Ahhh... Glad you found it. Yes I can confirm that URP is getting unassigned from Graphics Settings due to the error in Spine Initialize onload.

Interesting - I have also been having this URP asset getting unassigned issue but didn't realize it might have been related.(also on 2020.2)

Sorry for the late reply! Thanks very much @vhristov for figuring out the fix, good work! 8)
Also thanks @foriero for posting the EditorApplication.update based fix.
We have just submitted a bugfix based on the first implementation (as it executes a bit earlier and uses less code).

New 3.8 unitypackages are available for download here as usual:
Spine Unity Download: Download.
4.0-beta unitypackage should follow in a few days.

Thanks for all your helpful contributions and reports!

The update fixed it for me :greatsuccess:

Thanks guys!

I'm having the same issues but running the spine-unity-3.8-2021-01-08.unitypackage causes Unity to crash (after clicking the Import button).

I keep spine in the packages folder at: \Packages\com.esotericsoftware.spine.spine-unity
Unity version: 2020.2.1f1

Update: To get a working install, I had to create an empty project, import the package and then manually copy the files to my real project.

The 4.0-beta unitypackage has just been released. It's available for download here as usual:
Spine Unity Download

kloot написал

I'm having the same issues but running the spine-unity-3.8-2021-01-08.unitypackage causes Unity to crash (after clicking the Import button).

I keep spine in the packages folder at: \Packages\com.esotericsoftware.spine.spine-unity
Unity version: 2020.2.1f1

@kloot Did you try to import spine-unity directly from the unitypackage to the /Packages/com.esotericsoftware.spine.spine-unity directory? If so, I wonder that this worked in the past, as local non-UPM unitypackages are not intended to be unpacked into the UPM /Packages directory, this is a mix of the old and new Unity package workflow. spine-unity contains package.json files so that it can alternatively be used by the Unity Package Manager by the following workflow:

http://esotericsoftware.com/spine-unity#Installation написал

Copy the package contents anywhere outside your Assets directory, then open the Package Manager in Unity (via Window > Package Manager), select the + icon, choose Add package from disk..., and point it to the package.json file.

While this workflow works, it is however not recommended (yet) and therefore we describe installation of the unitypackage on the spine-unity documentation page using the normal (old) package workflow of unpacking a local unitypackage: spine-unity Runtime Documentation: Installation
Unity documentation also still lists the same workflow for local unitypackages:
https://docs.unity3d.com/2020.2/Documentation/Manual/AssetPackagesImport.html
Note that the spine-unity documentation section about Optional Extension UPM Packages is describing installation of the extension modules provided as a zip package, not the spine-unity core unitypackage.

In short: please do not mix the old unitypackage import workflow with the new UPM package workflow.

• a) When importing the unitypackage directly, please don't place the assets in the /Package directory and leave it in /Assets.
• b) If you really want to use the new UPM workflow, please update the files in their existing location manually (or via git pull) and don't use the old unitypackage import workflow.

Glad to hear, thanks for letting us know, Marek!

I'm sorry, was runtime for unity 2020 removed from public access? All runtimes here say they are for Unity 2017.1-2019.4, even the 4.0 beta.

Thanks very much for taking the compatibility lines seriously! You can use the latest versions of both the 3.8 and 4.0-beta spine-unity runtimes with Unity 2020.1, there are no separate 2020.1+ packages.

We have not yet increased the lines to officially support Unity 2020.1 because there were still some critical known bugs such as this one left that needed to be fixed. It will take one more minor simple commit for this issue ticket until we will increase the version number, as no known bugs limited to 2020.1+ are remaining after this ticket.

We have just commited the remaining bugfixes.
The latest 3.8 and 4.0-beta packages now officially support Unity 2017.1 - 2020.2.
Thanks again to everyone for your bug reports! :nerd:

They can be downloaded here as usual:
Spine Unity Download

Thanks for adding the official support

By the way, is there a changelog for 4.0 runtime? All I see is this, which stops at 3.9 version.