I’m just wondering if there is any advantage/disadvantage to enabling/disabling script components on an object (to turn them on or off) vs setting a public bool on the script and wrapping all the update/fixedupdate functions inside a test to see if that bool is true or not?
targetScript = ScriptTargetGameObj.GetComponent<myScript>();
targetScript.booleanScriptEnabled = true/false;
//and then in the targetScript
void Update() {
if(booleanScriptEnabled){
//update code
}
}
With the first approach I have to us OnEnable() instead of Start on targetScript - and disabling the script just tells Unity to not run those functions, so the memory usage probably isn’t much different - with the second approach I can just use Start() but unity will still at least parse the boolean before ignoring the rest - any pro’s or con’s or personal preferences to either approach or is it pretty much of a muchness either way?
Turning the script off stops any update or fixed update loop from the object that may be inside the script, whereas setting a bool although there may be no computation in that script it’s still constantly checking to see if that one bool has changed. So although in a small instance it may not make a visible difference if you had that situation for a script attached to a few hundred objects you’d might see a difference.
A few hundred objects for example a grid made from tiles that had an update loop or collision loop.
Also I don’t know if you noticed but …. If you create a script that does not contain an update or fixed or collision or trigger check; you can’t deactivate the script (because there is no reason to)
Actually you can, but not in the inspector ^^. So the inspector is not showing the checkbox, but the state can still be changed. Also disabling does have some other effects besides the Unity callbacks. In order to start a coroutine on a monobehaviour the script must be enabled.
On topic:
Of course it’s partly a matter of choice. However generally speaking a component in Unity should be small and have preferably only one purpose. Using Unity’s enabled property has the advantage that it already represents a common interface. This makes it easier for inter-component interactions as one could simply have a reference to a “Behaviour” and he’s able to enable / disable it without knowing the exact type or what it does. Sure a similar effect can be achieved with custom interfaces, but less elegant since interface references are not serializable (at the moment).
As AnimalMan said, using your own boolean does work, but leaves a lot of overhead behind since the Update method is still called every frame just to do nothing. Most arguments for such an approach are that there may be other code that still needs to run. Yes, there are such cases, but in most cases it could be a sign that there is too much functionality inside the same component. Don’t get me wrong, sometimes you need god-objects for certain things, but it should not be the norm.
You can’t really give a generally valid answer to this question as it highly depends on the usecase. Though when you think about a MonoBehaviour in its literal sense, so it represents a certain behaviour and when you enable / disable that component, you enable / disable this behaviour. You mentioned OnEnable and Start in your question. However those are only partially related to this. While Start, Awake and OnEnable allows you to carry out certain actions in certain situations, object initialization often times can not be done by the component alone. There are many cases where the order of initialization matters. So in such cases you often use your own central initationation logic. This does not only provide more control over the execution order but is often times better for performance. Though, again, there’s no generally valid argument for such questions.
I suppose Unity would need to parse whether a script is enabled or disabled to decide whether to run the update loops anyway…so the boolean variable method to ‘block out’ same is starting to sound a little redundant…
No, that’s not how it works ^^. Disabled components are simply not listed in the internal update lists. So Unity essentially has a List (probably a C++ vector or a hashmap) that contains all instances that need their Update method called. How exactly Unity organises them internally we don’t know. Though Unity has to obey the setup execution order. So Unity may even have seperate buckets for each execution order group.
Saving the cost of crossing the C++ - C# barrier is more than enough reason to go with the component.enable solution. Even a very quick and dirty in-editor test shows the difference as Jason Booth pointed out in his latest post here.
