I have a location consisting of several connected rooms and some enemies chasing me. But when bots are walking very close to walls I can see their hands passing through the walls, despite both bots and walls have colliders and enemies cannot go through them. Is there any way I can create a border or something to prevent it?
It sounds like #Heisenbug is probably correct.
I would attach a secondary collider to your model, most likely a box (for speedy processing) and call it personal_space. This way you can control how much space they give themselves from walls and such while still allowing them to get closer to the player and other special objects.
Related
Kinda what the title says, I have a "wall" made out of multiple segments specifically for modular purposes. I have a contactTestBitmask that forces the player to stop moving in the direction of the wall once collided, but, if you slide along the wall to another segment, the player just rolls straight through it. I cannot do a collisionBitmask as the player runs fast enough to "phase" through the walls. I also cannot do collision as my camera and lighting are also dependent on the player's movement and position, and will not interfere with the walls (I think). If anyone could help point me in the right direction to allow me to make solid modular walls, I'd greatly appreciate it.
Figured out the source of my problem, contact IS happening, I just have wonky flags and the system doesn't like that. I need a contact currently happening method, I guess
In unity 5 I am having an issue with certain collisions. I made a basic maze-like game where the player controls a cube across platforms (made from other cubes). In certain areas, two or more of the platforms touch so the player can get to different areas of the level. The problem with my collision happens at these intersections. The player will seem to get stuck for no reason and they would have to back up and get a running start in order to get to the other platform. I went through everything and made sure they are lined up perfectly in the unity editor but nothing seems to fix this.
Any advice would be greatly appreciated .
EDIT: all of my objects are using box colliders
A common (and good) practice is to use a Circle collider on the bottom of your character object in conjunction with a Box collider.
For Example:
While this will likely fix your issue, the source of the problem is probably using many small tiled cubes each with their own colliders. A large amount of tiled objects with colliders most likely cause performance and collision issues.
I am making a 2D Brick Breaker game in Unity.
I have an issue with the scenario when ball hits in between two bricks. I have BoxCollider2D attached to all bricks and a CircleCollider2D attached to the ball. When the ball hits between 2 adjacent bricks, it bounces back in the same direction as if it hit the edge of the brick. There is no edge in between, but two adjacent bricks form a continuous surface. So, the ball should bounce off of the surface (in other direction) instead of bouncing back.
Anyone knows of any solution to tackle this problem? I asked this in the Unity Physics forums but didn't get any answer, so checking if anywhere here might have had this issue.
Thanks,
Mukul
I am guessing this could be the problem:
When your ball is hitting the bricks with a strong force, There is a chance it might move one of the bricks by a very very slight distance, even if the mass of the brick is much heavier.
This movement might cause an uneven surface, which is why the ball bounces back in the same direction.
Try adding a Rigidbody Component on every brick (if you have not done it already), and set its isKinematic property to true.
Let me know if this solves it.
Way 1:
Use one box collider for the wall, but not for every single brick.
This will fix your issue + will optimize your project.
Way 2:
You need to build wall programmaly and colliders in this case must be without spaces between them. This must fix the issue.
Way 3:
Make your own hitting wall logic.
OnColliderEnter you need to get balls velocity.
OnColliderEnd you need to set manually velocity.
I've started learning sprite kit and I think I've got the basics but now I'm struggling with something.
I want to create a game that has a 'Streets of rage' type feel to it whereby the user can move up and down, but isn't jumping, they're still on a 2D plane. But I also want them to be effected by gravity e.g stairs etc. like the following picture.
Am I right in assuming that I should have my background image with colliders around the blue and brown edges, and then create a physicsbody collider located at the feet of my player/players so that it looks like they can move against the background, but when their feet reach the top it would stop?
Could I then place other obstacles like rocks etc on that path that they would be able to collide into, but that could also sit over the path and the sky? How would I handle the fact that these could be constantly colliding depending on the position?
I appreciate there isn't any code here, but I'm trying to understand the concept around this before I jump in coding a solution.
Thanks
I would use a categoryBitMask to separate the different planes of objects.
And I would play with collisionBitMask/contactTestBitMask depending from the plane the player is in, in addition to the z-order.
Thus you can have a rock that collides your player if they are both in the same line else the player would walk behind/front.
I have a Unity project in which there is a 2D game world that consists of static colliders to make the geometry solid to the characters that inhabit it. The player is a dynamic collider (with a non-kinematic rigidbody). There's also an enemy character that is also a dynamic collider. Both characters walk over the floor and bump into walls like I'd expect them to.
What I want to achieve is that the player and enemy are not solid to each other, so they can move through each other. I achieved this by putting the enemy and the player on separate layers and setting the collision matrix so that these layers do not collide with each other. The problem I'm having now, however, is that I do want to detect whether or not the enemy and the player ran into each other. I added a trigger collider to the enemy character, it's on the enemy layer which means it doesn't detect collisions with the player.
I thought of making a sub-gameobject for the enemy, put it on the player's layer, add a rigidbody and trigger collider to it and use that to detect collisions between the player and the enemy, but it feels so convoluted that it leaves me wondering if there isn't a more elegant solution for this.
Edit (2020-05-26): Nowadays you can tell the engine to ignore collisions between two given objects. Kudos to Deepscorn for the comment. Will leave the rest of the answer unchanged, and read with that in mind.
Yes, you need to create a child GameObject, with a trigger collider, and put it in a layer that interacts with the player layer.
No, you don't need to add a Rigidbody to the new GameObject, the parent's rigidbody already makes it a dynamic collider, so you will get OnTrigger events.
As a side note, just to keep things organized, if you create a child of the enemy don't put it in the player layer. For example, in the future you might need to disable the player's layer collision with itself. Furthermore, if your player interacts this way with many objects, I'd put a single trigger on the player instead of the enemies, on a separate PlayerTrigger layer, just to keep things simple.
Isn't there a simpler way? Not really. You definitely need non-interaction between the player and enemy colliders, but some kind of interaction between them too. So one of them needs to span two layers, or the whole interaction would be described by a single bool. The physics engine processes lots of information in one go, so you can set all the layers and collisions you want, but during the physics loop you have no further control on what happens. You can't tell the engine to ignore collisions between just two objects. Having only 32 layers, and having them behave in the rigid way they do are actually heavy optimizations. If you are concerned about performance for creating another layer, disable interaction between layers you don't need, like the trigger layer and the floor and walls, or layers that don't even touch.
Your alternative is doing it all by code, which is even less elegant. A single child capsule on the player doesn't sound that bad now, doesn't it?