(Solved, but unhappy)ScriptableObject.Awake never execute

Well you can drag a monobehavior (aka a script) from your assets onto a game object to create a component.
Do you have that many scripts that do not need a transform and yet should not be added to the same game object, so that the slight resource waste really becomes a problem?

"the Asset version of an MB" makes sense, yeah. It's still specific scenarios where you need that, I'd say. After all not being a game object comes with the downside of not having auto-resetting member variables (aka set values persist between two runs which is not always what you want).

 

This is getting a long way off-topic. But briefly: only assets and gameobjects are supported by the UnityEditor as directly-draggable/referenceable entities. MonoBehaviours have a handful of hacks (have been in Unity for > 10 years) that are REALLY UGLY when you dig into how they're implemented/what they're doing behind the scenes, and give the illusion that a user can drag/drop an MB. If I remember correctly this is also conceptually bound-up (they share root problems, share some of the hacks, etc - it's all to do with the difference between "MB in C#" and "MB in C++", IIRC) with why things like UnityEvent are almost impossible to use from scripts, and many other weirdnesses of serialization - MB is not, and never has been, a first-class item in the Editor.

Re: 'auto-resetting member variables' - this is in no way a 'downside'; if you are hot-swapping code it's exactly what you want -- it would be a nightmare if code variables were disappearing/appearing underneath your code!

TL;DR: SO's are great as re-usable, modular, composable, coding framework.

 

This seriously still isn't fixed? I want to instantiate a dictionary on awake and it isn't working. A simple debug.log message isn't being called...

I've already read through this thread and I don't quite understand how awake works in a SO. Can someone please explain how the awake in a SO actually works and what it is doing?

For example, does another script have to reference the SO first before any of its code including awake is called, I tried changing the execution order and it didn't make a difference.

 

TL;DR: "it doesn't" - simples!

Unity isn't going to fix this, ever. There are bugs in lifecycle calls (Awake etc) that I've been waiting almost 10 years for them to fix, and the answer you ultimately get is "yeah, but so many people depend on our bugs now that we're never going to change this".

(which is disingenous: Unity frequently breaks 'all existing Unity projects' when it suits them. But it's an easy-to-use excuse for avoiding working on a difficult problem)

 

i.e.: if you really REALLY care ... use one of the community workarounds/hacks that creates a "FakeAwakeWhichActuallyWorks_UnlikeUnitysBrokenOneWhichDoesnt()" callback.

But then you have to keep remembering to actively use the workaround in all your classes.

OR ... take the easy route: write on a sticky "NEVER use ScriptableObject.Awake() ever, in any Unity project", and put it on the wall behind your desk. Every time you need that method ... think of a more convoluted way to achieve whatever it was you were trying to do. And stick a comment in the source code "Unity refuse to provide a working Awake() so we have to do this instead; whatever you do: don't refactor this code to use Awakre - it WILL break if you do that!".

 

Create a SO script that inherits from SO with a callback that you want it to be "awake".
Then, create a SO Manager that is responsible to provide the SO you need and therefore, it calls the "awake" you created when you trigger the need for a specific SO.

This way you create a workaround unity's SO misconception.

 

Faced this issues in December of 2023, meaning today, documentations still states:
Awake is called as the ScriptableObject script starts. This happens as the game is launched and is similar to MonoBehavior.Awake.