No… the order in the guiNode does not matter. Just the Z value of the local translation. Something else must be going on that I can’t see.
Not sure why you have to keep track of the focus requests… unless that’s how you are tracking the ‘dialogs’. You do somehow have to keep track of what you are managing this way so that you can resort them, yes… else you constantly increase Z each time which would work but is a bit hacky.
Indeed I was just trying to deal with the Z-order.
But the Z order only worked after I re-added the dialogs.
If I just modified the Z value, nothing changed…
May be I would have to make a minimal test case to understand why I had to re-add to gui node for it to actually work, so I would be sure it was not something I missed to configure/call like some kind of refresh/update for the gui elements.
I had to keep track of the focus because I was modifying the Z of each dialog based on their stack index, so older ones will have the smaller Z values.
And also, when the stack is empty, I have to remove all focus, otherwise it will not “give focus back” (stop intercepting keys) to the application/game, this also can be something I am missing, as I remove the dialogs from the gui node and initially I thought only that should suffice.
I made some more tests, a Z value of 1000f will make the mouse cursor stop working when trying to click at elements like buttons, even hovering highlight stops working.
I tried that big value to try to avoid removing and re-adding the spatial, but it didnt work, the overlapping still happened. I will see if I can prepare a test case…
So now, I am using a Z displacement of 10f between each dialog, and some of that overlapping problem that was still happening (with a displacement of 0.1f), now are gone!
I mean, it is working great now, despite I quite do not understand why it had to be 10f or more, like it has some kind of precision… ahh… I guess I am not able to even guess now :), but it is working great, is what matters!