Add search filter syntax to the scene tree dock

[GuyUnger]

Describe the project you are working on

NA

Describe the problem or limitation you are having in your project

I have a lot of nodes in my scene and searching through them is limited

Describe the feature / enhancement and how it helps to overcome the problem or limitation

add advanced search filters similar to discord's search

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

filter:script all nodes that have a script

filter:tool all nodes with a tool script

script:SomeScript all nodes that have SomeScript.gd attached

filter:signal all nodes that have connected signals

filter:group all nodes that are in a group

group:group_name all nodes in a specific group

type:AudioStreamPlayer2D all the AudioStreamPlayer2D's (or whatever node type)

i don't know the best syntax, but some way to filter out these kinds of properties would be very helpful for me

If this enhancement will not be used often, can it be worked around with a few lines of script?

NA

Is there a reason why this should be core and not an add-on in the asset library?

NA

[and-rad]

It would probably be a good idea if you went into more detail about specific use cases where the current implementation is a limiting factor for you. Like, limiting in terms of the amount of code you have to write or in terms of performance or something else?

Regarding some of you examples:

group:group_name: What's wrong with get_tree().get_nodes_in_group(group_name)?

type:AudioStreamPlayer2D: When is get_tree().get_root().find_children("", "AudioStreamPlayer2D") not enough for what you're trying to achieve?

script:SomeScript.gd: If you give the script a class_name, you can use find_children like above. Admittedly, having to set a class names for every script is not always desirable.

For the other ones I find it hard to come up with scenarios where I would need them in the first place. That's another reason why it would be interesting to read more about your specific use cases.

EDIT: The general idea for a kind of scene query language with some arbitrary filters sounds kinda interesting though. But I'd be more interested in filtering for property states, like "find all GPU particle systems where OneShot is true and Enabled is currently false".

[Zireael07]

@and-rad: I imagine the idea is to filter through nodes in a large scene while you edit it, not to find stuff at runtime. Your proposals are all for runtime.

[and-rad]

As in, typing it in the Filter Nodes search bar in the editor? That would indeed be a different use case and I misunderstood. (All the more reason to be more explicit in the proposal, though).

In that case, I'd be interested in how instanced scenes should be handled. Their children are hidden if Editable Children is not checked, so would they just be ignored by the search? It's what I would expect, but I imagine that would limit the usefulness of this feature somewhat.

[KoBeWi]

type: is being implemented here: https://github.com/godotengine/godot/pull/58377

In that case, I'd be interested in how instanced scenes should be handled. Their children are hidden if Editable Children is not checked, so would they just be ignored by the search?

The current filtering by name has the same limitation. It's not really a problem.

[and-rad]

Makes sense. I think this proposal is a good idea then. I can see group: being pretty useful as well as the filter: filter. The question would then be what kinds of filters should be supported in the initial implementation.

[seppoday]

As @KoBeWi said, we already have search filter for "type: ". This PR is nice QoL change that does not remove or add anything visually to the editor. If someone will not use it that proposal would not change anything for that person. Editor will be the same.

At the same time if someone needs that filters then why not have them? For me personally filter:signal or filter:group_name might be usefull from that list. I think that proposal is great and we already have tested it with that "type:" PR. I think that it is especially nice feature for more complex scenes (UI heavy etc.) If there is contributor interested in implementing then let's do it :)

[GuyUnger]

As in, typing it in the Filter Nodes search bar in the editor? That would indeed be a different use case and I misunderstood. (All the more reason to be more explicit in the proposal, though).

In that case, I'd be interested in how instanced scenes should be handled. Their children are hidden if Editable Children is not checked, so would they just be ignored by the search? It's what I would expect, but I imagine that would limit the usefulness of this feature somewhat.

Right, sorry for being unclear. Currently, children of instanced scenes do not show up in search. Maybe it could be helpful but in the current functionality i haven't felt a need for it

[and-rad]

If more filters are going be added besides the type: filter that's already being worked on, it might be a good idea to eventually implement a kind of drop-down element for the search field for users to select among the available filters. Like how Discord does it.

[GuyUnger]

If more filters are going be added besides the type: filter that's already being worked on, it might be a good idea to eventually implement a kind of drop-down element for the search field for users to select among the available filters. Like how Discord does it.

yes definitely agree

[GuyUnger]

instead of filter: it could also be has: like on discord

[JoNax97]

To streamline the search, we can use wildcards instead of the 'filter' keyword. For example, instead of this:

filter:group all nodes that are in a group group:group_name all nodes in a specific group

We can have this:

group: * all nodes that are in a group group: group_name all nodes in a specific group

This way the syntax is the same for both cases

[me2beats]

Also there can be a way to search nodes in the project, for all scenes. Maybe worth a separate proposal tho

[GuyUnger]

this can also greatly improve some of the prompts for selecting nodes such as: connecting signal: default search to filter:script adding audio playback track to animator type:AudioStreamPlayer2D,AudioStreamPlayer3D,AudioStreamPlayer (don't know the appropriate syntax for allowing multiple types) adding a call method track to animator filter:script (not sure about this one)

[seppoday]

Other idea for possible implementation (if there is need for it)

has:uniquename

This also might be good for scenes that are heavy in Control Nodes.

[Mickeon]

If I may suggest, filter:unique or something similar, to only highlight Scene Unique Nodes. Somewhat needed, as it can prove difficult to spot and make use of them by memory in a large Scene Tree.