koobas.hobune.stream
Dynamically removing required components when destroying
Scenario:
A GameObject has Component1, which requires, say, a box collider trigger.
ScriptA adds Component2 -- which also requires a box collider trigger -- to the GameObject.
ScriptB adds Component3 -- which also requires a box collider trigger -- to the GameObject.
Later, ScriptC Destroys Component3.
In an interest in tidiness, ScriptC should destroy Component3's required box collider. B ut the box collider shares a codependency with Component1 and Component2.
I don't see anything in the RequiredComponent documentation that points to how I might check whether any other components also require the box collider. (i.e. programmatic access to RequiredComponent attributes of components).
Any ideas on how to best solve this problem? Would I have to eliminate the RequireComponent attribute and programmatically add required components in Start(), and track them via that method? I'm hoping I've failed on the research/Google front and there's a great way to do this via baked in methods.
Why do you want to destroy the collider? If you don't want that collider which is required by others then don't refer to that collider in Script-C.
@kumarc123 - Take the simplest case - ScriptA adds a component that requires a box collider. ScriptB destroys the component. An orphaned box collider is left on the gameobject, which I'd like to prevent, as ScriptA and ScriptB might fire across many objects across a gameplay session, needlessly leaving many orphaned box colliders.
I suppose any other scripts requiring the box collider will prevent its destruction ("Can't remove BoxCollider because YourScript (Script) depends on it"), so I can have each script that destroys a component that requires the box collider to try/catch an attempt to destroy the box collider, too. That has its own pitfalls - what if the object naturally had its own box collider to start?
For the case where ScriptA adds the only component that requires it, how would one later tell what required components exist due to the component being destroyed without a custom framework built around it all?
Is there any way to introspect the RequiredComponent attributes of a Component to see what dependencies exist?
Or, would conventional Unity wisdom indicate that leaving "orphaned" box colliders that are triggers all over the place has negligible performance impact?
Your best bet is to use something else to govern the collider. I'd suggest another little script who does nothing but figure out whether his object needs a collider or not.
