Godot: YSort companion node

[gusthe]

_Disclaimer_ : I am not asking for YSort to sort all sub-nodes of it's child nodes.

Would it be possible to add a new node that would only serve as a container/symbolic link within YSort nodes, where its contents would be YSorted as if they were direct children of the YSort node for better organization?

I'm not asking for this to interfere with other nodes or instanced nodes that are already children of the YSort node. They should all work the same way as before.

_example_

YSort1

_sprite1_ <---- YSorted because it is a direct child node of the YSort node
_instanced nodes_ <---- would still get sorted like they currently already do just like sprites 1-2(and its children would _not_ be sorted)
_sprite2_
(_New node_)

_sprite3_
_sprite4_ <---- Direct children of the new node (sprite3 and 4) would be YSorted as if they were direct children of the YSort1 node like sprites 1-2

I apologise for resubmitting this issue. I submitted it two days ago https://github.com/godotengine/godot/issues/3258 but it was closed because everyone thought I was asking to sort _all_ sub-nodes of children of YSort nodes.

[bojidar-bg]

@gusthe ~ Here is the main problem with your idea: you cannot do it with the current node structure and renderer, without doing some "hacks" (discussed below).

Here is an example: Imagine you have 6 nodes, at different _global_ Y coordinates:

- A (Y:1)
- B (Y:4)
- C (Y:6)
- YSortLink (Y:3) # This is the new container node
- YSortLink - E (Y:2) # Children of YSortLink
- YSortLink - F (Y:5)

After sorting by global Y (lower Y goes first in this example):

- A (Y:1)
- YSortLink - E (Y:2)
- YSortLink (Y:3)
- B (Y:4)
- YSortLink - F (Y:5)
- C (Y:6)

Unfortunatelly, we can't just move the node outside of its parent, plus it would be drawn either directly on top, or directly behind (with "CanvasItem/Behind Parent"=true). Thus we change our tree to fit:

- A (Y:1)
- YSortLink (Y:3)
- YSortLink - E (Y:2) (Behind parent checked)
- YSortLink - F (Y:5) (oops! This node just went behind B, while it should be in front of it. This would get very confusing to anybody just starting with the engine.)
- B (Y:4)
- C (Y:6)

---

Ok... there should be _some_ solution to the problem? Well, I can think of a few, each with its drawbacks:

1. Use z-index. This has the side effect of overwriting the already present z-index, which would be... nasty. (as it means you will have to keep foreground in seperate nodes/wrappers => more organizational issues)
2. Change the rendering system to have some virtual order, used for sorting internally. Probably the best solution, and the most complex too. Now we have: node order, z-index, and virtual order.
3. Change the node system, so nodes are in a tree, but are actually in a list, that gets sorted by YSort and others. That would laaagggggg, so #2 is better

[gusthe]

Would there be any way to do it where the YSortLink node would not be given a Y value at all? Kind of like how the AnimationPlayer(from what I can tell) node dosen't have any x y or z values? Sorry if what I'm saying doesn't make any sense.

[reduz]

I don't think this is fixable in any way, and I still fail to see why it is
needed

On Fri, Jan 8, 2016 at 6:46 PM, gusthe [email protected] wrote:

Would there be any way to do it where the YSortLink node would not be
given a Y value at all? Kind of like how the AnimationPlayer(from what I
can tell) node dosen't have any x y or z values? Sorry if what I'm saying
doesn't make any sense.

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/3281#issuecomment-170136825.

[gusthe]

I can't comment on whether it's fixable or not, but we can at least discuss it can't we? I can only speak for myself, when I say it would certainly be of value for my purposes. YSort is the only option I'm aware of that will allow me to perform this kind of sorting. And in my case I'll be looking at many hundreds of nodes all under one YSort node because that's the only place I can put them to sort them. It's not a deal breaker for me, but I thought I could at least inquire or suggest a possible solution.

[kubecz3k]

@gusthe Hmm maybe some kind of "search" or "filter"(with part of the name) button for scene tab would solve your problem?

[reduz]

The problem is that for this to be fast, it has to be simple. The sorting
of children Y-Sort nodes is done in-place with a local stack copy, so
anything more complex won't do.
A remote link is also not possible because nodes are processed in tree
order, and hacking this process would require adding a lot of code that
will make the process more unnecesarily complex, as well as prone to bugs
(a lot of behaviors rely on trees being processed in order). In other
words, It's too much hack for something that I feel is a corner case and no
simple solution comes to mind.

On Fri, Jan 8, 2016 at 7:25 PM, gusthe [email protected] wrote:

I can't comment on whether it's fixable or not, but we can at least
discuss it can't we? I can only speak for myself, when I say it would
certainly be of value for my purposes. YSort is the only option I'm aware
of that will allow me to perform this kind of sorting. And in my case I'll
be looking at many hundreds of nodes all under one YSort node because
that's the only place I can put them to sort them. It's not a deal breaker
for me, but I thought I could at least inquire or suggest a possible
solution.

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/3281#issuecomment-170144721.

[gusthe]

@kubecz3k You mean to search for a specific node in the scene, like something specific under the YSort node?

Edit: Yeah I could see a filter or search option being very useful.

[gusthe]

@reduz If that's that case then I can understand why it would be difficult to change. I wasn't looking to suggest major changes like that. I was only looking for something simple. Should I just close this issue?

[reduz]

I will think for a way to do this, so don't close it yet

On Fri, Jan 8, 2016 at 7:37 PM, gusthe [email protected] wrote:

@reduz https://github.com/reduz If that's that case then I can
understand why it would be difficult to change. I wasn't looking to suggest
major changes like that. I was only looking for something simple. Should I
just close this issue?

—
Reply to this email directly or view it on GitHub
https://github.com/godotengine/godot/issues/3281#issuecomment-170147028.

[kubecz3k]

@gusthe yeah exactly, I was thinking about possibility to filter nodes with fragment of their name (or path) something similar to how it's when you are opening a scene with ctrl+shift+o, but under 'search button in the scene tab, where are all the nodes.

[bojidar-bg]

@gusthe @reduz BTW, would a node that transfers all of its children to its parent at _enter_tree be a nice solution? This would also fix all kinds of similar organizational problems, and it is simple to do with the current codebase. The downside is that it would change nodepaths to its children...

[danielytics]

Or a node that exists only in the editor hierarchy, but at runtime its as if the children were directly parented to the containing node. That would make grouping and organising nodes easier, right now I have to prefix or suffix all of my nodes with their "group" so I can create filters, which is rather clumsy IMHO.

On the topic of filters, being able to save filters would also help in making the scene graph a little more accessible, as well as being able to filter by things other than just the name. I might take a look and see if this is something I could implement myself.

[reduz]

We discussed a nice way to potentially do this at Godoton, would like to
give it a try when back from GDC

On Sat, Mar 17, 2018, 04:22 Dan Kersten [e-mail] wrote:

Or a node that exists only in the editor hierarchy, but at runtime its as
if the children were directly parented to the containing node. That would
make grouping and organising nodes easier, right now I have to prefix or
suffix all of my nodes with their "group" so I can create filters, which is
rather clumsy IMHO.

On the topic of filters, being able to save filters would also help in
making the scene graph a little more accessible, as well as being able to
filter by things other than just the name. I might take a look and see if
this is something I could implement myself.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/3281#issuecomment-373912746,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AF-Z28lRV18r5eClNs3hbe4a-rAkp8Mdks5tfPHbgaJpZM4HBXCw
.

[danielytics]

I’d be willing to help out, but I’m new to the Godot codebase so would need some guidance.