Thanks, just realized I do some a lot of initial setup on some of my boiler plate scriptable objects that might actually use this reset functionality nicely. Need to do some testing with when it is actually fired for SOs.
Looking at the comments I think a lot of developers do the same .. there are a couple of benefits to the reset method like it not being called with each value change in the inspector, but mainly separation to keep the onvalidate just for validation is a bonus.
I also do that for some things, but the problem with OnValidate is that it triggers on any project interaction, not just that single object; which should obviously be avoided when possible. In some cases, the only way to bypass it is to create a custom editor.
@@Rovsau I have been using OnValidate, and I felt like it was too much extra work ... overloading ==/!= and wrapping it all in #if UNITY_EDITOR with a previous inspector values field and comparison, or in some cases abuse of GetHashCode lol, but the good thing is I could detect exactly what field was modified and trigger more complex editor logic 😆
Well, there's a problem with Reset() method, when you have float fields and a designer sets value in the editor, when you click reset to assign references these earlier mentioned floats are being reset as well
Yep reset will return all to default values .. in this video its more about the initial adding of a component and using the monobehaviour reset functionality to help you.
Well it depends on a few factors with the main one being how many components there are on the gameobject .. GetComponents could also be swapped in this example for GetComponentsInChildren which will go deeper. Then we need to look at how often it is done in the scene etc .. so the good practice of using reset and serialized fields in this instance is an overall benefit .. but not essential
It doesn't matter until there's already a lot going on, such as many objects being awoken simultaneously, and or during a resource-intensive game scenario. This might only matter when dealing with many thousands of game objects.
I've advocated for that practice for some time (void Reset). Normally using it along with the HideInInspector attribute, but recently learned that's not necessary if all the components are in a serializable struct, because the entire struct can be collapsed in the inspector, which makes it pretty clean. What is important to note, is that if a component goes missing from a script, Reset is Not called when Play Mode is entered. And while I haven't done this, theoretically: if a lot of objects need to Get their Components again, clicking Reset on all of them by hand might be tedious. A parent object script could use MonoBeahviour's SendMessage to trigger all the Reset methods. But ideally, it would be a custom method like GetMyScriptComponents which is called by Reset, which can then be called by SendMessage, without resetting all the scripts' values.
@@WarpedImagination Last week I explored some more practical solutions than SendMessage. With either an interface or an abstract implementation, all those behaviors can have their GetComponents triggered. All one needs to do is make a method or two, that helps find any currently loaded MonoBehaviour or ScriptableObject, or other object which may implement it. This is possible by using Resources FindObjectsOfTypeAll, with MonoBehaviour and ScriptableObject respectively. A trick inside the foreach is to have an if-statement that says if (monoBehaviour is T behaviour) found.Add(behaviour).
Hey ol fella, what's the big idea?! Think ya can just go around teaching me useful tricks I hadn't thought of??! Cuz, well ... ya can, actually ... I like this! 😅
I usually try and keep onvalidate purely for validation (which I have some cool automation around that I have been meaning to do a video on) .. plus on validate gets called a fair amount whenever a value changes in the inspector so I skip having to do gets everytime .. but in all honestly it doesn't hurt anything
I had no idea this existed, nice!
Seems by the response I got to this video you were not alone .. remember to tell one other developer to share the knowledge
I love Reset but I don't always remember to use it though.
Great video!
I admit I forget on the odd occasion as well when I am coding on automatic
I usually handle this using a null check in OnValidate, but nice little tip to add to the belt.
yep it doesnt hurt to do it onvalidate
Your content is fantastic. Keep up the great work.
Thanks, will do!
Dang! I never knew that reset was called when adding a component. Nice.
Yep it's sure handy
I've been using this trick for years now :D
Automation is our friend
thx man very helpfull
No problem!
Thanks, just realized I do some a lot of initial setup on some of my boiler plate scriptable objects that might actually use this reset functionality nicely. Need to do some testing with when it is actually fired for SOs.
It is fired when the SO is created or when the context menu Reset button is pressed
Love this tip!
Glad you liked it!!
This is a nice trick!
Glad you liked it
Magnificent! Had forgotten this exists. Just hope the bunnies don't end up in tanks in the basement of the theatre.
I can't say where the bunnies go .. that would ruin the illusion and get me in trouble
Oooo love this!!
Yep its super useful
very cool tip thanks
No problem!
Interesting I always did same but instead of void Reset(), I used the void OnValidate() to make it populate my component into the serialized fields.
Looking at the comments I think a lot of developers do the same .. there are a couple of benefits to the reset method like it not being called with each value change in the inspector, but mainly separation to keep the onvalidate just for validation is a bonus.
I also do that for some things, but the problem with OnValidate is that it triggers on any project interaction, not just that single object; which should obviously be avoided when possible. In some cases, the only way to bypass it is to create a custom editor.
@@Rovsau I have been using OnValidate, and I felt like it was too much extra work ... overloading ==/!= and wrapping it all in #if UNITY_EDITOR with a previous inspector values field and comparison, or in some cases abuse of GetHashCode lol, but the good thing is I could detect exactly what field was modified and trigger more complex editor logic 😆
dude. Thank you!
Glad to help!
Well, there's a problem with Reset() method, when you have float fields and a designer sets value in the editor, when you click reset to assign references these earlier mentioned floats are being reset as well
Yep reset will return all to default values .. in this video its more about the initial adding of a component and using the monobehaviour reset functionality to help you.
Hi! Great video, thank you!
A quick question - why don't you use Rider instead of Visual Studio? What are the advantages of visual studio?
The main reason I use visual studio is its free to unity developers so anyone watching the videos can get the same experience
Charming video. 🐇
Though i do prefer the Awake-Calls. It's slightly simpler an do like simple.
Simples!
Good tip. Is calling GetComponent in Awake really that costly though?
Well it depends on a few factors with the main one being how many components there are on the gameobject .. GetComponents could also be swapped in this example for GetComponentsInChildren which will go deeper.
Then we need to look at how often it is done in the scene etc .. so the good practice of using reset and serialized fields in this instance is an overall benefit .. but not essential
It doesn't matter until there's already a lot going on, such as many objects being awoken simultaneously, and or during a resource-intensive game scenario. This might only matter when dealing with many thousands of game objects.
I've advocated for that practice for some time (void Reset). Normally using it along with the HideInInspector attribute, but recently learned that's not necessary if all the components are in a serializable struct, because the entire struct can be collapsed in the inspector, which makes it pretty clean.
What is important to note, is that if a component goes missing from a script, Reset is Not called when Play Mode is entered.
And while I haven't done this, theoretically: if a lot of objects need to Get their Components again, clicking Reset on all of them by hand might be tedious. A parent object script could use MonoBeahviour's SendMessage to trigger all the Reset methods. But ideally, it would be a custom method like GetMyScriptComponents which is called by Reset, which can then be called by SendMessage, without resetting all the scripts' values.
Good points to add to the conversation
@@WarpedImagination Last week I explored some more practical solutions than SendMessage. With either an interface or an abstract implementation, all those behaviors can have their GetComponents triggered. All one needs to do is make a method or two, that helps find any currently loaded MonoBehaviour or ScriptableObject, or other object which may implement it.
This is possible by using Resources FindObjectsOfTypeAll, with MonoBehaviour and ScriptableObject respectively. A trick inside the foreach is to have an if-statement that says if (monoBehaviour is T behaviour) found.Add(behaviour).
Nice!
Thanks!
Hey ol fella, what's the big idea?! Think ya can just go around teaching me useful tricks I hadn't thought of??! Cuz, well ... ya can, actually ... I like this! 😅
Glad you liked it .. now lets discuss who you are calling old
@@WarpedImagination why'd you bite on that?! 🙃 haha
Abracadabra!
I might make every tutorial magic themed from now on!
I use OnValidate for this. Is there a reason I should use Reset instead?
I usually try and keep onvalidate purely for validation (which I have some cool automation around that I have been meaning to do a video on) .. plus on validate gets called a fair amount whenever a value changes in the inspector so I skip having to do gets everytime .. but in all honestly it doesn't hurt anything
OnValidate triggers on any object change, not just the parent object. It should be used sparingly, or at least not too much.
It's really cool people are still using engines like Unity, keeping the old flames alive.
Yep been using it for over a decade now
@WarpedImagination you must be exhausted, take a break and get some sleep.
Is there any social where I can contact you?
There is a contact section in the about page of the channel
neat
Glad it was helpful