Children not inheriting position of parent

Help
,
1

I have a rigidbody2d which im applying a force to, and i have a sprite2d and an area2d (with collisionshape child) all as children of the rigidbody2d. Why are their positions not being updated to the rigid body’s position? I’m looking in the remote viewer and the area2d’s position is always 0,0.

2

I guess the position shown in the remote viewer is their position relative to the rigid body which is also called local position. Their global position will be different. Try printing their global positions and see if it matches the global position of the rigid body.

1 Like
3

The output does show their positions being the same, however my area node doesn’t seem to be following my unit properly, in that i can only “select it” at the origin. Hmm

4

I don’t understand what you mean by you can only select it at origin.

5

I’m making an RTS, with a dragbox selection system that selects units within the ninepatchrect I draw out with my mouse holding down M1. Releasing M1 casts a selection to all units within that area.

I can succesfully grab my unit from the origin, (0,0), and your debug showed me that its area is indeed moving around, I believe, but I can only “select” the unit by drag selecting around the origin.

Would you like me to upload my project? As I have a couple questions and things I wouldn’t mind getting some assistance on, and it would probably help get us on the same page . :smiley:

6

Yeah, uploaded it so I can look throughit.

7

https://www.mediafire.com/file/pmjmek6z19srx8y/Space_Game.7z/file

here is the link to the download.

When you start it up, you should be able to hold M1 and drag a selection box around the builder drone placed near the center of the camera upon spawn.
You can then right click to move around or left click on the build option to spawn a solar collector somewhere, which it will move to build.

If you move the drone a bit from spawn, you’ll see that you can’t select the drone by dragging the box around its current position, you can only do it by box selecting around the origin.

Thanks in advance for the help, I have a couple other issues I’m experiencing but this one is the most puzzling

8

Any ideas? :smiley:

9

I checked out the project.

Issue

The issue stems from the drone scene tree and how InterfaceManager.cast_selection() checks what nodes are inside the drag box rect.

Drone

The drone tree looks like this

- drone: Node2D
  - RigidBody2D
    - Sprite2D
    - ...

Cast selection

The cast selection checks for node’s position like this

for unit in BoxSelectionUnits_Visible.values():
	if drag_box_global_rect.has_point(unit.global_position):
		if unit.is_in_group("units"):
			selection_add(unit)

Where drag_box_global_rect.has_point(unit.global_position) is checking the units position.

What’s up

What’s up is the drag box is checking the drone’s (`Node2D’) position which is in the origin.

In this case, you want to know the drone’s RigidBody2D position.

Solution

Restructure your drone’s scene to look like

- drone: RigidBody2D
  - Sprite2D
  - ...

Where you replace the drone Node2D with the RigidBody2D. This makes the RigidBody2D the root of the drone scene.

Side Notes

  • Please fix all errors! These errors can mask other issues.
    • GDScript can error with but a polite complaint, break out of the current function, and continue chugging along. This can lead to undefined behavior and broken state.
  • When running into an issue like this, it is a valuable practice to create a MRE. Reducing your scene to be as minimal as possible will give you another perspective of the issue. Additionally, this is much more efficient for others to assist you.
10

Thank you very much for the thorough response.

I’ve faced similar issues in the past, where I believed that having a node2D base was the best practice as a “container” of sorts for the rigidbody2d, but I’m now realizing that introduces a host of issues or at the very least some annoying programming patterns where you have to get the parent / the child of the node2d, and the node2d itself often serves no actual role, as manual repositioning / scaling of a rigidbody isn’t good practice. So thank you, i’ll remove the node2d’s that are the parents of my rigidbody entities and refactor that.

I’ll attempt to go through and remove “errors” / unused variables etc.

1 Like
11

I think you’re right. Having a container node is a good practice.

The rest of your code would need to be aware of the container pattern. For example, defining a container interface that has a get_body() function. Or using ‘get_node_or_null()` to just grab the node if it happens to exist.

For character and rigid bodies I seem to default to having the body as the container since it can have a lot of interactions with other objects.