Teleporting onto a trigger

Hi, so at the moment I have four-game objects that spawn monsters in and then gets placed to a new ‘x position’, I’m trying to get it so that when the two spawners overlap they become slightly transparent but using OnTriggerEnter2D isn’t working.

Here’s my code for OnTriggerEnter2D:

private void OnTriggerEnter2D(Collider2D collision) {
        if(collision.gameObject.tag == "Spawners") {
            print("Trying to change color");
        }
    }

It doesn’t even call the print method which I’m trying to achieve before I start trying to change its alpha value.

Colliders/triggers without rigidbodies aren’t being tracked by the physics engine. If they don’t have rigidbodies yet, and you’re moving them around, give them one, and set them to IsKinematic if you don’t want physics actually pushing them about.

[Edited to avoid giving bad information]

1 Like

Thanks, I will try all of above and hopefully, it will work. :slight_smile:

Perfect, it works now as soon as I put the rigid body onto it. So to understand it better, box colliders are an outside shell of the object, and a rigid body’s collision is the entire object?

Also just to say, my objects are the same size and most of the time was always on the edges so I thought box colliders would work.

Not quite. They’re not two versions of the same thing, but two different things that work together. The rigidbody says “this object moves and can collide with things, so it needs to be tracked by the physics system”, while colliders say “this is the shell that determines collision/trigger areas”. A bullet needs both, a moving character needs both, but static / stationary colliders and triggers don’t need rigidbodies, because they don’t move, so they don’t collide with anything- things (with rigidbodies AND colliders) collide with them.

So a spawner that isn’t being teleported around doesn’t need a rigidbody, but yours do. Hope that makes sense. :slight_smile:

1 Like

Yes, thanks for the reply! :slight_smile:

Suggest doing more searches on each of these things. You should find lots of discussion on them all. The replies here seem not-quite-right. For example triggers can detect things that just appear inside them, and continuous detection has nothing to do with that.

Technically, isn’t the best form / fastest version of this sort of check these days to use Physics.OverlapSphereNonAlloc?

And do I have it right that no rigidbody is required on this?

Just tested, and you’re correct. I remembered a rash of problems a few years ago involving teleporting and spawning inside of collider areas without colliding or triggering, but it looks like that’s not an issue any longer- or maybe it never was and that was just bad info spread even then.

Either way, thanks for pointing that out- I’ve updated my response to avoid giving bad info to people who find this thread later. It’s worth noting that my initial reply is still valid in the case of an object that needs to move so fast all of a sudden that it may not enter a trigger area at all, but rather appear on the other side of it, and you still want to collisions to occur based on the teleport path from A to B. But as that’s not the case here, it’s irrelevant (except to save a bit of pride on my part ^_~).

Correct- if you’re doing the check more than once anyways, it’s fantastically better than the normal Overlap methods. If it’s an event that’s unlikely to recur though, then the normal approach is probably best because it gives you the exact number of overlapping colliders instead of you pre-calculating your best guess. Also worth noting that the NonAlloc method is also really really useful to feed tiny pre-initialized arrays if you’re only ever interested in 1 or 2 results, as it can seriously cut down on the amount of work that the function does internally (or so I’ve heard).

I actually got into an argument with a moderator on the Answers site just the other day about a similar subject (the new NonAlloc method for RaycastHit2D.GetContacts). He thought having an array that’s too small to hold ALL results would cause an error, and said people shouldn’t pre-initialize the array. In fact, not pre-initializing the array defeats the purpose, and causes an error itself, and any array size works if you’re only interested in that many returned objects. He deleted his answer, then proceeded to downvote mine and close the topic in a tantrum response. Doubt he’ll remember it as one of his better moments.

2 Likes

Yeah, I gather that if the number of colliders collected by the overlap exceeds the provided array, whatever doesn’t fit in the array is not calculated or stored.

Probably another effective method in many cases would be to do a distance calculation.

1 Like

So how come your previous solution worked? If you can explain that would be great. :slight_smile:

You didn’t have a rigidbody- two objects, neither having a rigidbody, can’t collide with eachother. You need to have a rigidbody AND a collider on any moving object in the scene that needs to collide with other objects. Only static, immobile objects can have only a collider / trigger.

I only removed the part about collision detection modes and teleporting into trigger/collider areas without ever intersecting the outer shell, so everything that’s still in my replies is accurate.