If you create a ScriptableObject and add a CreateAssetMenu line as per the docs, the menuName seems to have to exactly match the ScriptableObject’s name at the end or at least certain names really break the scriptable object i.e. doc says menuName = “ScriptableObjects/SpawnManagerScriptableObject”
if I use a line like [CreateAssetMenu( fileName = “CommonMaterials”, menuName = “ScriptableObjects/CommonMaterials” )]
Edit: followed by a scriptable object named say CommonMaterialsScriptableObject
I do not know what is happening here but please make better error messages and document how to write the CreateAssetMenu line without breaking anything
Edit: this was a bug fixed by changing the CreateAssetMenu name, could not recreate in fresh project - moving on
I don’t think the error has anything to do with [CreateAssetMenu]. That error generally means your monoscript file and the class defined inside do not match.
This works completely fine for me:
[CreateAssetMenu(fileName = "CommonMaterials", menuName = "ScriptableObjects/CommonMaterials")]
public class CommonMaterials : ScriptableObject { }
That shows on literally every script that either isn’t a monobehaviour or scriptable object script, or where your monobehaviour/scriptable object class name doesn’t match its containing monoscript file name.
If it’s either a monobehaviour or scriptable object script, then just fix the name issue. If it’s not a script for either of those types, you can ignore it.
I did not call the scriptable object class the same as fileName - that would be awkward…
The monobehaviour message (which Unity should not show if not a monobehaviour!) is not actually shown if the scriptable object is working properly.
Anyway I can not recreate the issue in a fresh project at the moment - very weird bug, only fixed by changing the CreateAssetMenu menuName…
Except that doing so is the correct Unity way. What is “awkward” about it?
I’m not on the engine team but I’ve heard from various sources that the core native engine data structure is identical between a MonoBehaviour and a ScriptableObject. One is meant to live as an asset on disk, the other is intended to only be instanced while attached to a GameObject, that’s all.
I’m guessing something else was wrong (perhaps a failure to reimport / compile the file?) and it got fixed when you retyped your message. See Spiney’s message above.
You completely misunderstand me, I am not a beginner - I was talking about fileName in the CreateAssetMenu line. This is what bugfinders was talking about but of course I did not do it.
Doing as Spiney wrote would create a new asset with the same name as your ScriptableObject class
This whole thread is a series of misunderstandings, time to delete…
ScriptableObjects actually ARE MonoBehaviours At least from the perspective of the engine core. On the C++ side Unity literally uses the same class to represent both. ScriptableObjects are essentially MonoBehaviours without a parent. It’s only on the C# side that there are two different classes. You can actually see this when you look at the serialized data.
The reason why it’s called MonoBehaviour in the first place is the fact that the C++ side simply sees the C# / mono part as a dual / addition to the native representation.
I was trying to leave this conversation…!
But yes OK scriptableObjects are - what I was thinking of is plain C# scripts.
At one time Unity suggested in the docs that all your scripts should be monobehaviours or scriptableObjects which is nonsense since you can have any number of straight C# scripts too.
This is why unless it is a monobehaviour-derived script where it needs to be a classname that equals the filename, this warning is not relevant.
I did not notice it before - but any script with just C# in and no monobehaviour shows the message - silly!
It’s not a warning, though. It’s just a regular info box.
If it were a warning it’d have yellow icon, or red if it’s an error.
It’s just to let you know in case it is relevant. If you see it when you’re making a scriptable object or monobehaviour class, you know something is up. If you’re not, you can ignore it.