#CollisionObject2D input_event race condition

1 messages · Page 1 of 1 (latest)

tidal sable
#

Working on a 2d sports game, I have a field area 2d that has player CharacterBody2D objects as children. When a player is clicked they become selected. When the field is clicked a waypoint for the selected player is set. Both types subscribe to their own input_event signal to process mouse clicks. Player calls 'viewport.set_input_as_handled()' on consuming the event.

However, it appears that neither object heirarchy order or z layer impact which receives the event first, and is instead somewhat random, so there are times where field gets the input event first and incorrectly processes the click, setting a waypoint under the player to be selected. I was originally using unhandled_input for field until I realized that (somewhat counterintuitively to me at least) that object events come dead last in the processing order.

#

CollisionObject2D input_event race condition

oak kettle
#

I've run into the same problem and was wondering if any solution was found?

astral lark
#

Normally when no z index is used, the order of things in godot depends on the tree structure. Things which are up in the tree get processed last while things further down get processed first. Also, children get process before their parents.

oak kettle
#

Thanks for the reply! I'll work on making a minimal repro tonight or tomorrow. What I ran into is exactly what Smileynet described. It's quite odd. I would expect signals to follow the same node ordering as _input and _unhandled_input.

astral lark
tidal sable
astral lark
oak kettle
#

I made a minimal repro of the issue.
There are two scenes. The main scene PlayField, which has a white noise texture and the script on its root node.
Within PlayField is instantiated scene ClickField, which has the green noise texture.
The input_event for ClickField is connected to the root script, as well as the input_event of the Area2D that is a child of PlayField.
The expectation is that when you click inside ClickField you will always trigger the method _on_click_field_input_event. If you click anywhere else, you should trigger _on_area_2d_input_event.
However, when executing, which signal is processed when clicking inside ClickField is effectively random.
I can share a zip of the whole project if anyone wants, but this should be pretty quick to make as well.

#

In my own project I worked around this by using mouse_entered, mouse_exited and _unhandled_input instead of input_event signals. Seems like that shouldn't be necessary though...

tidal sable