Could anybody help me with these 4 longtime scripting questions?

Hi all,

1. I have this fear that my coroutines will not stop so I use a return break in all coroutines and then use StopCoroutine again in onDisable (or elsewhere depending on context ). Is this useful or does it give 'hidden' problems? And if a coroutine is ran and the gameobject is disabled, does the coroutine stop of does it run until the break?
2. I have several scripts that undo their changes in OnDisable. Things like StopCoroutine and for loops (to for example reset material colors). Now when I stop the editor I get errors that the GameObject is not available anymore and that I should do an null check. Does this give problems in the final application or can I ignore this?
   
3. I read not to use SendMessage too much, so I don't alternatively I use GetComponent. But when I load a script component in a variable, that variable is a reference to the script(on that gameobject) right? Or it stores the entire script? And if its a reference then why not always use the 'getcomponent message'? And whats the difference between SendMessage besides specifically pointing to the right method in the right component?
   
4. When possible I try to use things like GameObject.Find("something").GetComponent to avoid creating extra member variables. Whenever I don't need them much, for example for toggling things in a tutorial. As a tutorial is only used once or twice. Is this good practice? And do the class member variables still use memory if the Gameobject is deactivated?

btw I use C#.

Thanks in advance!

 

Well all I can say is you've pretty much made a checklist on how to slow down games. Using references to objects are a far better pattern for unity.

1. I don't use coroutines so I can't help you there.

2. same

3. Sendmessage is absolutely fine to use. Just not if you're doing hundreds of them. If it means cleaner code, by all means use them. I've even used them on mobile with zero impact on the framerate. I guess the advice is use, don't abuse.

4. GameObject.Find is horrific for performance, depending on scene. If it's just used during setup then it's fine, but it's not actually intended for runtime use really.

 

1. Coroutines will automatically stop if the MonoBehaviour they are called from is disabled or destroyed.
2. Just do the null check or check is the application is quitting. In most cases you don't actually need to reset changes when the application is exiting, Unity will take care of this for you
3. Storing a reference doesn't store the entire script. It stores a tiny pointer to the scripts location in memory. So if you are going to call GetComponent more then once it makes sense to save the result. SendMessage itself should be phased out in favour of ExecuteEvents. ExectuteEvents is cleaner, safer and faster
4. GameObject.Find is expensive on the CPU. Storing a reference in a member variable costs a tiny little bit if memory. On most platforms Unity targets there is memory to spare, and precious little CPU to waste. So Find seldom makes sense.

 

From my tests, the coroutine will not disable if the monobehaviour is disabled, only if the gameobject the monobehaviour is on is disabled. If the monobehaviour is destroyed then it does stop.

 

Nice to know. I personally tend not to disable MonoBehaviours very often, because a disabled MonoBehaviour doesn't always behave as expected. Mostly I just use the check box for occasional debugging. If I want to be able to turn a MonoBehaviour on or off I'll normally implement my own functionality for this.

 

Most of my GameObjet.Find's are in Awake, but I'll get the other ones out too then. Thanks for the replies!