body_shape_entered signal/event - does not have access to it's parent (calling) Node?

:information_source: Attention Topic was automatically imported from the old Question2Answer platform.
:bust_in_silhouette: Asked By trjp

I have multiple Area2Ds - all connected to the same “body_shape_entered” signal function - which is passed details of Rigidbody2Ds colliding with these Area2Ds

Problem is, there is no way to know WHICH Area2D the body has collided with because this information isn’t included in the parameters - which seems to be a massive oversight?

There must be a way to get this but the documentation is zero help here

Why wouldn’t a collision event contain details of BOTH colliding parties?

p.s. body _ shape _ entered - stupid markup nonsense…

You can put in-line code references between back-ticks (``) for readability. That’ll look like:

body_shape_entered

jgodfrey | 2020-05-16 16:41

Thanks for the tip - shouldn’t be necessary tho, it’s a WYSIWYG editor so why is it converting what’s entered as markup??

trjp | 2020-05-17 14:20

:bust_in_silhouette: Reply From: phiz

Perhaps you could connect the collision locally and make your Area2Ds emit a custom signal which includes some identifier for themselves? Custom signals can have any number of arguments.

I discovered this when searching for answers to this - however I don’t really think it’s the right answer.

If I were creating Nodes manually, creating signals manually would be logical

I’m creating nodes in the editor tho - I can add signals in the editor and they lack critical information (which I cannot change even tho I can customize signals)

Note: if you duplicate a node, signals are duplicated to the same function so the editor CREATES the problem as a matter of course…

trjp | 2020-05-17 14:16

:bust_in_silhouette: Reply From: njamster

Why wouldn’t a collision event contain details of BOTH colliding parties?

As long as you connect the body_shape_entered of one area with one callback, that would be redundant information: you know which area it was, because there is only one possibility! Your case is a special case, where it’s indeed not clear, but perfectly fine that you have to provide the missing information yourself:

func _ready():
	$Area2D1.connect("body_shape_entered", self, "_on_body_shape_entered", [$Area2D1])
	$Area2D2.connect("body_shape_entered", self, "_on_body_shape_entered", [$Area2D2])

func _on_body_shape_entered(body_id, body, body_shape, area_shape, area):
	print(area)
	print(body)

When connecting a signal from code you can provide an array of extra-arguments that will be passed after the default arguments of a signal.

What I’ve asked here is a pretty common question around Godot forums/Reddit etc. - and it’s always answered as “do it manually using connect” but I raised this because the existing system of ‘editor created’ signals is - well - it’s nonsense.

The editor can create things - duplicate things - you WILL end-up with signals which reuse a function and so that function should be able to determine it’s source

Moreover - the default paramters for body_shape_entered contain redundancy - why supply the body id AND the body itself (you can get the former from the latter?)

Needs tidying/sorting-out really

trjp | 2020-05-17 14:15

Needs tidying/sorting-out really

Nobody stops you from opening an issue on github.

What I’ve asked here is a pretty common question

Yes.

it’s always answered as “do it manually using connect”

Because that’s the correct answer (for now).

I raised this because the existing system of ‘editor created’ signals is - well - it’s nonsense.

You didn’t make clear why you raised that question though. Instead you stated this: “There must be a way to get this but the documentation is zero help here” And all I did was pointing out that way. I am not a clairvoyant: there’s no way for me to know that you already knew about this, if you don’t mention that in your question.

The editor can […] duplicate things - you WILL end-up with signals which reuse a function

True. However, that doesn’t necessarily mean that you’re interested in the node that called the callback. It’s very possible that it still doesn’t matter. Just saying.

so that function should be able to determine it’s source

And it is able to do that if you pass the source as an additional argument. I fully agree that it also should be possible to do that from the editor alone without any coding, but that’s a different topic. In fact there already is an issue for that.

the default paramters for body_shape_entered contain redundancy […] (you can get the former from the latter?)

Yeah, I was irritated by that as well. However, that’s not really an argument to include even more redundancy but to remove that redundancy as well, isn’t it? :wink:

njamster | 2020-05-17 15:21