|
|
|
 |
Reply From: |
RenenerG |
Hello Minwaabi,
It sounds like a basic question about physics and collisions. I would suggest you to read the chapter ‘Physics introduction’ from the docs.
Do I need to have them both be Bodies and Areas?
Usually not. For example, regardless of whether you developing in 3D or 2D:
An Area2D can detect collisions from nodes, which extendsCollisionObject2D, like KinematicBody2D, Area2D or RigidBody2D. Check the physics introduction, which I mentioned before.
Which should be the child of the other?
The collision detection of CollisionObject’s are not hierarchically dependent.
Any other suggestions on how to set this up would be appreciated
Here is a simple example scene:
– Node
------ KinematicBody2D
------------ CollisionShape2D
------ Area2D
------------ CollisionShape2D
A few things in order to get that work:
- The
Node has a script attached to it (Where your needed logic with the water could be)
- The property
collision_mask of the Area2D matches the value of the property collision_layer of the KinematicBody2D (usually they do by default)
- The
Area2D’s signal body_entered has to be connected to the Node’s script.
- And of course the
KinematicBody2D has a script, in order to move it over the area (like you already have, or just place the two collision shape on another and hit play)
- Do not forget to set up the shape of the
CollisionShape2D
At the end:
If you connect your Area2D properly. You will have a method called something like _on_Area2D_body_entered in your Node’s script. THERE you can react with your provided game logic.
For the signals, i suggest you to look again at the docs, chapter Signals.
Hope I could help you a little bit 
Thanks for the response.
I’ve read those which is partially where my confusion came from. So does Rigid/Static/Kinetic Body’s “On_body_entered” function effectively the same as Area2D’s “on_body_entered”? From the docs, it sounds like they functioned differently. (Area 2D says it emits when the areas overlap, Body2D when they come in contact).
Also, your simple example seems to be the same part of the problem I already understand. I think what I don’t know how to do (or don’t know how to do well) is the first part of the problem: stopping the player from entering the water until they confirm they want to enter the water. Effectively the water should act like a wall until the player confirms they actually want to enter the water (player and water should not overlap before confirmation). I know how to make the water act like a wall (use bodies) and I know how to make it act like a floor the player can walk/wade/swim on (use areas), but I don’t know how to do both for the same object. Does that make sense?
Minwaabi | 2019-02-19 19:13
So does Rigid/Static/Kinetic Body’s “Onbodyentered” function effectively the same as Area2D’s “onbodyentered”?
It depends. They do not have to be the same, only because they have the same name.
Methods and signals are two different things. I think you are a bit confused that the name of the auto-generated method sounds similar to the signals name, for instance "_on_Area2D_body_entered()" and the signal "body_entered". In fact, the KinematicBody2D and StaticBody2D does not provide this signal. But the Area2D is capable to detect these type of collisions, when entered or exited.
The functions name could be different. you can even think of a name yourself. For example name it "_my_collision_method(body) instead of "_on_Area2D_body_entered(body)" .
The important thing here is that you connect the Node’s signal to your provided method.
To archieve this, you can either connect it through the godot’s interface under the “Node” tab or doing this by code in the script, where your "_my_collision_method(body)" is, with something like my_Area2D_Node.connect("body_entered", self, "_my_collision_method")(in your ready method).
This will connect the Area2D node’s signal body_entered to the node, where the script is attached to (self). The method _my_collision_method will be called, when the Area2D fires his signal.
From the docs, it sounds like they functioned differently. (Area 2D says it emits when the areas overlap, Body2D when they come in contact).
Yes they act differently. KinematicBody2D does not provide a signal body_entered.
For example twoKinematicBody2D’s should not be able to “enter” the collision shape of another body (provided they are able to collide, see collision_layer). They mostly handle their collisions with other bodys with their build-in methods, like move_and_slide or move_and_collide via code.
So if you want to stop the KinematicBody2D, you can do something like this:
# Emittet from an Area2D node.
# This func is on a script on another node.
func _on_Area2D_body_entered(body):
# Is the name of the KinematicBody "Player"?
if body.name == "Player":
# Does the script of the body has a method called "stop"?
if body.has_method("stop"):
body.stop()
# Call an UI element
# Do other stuff ...
I know how to make the water act like a wall (use bodies) and I know how to make it act like a floor the player can walk/wade/swim on (use areas), but I don’t know how to do both for the same object.
If your water is from type StaticBody and your player from type KinematicBody2D, they wont be able to call a method, like you already trying trough signals.
A simple solution approach could be to add an Area2D node to your wall (or water), which can detect the player’s KinematicBody2D. Then you connect the Area2D’s signal body_entered to the parents script, like I mentioned in my first answer.
Now: Drag the CollisionShape2D’s edge just a little bit out of the wall, where the player should be detected. Then you can detect the player from the wall, and decide, if you want to make the wall (or water, or whatever) ‘walkable’ or not.
Does that make sense?
It depends. Think of a shooter. There you have player which is a KinematicBody2D node (or 3D). And the player provides a “hitbox”, made out of Area2D nodes, which in turn can detect bullets made out of KinematicBody2D’s. So you can use both. The difference here is (again), how you connect the signals to which node. But this is more your basic game design. First it is a good idea to learn the basics. It should not bother you anymore, if you make it through the tutorials.
So, yes. In your case as you can see. It makes sense :-). It lies to your creativity, how to build up your scene and connect all these types of nodes to work together.
RenenerG | 2019-02-19 21:23
Thanks, this was very helpful.
Minwaabi | 2019-02-21 18:43
