Unreliable ScriptableObject assets: associated script cannot be loaded

In the unity version I’m using (5.3.3f1), ScriptableObject-based assets became incredibly unreliable. I routinely run into “associated script cannot be loaded, please fix any compiler errors and assign a valid script” even when there are no compiler errors. Once I see this message, scriptable-object-based assets goes kaput, its “script” field is set to “none” and contents of the scriptable object cannot be recovered anymore (even if I assign valid script to the asset again).

I do not remember this happening in 5.1 or 5.2. Does anyone know what causes this issue or maybe there’s a workaround? I kinda liked using scriptableobjects as project-wide configs, and it is one of the things that worked well in unity before.

1 Like

It sounds like the metadata for your ScriptableObject class script is getting changed. You could try this: Switch to Show Meta Files and Force Text Serialization. Then record the GUID listed in your ScriptableObject script’s .meta file. When your asset goes kaput, check the .meta files of your ScriptableObject script and your asset. If the GUID has changed, something funny is going on, like maybe some editor script is copying and deleting your script, which would give it a new GUID.

Well, thanks for the response, but at this point I simply scrapped the class that was causing trouble and moved the data into monobehavior. Interestingly, only one class was problematic.

I’ll keep your advice in mind next time I run into something like this.

I ran into this same problem and found the cause to be a ScriptableObject that did not have the [System.Serializable] tag above the class declaration. Once this was added all of my ScriptableObject came back to life.

6 Likes

This was my issue too. Could not figure out what was wrong. Thanks.

I have this problem with ScriptableObjects inheritance and unfortunately this doesn’t solve it, I have to select the damn corrupt files and recompile inside the IDE (refresh & reimport inside the editor do nothing) every single time ! It’s such a pain…
It seems to only happen when you do inheritance among ScriptableObjects.
Unity version 2019.3.06f & above.

Edit: problem solved when I moved each SO into a distinct file AND recreated the .asset files corresponding to those SOs (e.g HealthPotion.asset). Without recreating those files anew the problem isn’t solved. Thanks to AverageArmadillo for pointing this out in Reddit - Dive into anything
This is one of those obscure issues in Unity unfortunately.

6 Likes

OK, I gotta post here. I had the same issue and will tell you how I fixed it… I worked on that project for about a year and basically had a standard ScriptableObject architecture for setting object references. Basically, what Ryan Hipple aka roboryantron popularised, but very much simplified.
The project was on GitHub all that time, I kept updating it. So, the day has come… I messed up my project, now I am cloning the project from the repo again, the latest stable version.
You guessed it - all ScriptableObject references got broken. However, I can still see that references to .asset files are still there (in the Inspector). I select my SO files, there’s a warning: “associated script cannot be loaded, please fix any compiler errors and assign a valid script”. No errors in Visual Studio, no warnings in console.
I rebuild the library, refresh, reimport - nothing helps. Then I notice one thing: my SO class is called GoValue, but in the project it’s GOValue. If it’s not clear, the script goes like this: public class GoValue : ScriptableObject, etc. But in the project files the file itself is called GOValue.cs
So I renamed it to GoValue.cs and it fixed everything (as it should!). Because everyone knows that if the file name and the script name are not the same, it won’t compile, right?! Now, the question is: how in the world it’s been a whole year of builds, even beta testing, without any problem? It just worked for some reason…

Sounds like when you created the SO assets the script was named GoValue, but afterward it was renamed GOValue. This would prevent you from assigning it to new SOs, but the original assets’ metadata/Library never changed, so it continued to correctly reference it by GUID. (If a script name and class name don’t match, the code will still compile. You just can’t assign it to a GameObject or asset.) Probably if you had tried a Reimport All in your original project, or removed and rebuilt the Library, it would have reported the issue then. Quest Machine is heavily SO-based, and I did this to myself, too, a couple of times during development.

2 Likes

Yeah you are right, TonyLi. It worked, I am quite sure I renamed it later, it worked for the whole year. Then I had to clone the project from the repository and that’s where things went bonkers. Thanks for clarification!

To add my experience. Just had my SO’s bugging out as above, ‘script not found’. I moved the script from sharing another SO .cs file to its own file, created a new SO using this class, and it and the old SO’s worked. Closed project, opened it, all broken again. So then deleted all SO’s that were created using the definition in a shared file and recreated with new SO’s using the definition in its own file. Now it’s working.

Moral of this story is ensure you have a separate file for each SO. The manual does say this but it’s not obvious if you have already used simple SOs and are reusing the idea without reading the manual through again as there are no complaints when you compile multiple SOs into the same file, can create objects fine, and can even use and populate those objects until the issues suddenly manifest. Ideally there should be a compilation error “cannot define more than one SO per file. Please create a unique file for each SO you are wanting.”

YOU SAVE ME!

1 Like