This issue still occurs with the latest version of Unity 4.2.1. Whilst I may be mistaken, I was under the impression that Unity 4.0 was suppose to support namespaces within scripts now.
When this issue does occur, attempting to delete the broken asset file causes Unity to crash to the desktop with some MemoryStream exception.
Oddly, it is (and has for quite a while now) possible to place ScriptableObject’s into custom namespaces if you compile them into DLL’s. But for some reason attempting to do this with separate script assets does not work.
I have reported this using the bug reporter. Here is the case number should anyone be interested: Case 561547
Can’t be certain on ScriptableObjects, but namespaces still aren’t fully supported for some objects. You can’t put a Monobehavior in a namespace whether its in a script or a DLL, it just doesn’t work. Your best bet is to not use namespaces for ScriptableObjects either.
@numberkruncher, I have not problem to use ScriptableObject in namespaces. In my Decal System Pro, I have a TextureAtlasAsset which is a ScriptableObject within a namespace. In my development environment, it is obviously not in a dll, while in the final version the class is part of a dll. I had not problems with it.
@Dustin Horne, lots of my classes are in namespaces, including scripts derived from MonoBehaviour, Editor, … . This works since Unity 4 and I never had issues with it so far. What is not working for you?
Interesting, I’ll have to give it a try again. It’s been awhile since I tried it but with 4.0 I was still getting errors when putting a MonoBehavior derivative in a namespace but I may have missed something. My MonoBehavior in that instance was in a compiled assembly.
Okay, I have narrowed the source of the problem down and it is 100% reproducible. This problem is caused when a custom scriptable object class is placed within a namespace which contains a function with a default parameter.
The following editor script is used in each of the following test cases:
// Assets/Editor/Test.cs
using UnityEngine;
using UnityEditor;
using My.Namespace; // Cases 3, 4 and 5
public static class Test {
[MenuItem("Custom/Foo")]
static void Foo() {
var ms = ScriptableObject.CreateInstance<MyScriptable>();
AssetDatabase.CreateAsset(ms, "Assets/test.asset");
}
}
Case 1: Works Fine - Bare Bones
// Assets/Scripts/MyScriptable.cs
using UnityEngine;
public class MyScriptable : ScriptableObject {
public int someNumber;
public void Foo(int xyz) {
someNumber = xyz;
}
}
Select menu Custom|Foo.
Select asset in project view and inspect.
All good.
Delete asset.
Case 2: Works Fine - Namespace
// Assets/Scripts/MyScriptable.cs
using UnityEngine;
namespace My.Namespace {
public class MyScriptable : ScriptableObject {
public int someNumber;
public void Foo(int xyz) {
someNumber = xyz;
}
}
}
Select menu Custom|Foo.
Select asset in project view and inspect.
All good.
Delete asset.
Case 3: Works Fine - Default Function Param
// Assets/Scripts/MyScriptable.cs
using UnityEngine;
public class MyScriptable : ScriptableObject {
public int someNumber;
public void Foo(int xyz = 123) {
someNumber = xyz;
}
}
Select menu Custom|Foo.
Select asset in project view and inspect.
All good.
Delete asset.
Case 4: Fails - Default Function Param + Namespace
// Assets/Scripts/MyScriptable.cs
using UnityEngine;
namespace My.Namespace {
public class MyScriptable : ScriptableObject {
public int someNumber;
public void Foo(int xyz = 123) {
someNumber = xyz;
}
}
}
Select menu Custom|Foo.
Select asset in project view and inspect.
Inspector indicates that script is missing sometimes saying “None (Mono Script)” otherwise oddly “None (Mono Behaviour)”.
Delete asset.
CRASH
Case 5: Works Fine - Same as Case 4 but inside a DLL
Checking in from the future world of 2018! This still happens. I tried to isolate it by moving the offending script into an empty project, but it works fine in the empty project. Other ScriptableObjects in my project work fine, but any new ones I create will not assign a script to the asset. When put the inspector in debug mode and drag the script into the inspector field, I get this in the console:
Just bumped into this issue: for me, trying to create a scriptable object and save it as an asset when it is defined in a dll does not work.
The instance is properly created, but whenever I reload the editor, the data inside the asset is lost.
How are you modifying the values of the asset? do you have a custom inspector for it? if so, are you using SerializedProperty to modify it or target? This sounds like the asset might not be marked as dirty after modifying the values.
Which, exact, version of unity are you seeing this behavior in?
A late fix was introduced in 2018.2, that is present in the final release, that addresses a just such a scenario.
I am setting the asset dirty, but the script is not recognized: I am creating the asset in an [InitializeOnLoadMethod] method, no custom inspector, just a data holder. The asset is properly created the first time, but after reloading the engine it is not recognized anymore.
Since it is for an asset store plugin, I unfortunately cannot rely only on version 2018.2: I found a workaround now, but I will check it on the last version as well!
I’m running Unity 2018.2.2f1 and I recently did a Reimport All. After doing so, two asset store assets I was using (Maintainer and QHierarchy) started acting up. Maintainer kept logging in the console that it couldn’t load its settings file and QHierarchy threw repeating errors in the console.
After looking at their code I noticed they were using ScriptableObjects to store their settings. QHierarchy’s ScriptableObject definition was defined within a namespace and I was able to repeat the same issues as described by others in this thread. After moving the ScriptableObject definition outside of the namespace, the errors went away and the .asset file in the project view was able to find its definition script file.
Got similar results to @amisner2k the breakage in QHierarchy is very noticeable.
My own ScriptableObjects break too. Not only that, when the bug triggers, almost all MonoBehaviours also stop being recognized. Some still continue working for some reason (all in namespaces). I could not find a way to revert it to a working state either. Reimporting did not help. You have delete the library folder and rollback to a working version.
Then there’s this: With the pretty much the same setup, everything works fine in one computer but not in another. Same OS and similar hardware, same Unity version, fresh project from source control, etc.
I manually copied the Library folder from the working machine to the broken one and it started working.
Since the issue seems very non-deterministic, I can’t produce a stable reproduction case.
I’m assuming this is caused by the changes in the parser related to this: Scripting: Fixed “using static” directive causing Unity to not find the class in the script (962043, 962275)(release notes: https://unity3d.com/unity/whatsnew/unity-2018.2.2)
The mentioned issue isn’t fixed, it is still present (at least with 2018.2.2 and 2018.2.3 on Windows). I just submitted a bug report (#1069915) about the static imports issue. Maybe fixing that will help with these weird issues we’re seeing on this thread.