Probably you could even do this smarter and actually use the real Awake method of SOs so they add themselves to the list automatically. Now all SOs that shall have an init method inherit from ScriptableWithInit and in my scene I have an object with the manager class and I add every new SO to its list.įinally in that managers regular Awake method is a simple loop that calls the Init() method for all the SO. Then there's a manager class which is a monobehavior and just has a srializable list of those ScriptableWithInit. In that case, all of the ScriptableObjects referenced will have Awake and OnEnable called before the first Awake is called for any scene objects (and as youve noted, before RuntimeInitializeOnLoad, though thats new information to me). I wrote a simple class that inherits from ScriptableObject like "ScriptableWithInit" and allows for an Init() method (you could also name it CustomAwake, SceneStart or something similar). However if you do want a real awake method that executes on every game launch or scene load, that's not that hard to achieve. Now it's too late sadly since it'd break backwards compatibility. The whole "Awake" issue could have been avoided by giving that event a different name, oh well. I've had more issues than use of SOs so far. This has been very inconsistent and unreliable in my experience. It gives the impression that the creation of SO instances is cached by some conditions. Even the scripts provided by and simply did not execute some of the times I entered / left playmode. But as soon as you're building and running the game outside the editor, these methods will not be called whatsoever anymore if the SO instance wasn't assigned to an active scene object or loaded by a script in another way, but just exists in the assets.įurthermore I couldn't find out when the editor decides to load or re-load an SO instance that only exists in the assets. create an instance of an SO in the project's assets and it will look like OnEnable, Awake. It is particularly confusing in the editor. ) on Scriptable Objects (SO) are only reliably called, when an instance of an SO is referenced by an active scene component. However, it may add some complexity to the code, and care must be taken to ensure that all IUpdateable objects are added and removed correctly from the UpdateV2 list.In my experience, all "event methods" (OnEnable, Awake. Overall, this approach provides a flexible way to organize update functions in Unity, and can help reduce code duplication and improve maintenance. The UpdateableMonoBehaviour class overrides the update methods for each update type, allowing derived classes to implement specific behavior for each one. The UpdateV2 scriptable object has methods to add or remove IUpdateable objects to the appropriate lists, depending on their UpdateMask, and properties to store the interval for each update type. UpdateableMonoBehaviour subscribes and unsubscribes itself to a ScriptableObject called UpdateV2, which stores a list of IUpdateable objects, organized by update type (update, fixed update, or late update). Then, an abstract class UpdateableMonoBehaviour is created, which inherits from MonoBehaviour and implements IUpdateable. The idea is to define an interface IUpdateable with methods for update, fixed update, and late update, and a property UpdateMask that indicates which of these methods should be implemented. This is an interesting approach for centralizing update functions in Unity, which can help reduce code duplication and simplify maintenance.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |