Editor embedded game window: how to solve Controls covering whole screen and preventing selecting nodes behind

[hsandt]

Problem

I have several controls that cover the whole screen in my game:

• Debug Draw 3D addon which automatically adds a DebugDrawDefaultCanvas that covers the whole screen (despite the name, it's used for both 2D and 3D)

• Some CanvasLayer HUD node with a HUD Control node that covers the whole screen

This prevents me from clicking on anything else using the new Godot 4.4 embedded game window 2D Selection mode: it just selects one of these two "huge" control nodes, despite them being invisible.

I need a way to disable selection on these huge control nodes so I can select the nodes behind.

Workaround

Currently I'm manually hiding the DebugDrawDefaultCanvas, but the trick only works that far when I don't need to see it. Then I must also hide the HUD, which may or may not be desirable... I cannot just disable selection without hiding said Control nodes.

Solutions

We can copy the solutions used in other contexts.

A. Node lock

In the editor Scene tree, Godot allows the user to lock a node (keypad icon). This prevents accidentally selecting any node or moving it when clicking on the Scene view. I always lock invisible container nodes such as huge control nodes placed just below CanvasLayer covering the whole screen, or even smaller controls that are empty and only serve as parent to place actual UI elements.

The embedded game window could simply honor the lock status of nodes in the Scene tree.

Advantages:

• reuse the existing Lock system, and in general what you want to lock in the editor is also what you don't want to select in embedded game window...

Issues:

• ... but not always, you may want to distinguish the locks between the two modes
• the lock status is an editor thing using the editor Local Scene tree, while the embedded game window runs a separate game instance represented by the Remote tree. To use node lock status, Godot would need to know about the origins of the nodes in the remote instance. It seems that Godot has some knowledge of this since when I modify a parameter in the Local scene tree with Debug > Synchronize Scene Changes enabled, the changes are reflected on runtime node instances. However I'm not sure how far Godot knows about the original Local node
• this only works for runtime nodes that are exactly coming from an equivalent local node in the scene. Nodes that are instantiated are runtime (procedurally or from a prepared scene) won't have a "locked" status (unless Godot is modified to copy the Lock status of the original scene into the runtime node and somewhat keeps this information, at least in the embedded game window). In the case of DebugDrawDefaultCanvas mentioned at the top, which seems to be instantiated by code, it would never be locked. Unless some API is added to access a node's editor state (I suspect this is doable in C++ for plugin writers but ideally this should be accessible from anyone using GDScript).

B. Mouse debug selection filter property

At runtime, Godot checks the Mouse > Filter (mouse_filter) property of a Control node to decide whether a click should go through or not.

We could add an equivalent property Mouse > Debug selection filter (mouse_debug_selection_filter or debug_mouse_selection_filter or editor_mouse_debug_selection_filter if Godot devs use debug or editor prefixes for special properties) that does the same, but is checked only by the embedded game window if 2D/Control selection mode

Unlike mouse_filter there is no need to have 3 values Stop, Pass (Propagate Up) and Ignore, just Stop and Ignore will be enough. So it could be a boolean flag / checkbox instead of an enum. In this case it could be named e.g. ignore_embedded_game_window_selection.

Advantages:

• it's now easy to set the property on nodes instantiated at runtime : just set control_node.ignore_embedded_game_window_selection = true after creating the node

Issues:

• this makes us store an editor-only property in scene files (this should be lightweight though, and could be stripped on build). I'm not aware of other editor-only properties in Godot, so I don't know if it's common practice or not

C. Distinguish 2D from Control Selection mode

We could split the current 2D/Control selection mode (shown by a circle half blue, half green) into two different selection modes

to

and

Advantages:

• it's clear what we select, we can even select 2D sprites under the HUD

Issues:

• user needs to switch mode every time they want to select 2D vs Control nodes. A regression for people used to the mixed selection
• this doesn't solve the issue of container Controls preventing selection of the child Controls they cover (only selection of 2D nodes)

D. Option to automatically ignore invisible Controls

That would be a nice option to have in any mode, in fact: editor, runtime, embedded game window

However Godot needs to be able to "understand" what an invisible Control is (does a TextureRect with a transparent color, or a sprite with transparent modulate qualifies, or only a truly empty Control that only acts as a Parent / Container?).

[Calinou]

cc @YeldhamDev

Personally, I would make editor locking/grouping affect the project as well (and make set_meta() with the the same metadata name at runtime work).

I'm not aware of other editor-only properties in Godot, so I don't know if it's common practice or not

We have Node.editor_description already, which isn't stripped from exported projects (as there is no system in place for that yet). There are also a few others like the custom debug colors for Path2D and CollisionShape.