Helper methods find_child_of_class(), find_child_with_method() and such.

[tomsterBG]

It's easy to script a for loop to iterate on all children and check which one is of a certain class. Similarly to check which one has a method or signal. Similarly to do that in reverse for your parents. However i think it's so frequently done that it deserves to be matured as an official set of helper functions along the already existing methods.

I find it easier to search for a node of a group than a node of a class because of the helper method. However groups solve a specific problem and i think it doesn't mean we can't have easily searchable nodes by other traits, especially commonly looked at ones like class and method, and perhaps signal. Arguably both of these focus more on what a node does rather than what it is.

Here's the more specific proposal:

Returns	Name
First node	find_child_of_class/by_type(type: String, recursive: bool = true, owned: bool = true)
Array[Node]	find_children_of_class/by_type(type: String, recursive: bool = true, owned: bool = true)
First node	find_child_with_method(method: StringName, recursive: bool = true, owned: bool = true)
Array[Node]	find_children_with_method(method: StringName, recursive: bool = true, owned: bool = true)
First node	find_child_with_signal(signal: StringName, recursive: bool = true, owned: bool = true)
Array[Node]	find_children_with_signal(signal: StringName, recursive: bool = true, owned: bool = true)
First node	find_parent_of_class/by_type(type: String)
First node	find_parent_with_method(method: StringName)
First node	find_parent_with_signal(signal: StringName)

I'm indecisive on the names, but the idea is there. It'd be easy to do and optimize in the future if the Object is_class(), has_method() and has_signal() methods are used.

On a side note, why is_class and type are used for the same thing? I feel like there's a distinction that is important like maybe type refers to all classes, even through class_name unlike class referring only to built-in ones?

As for usecases i just bumped into it yet again, wanting to find my children by their class simply because by name is less reliable, I may change the name, but the class doesn't just change at my will because i need it for its functionality and that is more reliably searchable in my case.

[AThousandShips]

Why is find_children_of_class needed? That's just find_children("*", type, recursive, owned) (edited, should be "*")

[tomsterBG]

Oh interesting, i just assumed if you leave the pattern blank it won't find anything because i didn't test it and the docs didn't make it clear. If that works as expected then it isn't necessary to have an extra method, but for readability purposes it may be cool to have. Though the helper methods are quite a lot to add to an already large Node so doing that as a GDExtension instead of engine feature may be the better option.

Since the methods are quite a lot i don't think all of them should be added, but i decided to make a more complete list just to show the entire family of functions and perhaps come up with a way to have a single function that takes an object which says what is the criteria (name, type, method, signal, etc.) and what is the direction (first parent or child, all children) and the rest of the parameters such as owned and recursive. This should greatly reduce the amount of API in Node exposed to the user, but would still require a new object which i can't figure out how to name.

It's easy to name a result, like raycast_result or damage_result, but this isn't a result, it's parameters. Perhaps raycast_params, resistance_params.

Perhaps find_node_by_params(value: String, find_node_params: FindNodeParams, recursive: bool)

FindNodeParams would have:

• enum Direction {PARENT, CHILD, CHILDREN}
• var direction: Direction
• enum Criteria (NAME, TYPE, CLASS, METHOD, SIGNAL)
• var criteria: Criteria
• owned: bool = true - only used when it's relevant

value is the value of the criteria. For example if you say value is "initialize" and find_node_params.criteria = 3 then you'd be searching for the method "initialize".

Sorry if any of the pseudocode is slightly wrong, but i hope you get the idea.

However i feel like this is getting overkill, maybe i should try to make an example of it working first, if i can at all, i have a history of failing to make the things work in Godot cpp.

[AThousandShips]

The documentation says that the pattern can be made to match anything:

As such, it is case-sensitive, "*" matches zero or more characters, and "?" matches any single character.

[tomsterBG]

I made this proposal because i thought that you can't add methods to built-in classes. You can't, but you can make a global script that has similar functionality and right now i'm working on adding these and some other functions in a helper global script over here: https://github.com/tomsterBG/godot-classes-unit-tested
I'll close the discussion for this specific reason as it may be more useful for us to make our own helpers rather than bloat the engine like this.