How would you make that interface work?

This is a READ-ONLY snapshot of the Godot Community Forums when TwistedTwigleg was the owner, which is hosted for archival reasons only. The current Godot Community Forums can be found here.

Some links may point to external websites, including the current Godot Community Forums. These websites are not associated with TwistedTwigleg.

How would you make that interface work?

Wafflily

Here's what I need to do: - have a background layer to block all inputs, so that the scene can be put over another scene and prevent it from catching events - have an area2D to catch mouse events - have another area2D on top of the previous one to catch mouse events (with priority over the previous one)

How would you do that? My current solution is to have a Control set on Stop for the background. My first area2D uses _input(event) to catch all events, then I manually calculate if the mouse click is inside the rectangle area. But I can't do that for the other area2D so I'm blocked.

TwistedTwigleg

I would try using _unhandled_input instead of _input, as the _input function handles all input regardless of whether the event has been handled/processed already or not.

Wafflily

But then it receives a grand total of 0 unhandled input, as the background handles them all, as intended. This question is NOT answered. Can somebody remove the tag?

TwistedTwigleg

@Wafflily said: But then it receives a grand total of 0 unhandled input, as the background handles them all, as intended.

Ah, well that would not be ideal then. Hmm, maybe you can add a boolean and then flip that to selectively tell which node to process which? Then if the Area2D on top processes the event, it could flip the boolean to false so the Area2D underneath ignores the event.

This question is NOT answered. Can somebody remove the tag?

It's not a tag, its just what the Vanilla plugin we are using labels any post that gets a reply. Unfortunately, we cannot remove it as its core functionality of the plugin and the assignment happens automatically.

It will be yellowed with "accepted answer" if any of the replies are marked as the actual answer.

Wafflily

It's not a tag, its just what the Vanilla plugin we are using labels any post that gets a reply. Unfortunately, we cannot remove it as its core functionality of the plugin and the assignment happens automatically. I see, makes sense. Hmm, maybe you can add a boolean and then flip that to selectively tell which node to process which? Then if the Area2D on top processes the event, it could flip the boolean to false so the Area2D underneath ignores the event. I'll try that.

llasram

@Wafflily -- I haven't done any real Godot UI programming yet, but what prevents you from using SceneTree#set_input_as_handled() and normal input event propagation to deliver your events only where they should go? My understanding is that events move up the node tree from leaves to root being passed to _input() until something marks the event has handled; if nothing handles the event then it repeats through the tree calling _unhandled_input(). Is there some subtly to marking events as handled I've not yet encountered?

Wafflily

Well, the way I presented the problem, yes. I left some details, like I would have prefered using input_event() at least for the second area2D because, well, that's what area2D are meant for (only treating inputs that are inside their collisionShape2D). But no input_event() gets past the background. Additionally, I just discovered that the background does not stop area2D that are under them from getting input(). So now I think I'll try making the scenes behind completely ignore input instead. Then the background doesn't need to stop input, then I can use input_event() for the second area2D and _unhandled_input() for the first. Or the solution that was suggested.

Wafflily

First test, setting set_process_input(false), set_process_unhandled_input(false) and set_process_unhandled_key_input(false) for a button seems to have zero effect. Is there a common way to disable all input processing for a scene or just a button?

llasram

@Wafflily -- Could you post a dummy project or (possibly even better) a self-contained scene file showing the setup you're having difficulty with? Even though I don't have specific knowledge, I'm up for being another set of eyes for my own education. Plus the exercise of creating the dummy scene might help you isolate the problem in the first place!

TwistedTwigleg

@llasram said: @Wafflily -- I haven't done any real Godot UI programming yet, but what prevents you from using SceneTree#set_input_as_handled() and normal input event propagation to deliver your events only where they should go? My understanding is that events move up the node tree from leaves to root being passed to _input() until something marks the event has handled; if nothing handles the event then it repeats through the tree calling _unhandled_input(). Is there some subtly to marking events as handled I've not yet encountered?

_input will process the input regardless of whether its been marked as processed or not, so marking the event will not stop future _input functions from receiving the input. _input will always receive the input event and as far as I know, there is no way to stop a single event. You can turn off the function from processing input on a per-node basis though, using set_process_input(false), if I recall correctly.

_unhandled_input does more like what you are describing, as input is processed top-to-bottom until either the input event is handled, or all of the nodes have had their _unhandled_input function called. I'm not sure on the order, but I believe _input is called after unhandled_input. Regardless, an event processed in _unhandled_input will still be called in _input, even if marked as processed.

The problem with _unhandled_input in the OP, if I am understanding the issue correctly, is that the UI setup used catches the input event before it can reach either of the Area2D nodes.

llasram

@TwistedTwigleg said: _input will process the input regardless of whether its been marked as processed or not, so marking the event will not stop future _input functions from receiving the input. _input will always receive the input event and as far as I know, there is no way to stop a single event.

I don't believe that's quite true, but it looks like my initial take was woefully incomplete too. The InputEvent tutorial has detail diagram of the event flow.

The key things seem to be

Both the docs and my experiments confirm that calling SceneTree#set_input_as_handled() stops the event from further propagating, regardless of the input-handling stage.
Control nodes and physics nodes have additional handling which make things far more complicated.

In particular, a control node with its mouse_filter set to anything other than IGNORE will mark mouse events within it as handled, and block anything it doesn't forward the event to (either to parent via PASS or manually) from receiving it.

Since both generic _unhandled_input() and physics-specific collision object input events are later in the processing, having a Control with mouse_filter as STOP will prevent any processing of mouse events via those methods within the rect of the control node.

It looks now to me like some other method of blocking unwanted mouse events is necessary.

Wafflily

After a break, I'm back on this problem. @llasram @TwistedTwigleg Sorry for the delay!

Could you post a dummy project or (possibly even better) a self-contained scene file showing the setup you're having difficulty with? Here's attached a dummy project. Since I couldn't find how to have a scene ignore input, here's the solution I'll attempt next: - keep the input-blocking background, so that controls behind the main scene don't get input - have both area2D in the active scene use _input() and have an ad-hoc tag to mark the input handled - have a second ad-hoc tag so that area2D in hidden scenes don't treat input

Wafflily

The solution was reaaally easy: - set visible to false for all scenes except the current scene. Scenes with visible=false and their children will not get any input - then the background Control can be set to Ignore mouse events - then the area2D nodes will have no problem catching mouse events with _input_event()