CanSeeObject Target cannot have a Collider

[Kade333]

I am unable to attach a collider to a target that `CanSeeObject` is searching for because the method `MomentUtility.cs/WithinSight` does the following check on line 133: `(GetComponentForType<Collider>(targetObject) == null && GetComponentForType<Collider2D>(targetObject) == null)`.

I would like there to be a toggle on the task that disables this check.
Wither or not the target object has a collider on it should not prevent it from being seen- because the object with the collider IS the object that is being seen.

 

[Justin]

So you don't want to do the obstruction check? Only use the angle/distance to determine if the object can be seen?

 

[Kade333]

I'm not sure it is an obstruction check- that sounds like "something is in the way of the target".
But, this collider belongs to the target itself- so that means it is obstructing itself? Which does not make sense.
The target has already been found, so I should be able to navigate to it, regardless of if it happens to have a collider.
It's not even checking if the collider is active or if "IsTrigger" is set to true- so I'm not sure what this check is supposed to do.

 

[Justin]

But, this collider belongs to the target itself- so that means it is obstructing itself? Which does not make sense.

The raycast is sent from the object's pivot position outward so it will not hit itself.

The target has already been found, so I should be able to navigate to it, regardless of if it happens to have a collider.

Can See Object is only responsible for determining if an object can be seen, which includes the obstruction check. It does not handle any navigation. If the object has already been found then there's no need to use Can See Object.

It's not even checking if the collider is active or if "IsTrigger" is set to true- so I'm not sure what this check is supposed to do.

If the collider is disabled then the raycast won't hit it. The raycast will always ignore triggers.

 

[Kade333]

So, should I not be using CanSeeObject to find the object?
I am relying on the CanSeeObject task to populate ReturnedObject by searching for what things with a specific Tag.
It then seeks the returned object and acts on it.

 

[Justin]

That is the correct use case. I guess I'm not following your usage. So you've found the object using Can See Object and this object has a collider, but then later this object no longer has a collider and you want to find it again?

 

[Kade333]

Sorry for the confusion.
Here's a detailed explanation.

I have NPC heroes that search through a dungeon for monsters and fight them.
These Hero objects have a RigidBody and a Collider. They use A*Pathfinding to move around the dungeon.
A Monster object has a tag of "Monster" and a 2D collider (set to IsTrigger) on it that is used by the hero to fight them (It does not have a non-trigger collider).

1. The Hero Behavior triggers the CanSeeObject task.
2. The only `m_DetectionMode` is `DetectionMode.Tag`- so the task uses `GameObject.FindGameObjectsWithTag` to loop over the available objects with that tag.
3. `MovementUtility.WithinSight` is called to check if the object with that tag is close enough and not obstructed.
4. In `MovementUtility.WithinSight`, `LineOfSight` fires out a ray trace to see if there is anything inbetween the 2 objects.
5. If there is nothing between the 2 objects, it checks if the target object has a Collider of any kind. If it does, then it ignores the object.

Without editing the code, the only way for the targetObject to be considered seen is (1) to put a collider on it that is not an IsTrigger (don't want to do this for other reasons) or (2) to not have any collider on it at all.

I'm sure there is some kind of use-case for ignoring the target object if it has any kind of collider on it (regardless of it's type or if it is even enabled)- but it does not fit with how things are set up.

 

[Justin]

Ok, I see. So it's not that the object doesn't have a collder, it's more that the object's collider is a trigger and you want to detect that. I think that the best solution would be to expose QueryTriggerInteraction to the task so you can detect triggers as well. Does that sound like it would work?