Movement Utility - Can see object with UCC

[Haytam95]

Hi

Today i've been working with the AI of the enemies in my game. It is going nice (BD is a great tool), but i have found a bug in the conditional Can See Object of the Movement Pack.

My character was being detected even behind the walls, so doing a little debugging i found out the problem:



(MovementUtility, line: 114) This function will return the targetObject if the raycast hits him (Or a child / parent gameobject). Null otherwise.

Then a little above (Line 104)



You can see that, if the "LineOfSight" returned null (So the raycast hit another thing or simply nothing), then it will check if the player has a collider. If not, then he assumes than he can see the object. (UCC collider is in a child component called Coliders)

The problem is, that LineOfSight doesn't return another gameobject that isn't the target. So if the targetGameobject doesn't have a collider it will assume that he can see it.

I resolved the problem by removing the else statement as a patch. Probably the best solution is make LineOfSight return the gameObject that have been hitted and check if the returned value is targetObject. Then if it's null, check if the target object has collider.

That's it!

 

[Justin]

Thanks! One of my next tasks is a Movement Pack update so I will take a look at this.

 

[Justin]

(MovementUtility, line: 114) This function will return the targetObject if the raycast hits him (Or a child / parent gameobject). Null otherwise.

I am looking into this now. In the case of UCC shouldn't it return the target object because the collider is a child of the target object?

 

[Haytam95]

The trouble is, when the raycast hits another thing (For example a wall).

Because LineOfSight only returns the target object and not the wall, then the code assumes that the raycast is clean and then attempt to check if the targetObject have a collider. If not (UCC is the perfect example because the collider is child of the targetObject), then it assumes that the view is clear which is not always true, because LineOfSight ignored other gameObjects that weren't the targetObject by returning null.

I don't think that checking if the targetObject as a collider is wrong, I do think that LineOfSight should return the object that the raycast collide always (Even if it's not the targetObject)

 

[Haytam95]

In the case of UCC shouldn't it return the target object because the collider is a child of the target object?

No no, I think this is great the way it is, keep it.

The trouble is with other objects that aren't related to the targetObject

 

[Justin]

Because LineOfSight only returns the target object and not the wall, then the code assumes that the raycast is clean and then attempt to check if the targetObject have a collider. If not (UCC is the perfect example because the collider is child of the targetObject), then it assumes that the view is clear which is not always true, because LineOfSight ignored other gameObjects that weren't the targetObject by returning null.

In the wall example wouldn't the nested Line of Sight return null because the wall isn't part of the target object, and then the upper else if (GetComponent...) return false since the wall has a collider?

 

[Haytam95]

Noup, it isn't working that way. Here i have a video, let's debug it together.

Edit: Re-uploading video

Check this three gameobjects in the video:

- "Escuela" is the building (School in english).
- "Cristian_With_Jacket" is the AI agent
- "Carla" is the player

When I start and the player is inside the AI range cone, then LineOfSight is being called.

Then because of LineOfSight returned null, the code directly attempted to check if "Carla" had a collider, ignoring completly the "Escuela" gameobject

Because not (luckly, otherwise it would be difficult to find out this bug), then it returns that can see Carla.

 

[Haytam95]

Here is the video:

Debugging starts at 1:15

And here is a screenshot where were both characters after the debugging:

 

[Justin]

I see now. Thanks for the details! Working on a Movement Pack update and I'll have this fixed in that.