Hi,
I noticed that if I create a Component with a public ScriptableObject reference I should be able to drag and drop a ScriptableObject instance inside.
However, I do not understand where I should take the ScriptableObject instance from. In fact, if I create a GameObject, I cannot drag and drop ScriptableObject inside, since ScriptableObject is not a Component.
Does this mean that ScriptableObject reference cannot be edited in the editor?
Thank you very much!
A ScriptableObject cannot be attached to a GameObject, so you wont be able to edit it in the editor, no.
so what is the point to detect a public ScriptableObject as an editor editable property?
Well by design, anything that inherits from Object is able to be exposed in the editor, so you can drag and drop things into the references, it’s just common functionality that ScriptableObject inherits, but I guess doesn’t have much use for,
What I do not understand is this: When I expose a Monobehaviour as public property in the editor and I drag and drop a GameObject inside it, do I drag and drop the GameObject itself or just the first Monobehaviour inside the GameObject?
That would be the first Monobehaviour in the object.
In my specific case I have a number of Command classes, that are very simple classes with just an execute method. I do not need any start or update or whatever, they are not indeed Unity Entities. However I do need the designer to be able to drag and drop these commands inside a component in a specific GameObject (Let’s say I have a RunCommandOnClick component inside a GameObject that knows when to call the OnClick function that executes a dragged by designer command).
Unity forces me to use Monobehaviour for commands in order to do this, am I correct?
As far as I know, yes, that’s the case.
But it shouldn’t be much of an issue, as if you don’t implement these functions in your class, they won’t be executed/have a performance hit.
Cool thank you very much, you have been very kind. In my case the problem is that in a given function I need to instantiate dynamically new commands, but I think I can find a workaround for it, maybe.
Although I have to say that I am exploiting (without even noticing it) a glitch in the unity editor that is allowing me to use ScriptableObject as component. Of course I will fix it, but honestly it works, try this:
Create a Monobehaviour class
Drag and drop it in a GameObject
Now change the class from Monobehaviour to ScriptableObject
The editor will now allow me to drag and drop the GameObject inside a public property that expects a ScriptableObject and it even works smoothly.
Haha, in interesting workaround!
But for dynamically creating the commands, what’s wrong with using GameObject.Instantiate?
That I do not want to clone a GameObject, I want to instantiate a new command (but of course I cannot do new on a Monobehaviour).
Can’t you just create a command prefab that is effectively a blank slate, which would be the equivalent of new?
I will try 
Hello,
You can’t attach ScriptableObjects to GameObjects as Components, but you can certainly reference them inside other behaviours. Your behaviour would have something like this:
public MyScriptableObject MyRef;
now you use a class like:
public class MyScriptableObject : ScriptableObject
You create instances of that class by using the ScriptableObject.CreateInstance function. Take the result and use the AssetDatabase.CreateAsset function to create an asset out of it, then use AssetDatabase.SaveAssets() to see the result in your project. The result will be a MyScriptableObject that lives in your Project folder (not your hierarchy) and it will drag and drop onto the MyRef field.
I will write a blog post soon about how awesome using ScriptableObjects for this purpose is and what kind of problems you can solve by using this method. If you want, follow me on twitter @JodonK.