How to prevent RigidBody from being inherited by child?
I'm making a character in a top down RPG which is able to make a slashing attack to kill enemies(it has got a collider with the same shape as the motion of the attack) , but when it makes one against a wall,it is immediately pushed away from it. This is the current hierarchy
-Player
-Slash
-Weapon
-WeaponSprite
I think this happens because Player has a rigidBody2D component attached and the slash gameobject inherits it from its parent. I want the Slash gameobject to keep its collider component but not the rigidbody2D,do you know a way to do it?
Image of the Slash gameObject's sprite and collider
The weapons isn't quite "inheriting" the rigidbody. A parent rigidbody gets all child colliders. Take a look at "compound colliders" in the manual. It should make a lot of sense why they work that way. You might want the weapon to be a a trigger. Those are a type of non-solid collider.
Answer by swanijam · Nov 07, 2018 at 04:11 PM
The player object and the weapon should have different rigidbodies and be on different objects, with different layers. Set your Physics Layer Settings to disallow collision between weapon the and the wall.
In unity, A rigidbody with multiple colliders has what's called a "Compound Collider". Any collider on a child object of the rigidbody is a part of that objects collisions. However, if you want an collider to be a child, but interact with physics separately, you just need to add a new rigidbody to said child.
If both have a rigidbody, you'd need some sort of joint (a hinge?) connecting them, or else the weapon will fall like it was dropped. And it would still push the player back when you swiped something solid (depending on the masses. A cute trick is making the player and sword weight 10,000 kilos, that way it smashes any other rigidbodies aside).
what if one is kinetic?? something tells me that is of some importance here too.
Answer by TonicMind · Nov 06, 2018 at 10:37 PM
First off, you should when asking questions provide as much detail as possible. Screenshots and/or code would be great.
You say the slash class inherits the rigidbody 2d from its parent. In object oriented programming you are supposed to design your classes such that they meet the requirements for your software (or game for that matter). Every class ought to have an explicit purpose. It should follow the SOLID principle, and utilize encapsulation, polymorphism, and opacity of data.
The rule when defining a class is to ask yourself (assuming you need it): "What IS it?" and the answer will guide you on both its methods and its data members.
That is just some background advice.
To prevent your slash gameobject from inheriting the rigidbody2d object, you must move that field (the rididbody 2d) into the child class. The rest of your code is going to need retooling, if you've got any usages or references to that rigidbody2d. Additionally, something very improper you could do is just remove the rigidbody2d component from your slash object. Write code that uses the rigidbody2d not execute via a bit of code like so:
if(rigidbody2d != null)
{
//Do your thing
} else
{
//Do nothing.
}
Thanks for your answer,I'm sorry that the image link(tried to fix it)and the hierarchy weren't enough. I posted so little info because I hoped there was some kind of workaround so that I woukldn't have to edit all the rigidbody references.
I tried the first solution you suggested,but since I use the rigidbody2D to move the player(by applying velocity according to the input),making a child object of the Player with rigidbody2D and Collider2D made the collider move on input but without the Player Sprite following it.
This is how I edited the hierarchy
-Player//now without rigidbody and collider
-Slash
-Weapon
-WeaponSprite
-PlayerHitBox//with collider2D and rigidBody2D components
so I tried to assign the sprite's transform to its child's transform but the Player's movement got messed up and was super fast(maybe because of the child following its parent and viceversa)
I think you're confusing two different things. Unity's physics system only cares about the arrangement of items in the hierarchy and which components they have; like whether the weapon is a child of the player, or not, and how many things have rigidbodies. $$anonymous$$oving around fields or redoing classes might make later coding easier, but it has no effect on game physics.
Personally i look at the Hierarchy -> H like an execution order of sorts, or a stack of papers maybe. Where the bottom of the pile is at the top of H and the top of the pile is the bottom of H. What i mean by this is, what ever is at the bottom of H will show in your scene over everything else in a 2d game. And UI stuff too. so if your codes are fine then your hierarchy shouldn't change around objects in the H, only add and remove clones of prefabs. These other objects usually spawn at the bottom of H if not set to attach to a parent when created. This would mean that if it were a GUI element it would spawn over top of all your other GUI.HIDING . To prevent that we add it to specific parents in the list so it doesn't hide other UI. The only reason i bring these things to attention are because i notices you have a top down 2d game by looks of your picture. I myself am making a Pokemon World Fan (Clone) Game, and use many similar aspects as you, also many different.
Your answer
Follow this Question
Related Questions
how to fire my player out of a Cannon? 0 Answers
A box collider 2D (Is Trigger marked) stops my player from moving which has rigidbody 2D 1 Answer
2D Colliders don't actually touch, causing problems 0 Answers
Adding rotate-to-mouse code causes issues with Relative Joint 1 Answer
2D prefabs(Enemy) overlap issue 0 Answers