2D - Why is my seeker game object with AI Lerp moving thru colliders?

My scene is in 2D. I have a player game object being followed by an enemy game object. The enemy has a Seeker script, AI Lerp script, and a Simple Smooth Modifier script. The enemy has a Rigidbody2D with a non-trigger CircleCollider2D. The scene also has a group of squares each with a non-trigger BoxCollider2D as obstacles.

As the enemy follows the player, it enters the box colliders, sometimes even reaching the middle of the collider. While the enemy is obviously trying to avoid the box collider obstacles that I’ve set up, there seems to be no collision taking place between the obstacles and the enemy. When disabling the AI Lerp script and attaching a simple movement script that moves the enemy on a path through the colliders, collision once again works in the sense of all movement being stopped by the box collider obstacles.

In going through the AI Lerp script, I’m not sure what is causing the prevention of collision. Is it something to do with raycasting as opposed to using Rigidbody2D collision that my scene normally uses?

Here is a GIF of the action and two screenshots of my setup.

The player is the black silhouette, the enemy is the ball, the purple boxes are the box collider obstacles.

Hi

I think the SimpleSmoothModifier that you have attached to the agent is smoothing the path a bit too much, causing it to intersect the walls.

Hey Aron, thanks for the response!

It’s not the SimpleSmoothModifier script, as removing that script causes the exact same issue.

And it’s not like the collision just doesn’t work, as when adding a Rigidbody2D to the boxes, the boxes are moved by the enemy. The player can also run into the enemy ball and be moved by it. However, the boxes are moved a bit awkwardly, like the seeker ball does not fully respect the boxes’ Rigidbody2D settings (moving them too strongly, for instance).

Could it be related to the way that movement is handled by the AI Lerp script? I noticed that it simply sets a new transform.position in Update, probably forgoing the Unity physics engine. I normally use Rigidbody2D.AddForce in FixedUpdate for the movement in the game, as is standard for physics-based Unity projects.

Somehow, I think that the answer lies somewhere in the physics handling.

Hi

The graph looks correct, so it is not that. Possibly you will want to increase the erosion setting or the diameter setting to have a slightly larger margin from the walls, or you might want to turn off ‘cut corners’.

Your sprite looks misaligned however. Are you sure the center of the sprite is at the pivot point of the character?

Hello.

“Cut corners” does not seem to affect it.

The pivot is at the center, but my sprite cannot be always centered, as it is part of a spritesheet with 64 x 64 cells and the sprite is at differing positions depending on the action. How would this affect it, though? (It may also be the GIF editing that is throwing you off.)

An erosion setting of greater than 0 is too extreme. But even if it wasn’t, I understand how it should in theory resolve this issue. But I still have a concern about this: how is the AI Lerp script allowing the seeker object to bypass those colliders? How is collision itself affected by using A* Pathfinding Project?

Thanks!

EDIT: Found the diameter setting, though it requires sphere collision. Also, it works based on the same principals, I think, as the erosion setting and I’m still wondering about how collision is bypassed in the first place.

Your circle collider is definitely not centered on the pivot point of the object (which is what will be used for following the path). It has an offset of (0.5,0.5).

The AILerp script is intended to follow a path exactly, it does not use physics at all for movement.

Thanks! You’re right about the pivot not being centered being the cause of the issue (I thought you meant the character’s pivot, not the ball’s). Unchecking “cut corners” with keeping the pivot at the center seems to resolve it completely.

I’m wondering: how do you negate physics when using this script? Can you foresee any engine-related problems by doing so, especially when other parts of the game do use Unity physics?

It uses Vector3.Lerp(…) instead of something like RigidBody physics. It shouldn’t cause any problems, as they are all supported features of Unity.

Thanks for the explanation.

1 Like