I’m tired of meticulously ordering my Gui to have everything fit properly within the 10 ZIndex limit. Why do we need the limit, anyway?
3 Likes
The ZIndex limit is annoying, but the ZIndex limit is good. Without it, GUI ZIndex would end up like CSS ZIndex, where you end up with ZIndex:9999999999. You can imagine this isn’t a good thing, especially with ROBLOX’s reusable GUI ecosystem.
Relative ZIndex is the superior solution to changing the 10 ZIndex limit, and the solution I support.
5 Likes
IIRC, @Sorcus said something about how removing the ZIndex limit would cause a lot of memory consumption problems.
1 Like
Never understood the number 10.
It’s bigger than 2^3 and smaller than 2^4.
We could have 1-16 with the same bits, allowing us 60% more ZIndex levels.
2 Likes
Doubt it’s related to storing the number itself.
They probably render the GUI to 10 distinct framebuffers depending on the z-index and join them in the proper order in the end or something like that.
2 Likes
IIRC Roblox use counting sort to render GUIs according to ZIndex, so a limit has to be enforced somewhere and then Roblox core GUI has to then render on top
1 Like
I hope they don’t or someone has to go over there and yell at whoever made it work like that. Counting sort seems more reasonable and also explains the limit.
Sounds more reasonable indeed 
. Feels like the limit is really low then, though.
How to get 50+ ZIndex layers:
Create 5 ScreenGui objects, each of which are placed in the PlayerGui (via code, I wouldn’t trust by hand) in careful, known order such that the first parented is known to be layers 1-10 and the last is known to be layers 41-50. Then parent objects to them using each of their 10 respective ZIndices.
This works because GUIs are rendered a ScreenGui at a time. The one parented earliest is drawn first, the next is drawn on top of that, etc. CoreGUI is always drawn last, on top. For this reason, a ZIndex-1-object will always render on top of a ZIndex-10-object if they are in two distinct ScreenGuis and the Z1’s was parented later than the Z10’s.
This is infinitely scalable, but you probably don’t need more than 30, for which you would use 3 ScreenGuis.
This isn’t the most convenient solution in the case where the things you want to layer are deep in a convoluted hierarchy that determines a very specific size/position, but if you don’t need complex size/position-determining containers (or if you are willing to duplicate the container structure, and say, make their background transparent) then this is certainly the solution for you.
Personally I use this system in multiple contexts, one of which is to make different “windows” stack on each other without having to worry about the ZIndices of their children with respect to one another. Each window is in its own ScreenGui. When you click inside a window, it un-parents and re-parents its ScreenGui so that it now renders on top of all other windows (making it the “active” window).
2 Likes
>multiple screenguis
pls no.
It may be a bit inefficient but it’s at least a kind of elegant way of implementing multiple windows and having them appear in the order of last clicked
This is live now btw.
2 Likes
ZIndex Cap was removed?
ya!
I’m assuming we still can’t draw over CoreGuis?
CoreGui objects still have a higher priority in the layer sorting queue, regardless of ZIndex. ZIndex is local per each BasePlayerGui.
1 Like