Allow NavMeshAgents to walk through each other - unity3d

I'm looking for a way of setting up my humanoid NavMeshAgents to walk through each other.
I don't want them to collide with one another as there will be several players in the map and they'll need to just be able to ignore one another.
They should still be able to avoid the baked NavMesh obstacles but just ignore each other.

So I just ran into this exact problem. Googling found older or very complicated solutions. I finally found an option under NavMeshAgent --> Obstacle Avoidance --> Radius. The trick in my situation was to set the radius to something very, very tiny; relative to the actual size of the GameObject. Then the objects can pass right by (thru) each other.

You should take a look at Unity's Layer-based collision detection. You'll need to set your non-colliding humans' layers to the same layer and then uncheck the box where it meets.

Related

Recommended strategy for overriding certain Rigidbody collisions in Unity?

I'm looking for a little newbie advice on gamedev strategy and/or approach. I'm working on a game that uses Rigidbody physics in Unity and I've got a character interacting nicely with physical objects in the game world. The thing I'm trying to work through is that there are certain physical interactions that I want to control, but my own attempts to control them are conflicting with what Unity is already (correctly) doing.
For simplicity, let's just say I've got a Rigidbody-based player, and when certain Rigidbody-based objects collide with that player, I want to override where they deflect to. When I detect the collision and apply my own force with rb.AddForce(myForceVector, ForceMode.VelocityChange), Unity is also applying it's own force as a result of the same collision. I also tried setting the velocity directly with rb.velocity = myForceVector, which mostly works, but there are still situations where Unity applies force after I set the velocity so it's glitchy at best.
Other options I've considered are:
Use an additional, larger IsTrigger collision mesh to detect and handler the special type of collision I'm looking for before the actual collision occurs. That might work for slower speed projectiles, but likely will have the same issue for faster collisions.
Change the player to not being Rigidbody-based, which might work, but would require me to code a lot of the other interactions that are already working out of the box with Rigidbody physics.
Use RayCasting to detect when these special collisions might occur next and handle them before the actual collision. This is where I'm leaning currently.
Anyone have a recommended best practice for this kind of thing?
Thanks in advance!
The easiest way might just be to take full control. On the correctly timed press, disable the RigidBody and the Collider. Then just move it yourself to the target location. It's really hard to get precise control over a RigidBody -- every FixedUpdate(), it might be picking up force from collisions, and there can be many FixedUpdate() calls between Update() calls.
You could write a pretty simple coroutine using a Lerp() or Slerp() between the object's current and target position. That way, you could fully control how the object moves toward its target.
Just to follow up... I attempted to "take full control" as suggested in Alex M's answer above, but that ended up making a number of other things complicated in my specific situation. However, his comments about disabling the collider in the original question led me down a different path that ended up working well...
I ended up disabling the collider for the deflecting rigidbody upon impact and setting the velocity of the deflected body directly. That way, I was able to avoiding any additional force(s) applied from Unity while the collision was active. Once the deflected object was on it's way, I just had to reenable the collider.
Thanks, Alex!

NavMesh not including all the surfaces

I have a level made with pro builders and at that level there is an agent who attacks the player. The problem is that when i baked the navMeshSurface i did not include all the walkable surfaces. See the image below :-
I am now really frustrated with how to solve the problem, i tried nearly everything. I tried changing the layers and also tried placing other game objects over the area which are not baked. But, it did not work.
Please tell how can i include all the surfaces in the navMeshSurface.
make sure you have selected all the blocks, because if you didn't it will only bake the ones that are selected.

Unity ignore collisions on the same layer

I want to use Physics.IgnoreCollision to avoid bullets hitting themselves.
The bullets are spawned on layer 8. Why is this not working? How can you ignore collisions with everything on the same layer?
// bulletscript.cs
gameObject.layer = 8;
// maingamescript.cs
Physics.IgnoreCollision(8,8);
There may also be other objects on layer 8 that should also be ignored.
(for example, the player ship).
Why not use the handy dandy Physics Manager. Go to Edit->Project Settings-> Physics and set up the proper layer collisions.
Go to Physics Manager and un-check the layer with itself to avoid collision.
Troubleshot:
Unity bug, try to update to latest Unity 5.3.x (5.4 currently has nasty bugs)
Make sure the bullets and players are effectively in the wanted layer
The change in layer takes some time to take effect (few frames), since bullet are fast, you are probably encurring in that lag (so in the time the change take effect the bullet already hitted the target)
The best way is to have a Bullet Prefab that is spawned already in the correct layer, you can later customize that by changin graphics at runtime if you like, but to avoid the lag it should be instantiated already in the correct layer.
There is no need to go to physics manager, the OP already do the correct code equivalent to the physics manager. The real problem is that the GameObject should be already instantiated with the correct layer, because layer update may take some time to get effective.
Another workaround is to disable/reenable the collider.

Determine on which collider the collision has taken place

I have a gameobject with two sphere colliders attached. One has IsTrigger checked and the other not.
I want to execute different set of statements when collision occurs with different colliders. For example I want to play different sound for both different collisions. Is there any way to achieve it?
I tried OnTriggerEnter() but unfortunately it is called for both type of collisions since other colliding objects have triggered colliders. I just thought if we could somehow find out on which collider of the gameobject the collision has taken place we will be able to achieve it.
So is there any way to get through with this?
I have been using Unity for years and faced tons of problems like this, related to bad software design. I hope Unity guys will handle physics more carefully in future releases.
In the mean time, you can use Physics.OverlapSphere and Physics.CheckSphere to manually check if there is something that collides with your object. Remove the collider that you are using as a trigger and use these methods instead of OnTriggerEnter. This is a bit hacky, but this will do the job I think.
Make your colliders visible in the inspector (make them public or add [SerializeField] before it) and then tie in the colliders to the code that way.
Then, in your collisions, compare the colliding objects against your variables that are holding the colliders for you to keep them separate.
To detect for source trigger in OnTriggerEnter, you must use workaround with multiple gameobject hosting trigger and satellite scripts.
Allow me to link to my answer on gamedev SO:
https://gamedev.stackexchange.com/a/185095/54452

Can I move dynamic physics bodies using SKAction when only contact detection is needed?

I am looking at tutorial where things are defined like this:
planes are sprites with dynamic physics bodies
plane moving is done with actions by following the path
there is contact detection between bullet and plane
bullet is sprite and it has physics body set to be static (which is little unusual in my opinion)
Here is the link to tutorial for more information.
Questions:
When we use actions to move physicsBodies is there a difference how we set body's dynamic property? Because bullet is static but still there is no problem for movement.
When we have situation like this, where we don't need collision detection, but just contact detection, and we can't move sprites (enemies) by applying forces or impulses, what is a good approach? Is this approach correct?
I think this is nice way, but I would like to be fully aware what is really happening when we use this method and are there any drawbacks or possible problems.
There are posts on SO that suggest we shouldn't use actions for moving dynamic physics bodies. I am aware that we can't use this approach in every case. For example this would not work for moving platform with other object on it, because there would be no correct physics simulation between body on the platform and platform moved by action. But in cases like from this tutorial, where we only need contact detection for object that can be moved only by actions (moved along path) I suppose it's not a problem ?
static means that the body isnt affected by physics. That doesnt mean it cant be manually repositioned or moved. So if something is set to static, it participates in the physics simulation, but it isnt affected by it. Think of a plane hitting a mountain. The plane is dynamic, the mountain is just going to sit there even though its participating in the physics. But you could still move that mountain around manually using a position or an action.
Not totally understanding your question, but I'll give it a shot.
You can move physicsBody's manually (using position property or actions), but you need to ask yourself why you're doing that. You typically don't want to do it because they're bypassing the physics simulation. If you're forcing it to move around, what's the point of using a physics body in the first place.. right?
But if your physicsbody is something like a powerup that is totally static, and you just want it to move around in a circle using an action then thats fine. You probably just want to use contact detection for the bullet, powerup, etc without actually moving it around using physics. Nothing wrong with that.