Simply put: We have 2 GameObjects, Old and New.
GameObject New gets instantiated but GameObject Old is inside it’s collider.
How do I delete GameObject Old?
Sorry if I explained that horribly 
Do you mean, “how do I detect that Old is inside of New’s collider, so therefore it must be destroyed?” In that case I guess scan all potential objects and see if their position is contained within the collider, perhaps with a raycast from some known not-inside-collider point.
Or do you mean, “I’m in the editor, I put a larger object around a smaller object, how do I get at the smaller object to select it and delete it?” In that case the answer is to use the hierarchy to find it, or enter wireframe mode and pick at one of its pieces of wire.
Three general ways.
- Have NewGameObject destroy OldGameObject (like a ninja).
- Have OldGameObject self-destruct when NewGameObject is created- this can because OldGameObject in some part responsible for the Instantiation of NewGameObject, or through collision detection like you seem to want.
- Have some sort of third party manager that can see NewGameObject’s creation (or is responsible for it) and which then kills OldGameObject in response.
I’m personally a huge fan of self-destruction. All things being equal, I believe that objects should “take care of themselves” whenever possible, and that includes their own deaths. Object A may know that it wants to kill Object B, but it doesn’t really need to know all of the particulars of Object B’s existence. TryToKill() might be called, but Object B knows itself best, and can simply respond “no thanks, I won’t die today”.
1 Like
Yes I mean the first thing you said btw
Lol liked for the funny answer ^^ Ill try to recreare your
idea. But what do I use? OnTriggerEnter()? I think that only works when you enter it not when you are instantiated ontop of it so what do you think?
I think it depends on the level of accuracy and versatility that you require. If OnTriggerEnter() indeed doesn’t trigger when another object is instantiated around/inside of its collider bounds, then an explicit check would be necessary. If you’re only looking to check against a specific object (like the player) then you can accomplish this with a GameObject.FindGameObjectWithTag() call and comparing the colliders/positions directly (Collider.ClosestPointOnBounds() is incredibly useful in this case, so keep it in mind).
If you need something a bit more versatile and which can handle multiple possible objects within the bounds of the collider, then perhaps something like Physics.OverlapSphere() might be better.
This would only need to be run in the Start() function of the newly Instantiated object btw, as past that point you can rely on the OnTriggerEnter() function normally.
Ok I tried using OnTriggerEnter() but that does indeed seem to require an “Enter” of the collider so it doesn’t register spawning inside another collider. How do I do this
?
I don’t know the particulars of your situation- what exactly is being created and what exactly are you trying to check that might possibly be destroyed? Is the newly-created object’s collider spherical or does it have a different shape? Are you checking to see if a specific object is within the bounds, or ANY objects with colliders, regardless of what those objects might be?
I am making a randomly generated tunnel and sometimes the tunnel does a full 180 degree turn by random generation and goes back into itself. I want to delete the old part of the tunnel that it is colliding with so the tunnel can’t stop and has no end.
Out of curiosity, can you change OnCollisionEnter() to OnCollisionStay() and have it detect the collision there? It feels like while the former might have a specific condition for triggering, the latter would be triggered on any intersection regardless of when that intersection occurs.
Here is a quick clip to help you better understand my problem with the tunnel when it decides to generate into itself.
Nope that didn’t fix it. Any ideas?
You can use Physics.OverlapSphere() in the Start() call of the new section, passing in the current position and a radius to detect other colliders. You can use a layerMask as well, which is an int value that corresponds to a layer ID (it’s easy to get just using the static method LayerMask.NameToLayer(“Name of Layer”) or some such thing).
I haven’t used OverlapSphere() before, but you’d have to make the radius large enough to touch or surround colliders of sections you want to be able to get rid of. Afterward you’re left with an array of GameObjects, which you can loop through and check the tags/names for and destroy the ones you want.
Alternatively, you can make it so that sections have an automatic self-destruct after x number of seconds and time it so that “turning back on itself” would take longer than the time necessary for that section to get destroyed. Self-destruct timers are incredibly easy, and to make sure it doesn’t occur while you’re stationary inside of it, you can start the timer on OnTriggerExit() or something.
This is not exactly the best solution but I’ll take it for now and just try to come up with a better one later. Thanks for all the help
For the tunneling you are showing in the video above, I assume that the player cannot turn around and run back more than a certain distance, or else you’d have problems in any case. If you choose, say, three tunnel segments max, then you can cap that back one with a blank wall that spawns at the same instant the next chunk (three pieces ahead) spawns, and then blow away anything older than that.
The right way to do this is to have a grid representing what areas of the world (at a granularity appropriate to your tunnel chunk size) have been “used,” and then don’t turn towards them. Of course you could still paint yourself into a corner, but that gets into a whole other area of applied graph theory and spatial subdivision and path choice for optimal area fills…