Gui ZIndex messing up badly, 9 overlapping 10

I have an issue where I have several ScreenGuis, and an object in them is a ZIndex of 10, with another object in a different screengui with a ZIndex of 9, sometimes the ZIndex of 9 overlaps the ZIndex of 10, and can be resolved by dragging the 10 into different screenguis, some yield desired results, some do not, both objects are image labels, and I have a reproducible example of it, and have confirmed the ZIndex of 9 overlapping the 10 in play solo, so its not a script issue. the 10 appears to overlap everything else but this one screengui and contents. :angry:

Known issue.

Don’t use ZIndex = 10 and you shouldn’t see any problems.

When you make unlimited ZIndex, could you fix this as well? :smiley:

Just changed it in my game to be 8 and 9, instead of 10, and it still is having the same issues, so does 8 and 10. Will keep you posted if I find out a workaround.

Edit: insert order matters in this case, I just cut the 10 gui, and repasted it, and it shows above the 9 consistently, and the 9 is drawn via a script, so it seems that ZIndex is ignored when the screenguis are inserted into the gui after the game has already began.

I think only the very first number is used, which means 10 becomes 1, and 23 becomes 2 etc

broke for a 9 and 8 as well, no tens, it mattered on insert order into the game, it looked like, as what was inserted first was what was rendered on bottom, like the zindexes were completely ignored.

this is what happened:
game starts with a screen gui, with a zindex of 9 in it
game makes a screengui with a zindex of 8 in it
8 shows ontop of the 9
cut the 9, and re-insert it into the game
the 9 is now ontop of the 8

this I would expect of gui with the same zindex, its almost like the zindex doesn’t matter if the guis were inserted after the game start, as they work fine otherwise.

You do know that ZIndex only works within a given ScreenGui, right? Given that, the behavior you described seems exactly correct to me… if you cut the ScreenGui with the 9 in it, and then paste it back, it will now be the last ScreenGui to have been parented, and thus will be drawn as the topmost.

[quote]

You do know that ZIndex only works within a given ScreenGui, right? Given that, the behavior you described seems exactly correct to me… if you cut the ScreenGui with the 9 in it, and then paste it back, it will now be the last ScreenGui to have been parented, and thus will be drawn as the topmost. [/quote]

So I could achieve more than 10 ZIndexes by inserting whatever ScreenGui is to be on top last?

"So I could achieve more than 10 ZIndexes by inserting whatever ScreenGui is to be on top last? "

Yes, or just by using ChildOrder over ZIndex where possible within a given ScreenGui. Age of Glory actually has an object-pool of 16 statically created BillboardGuis that a manager hands out to other classes that need them because it’s the only way to get them to layer underneath our run-time created ScreenGuis event handling wise.

[quote] "So I could achieve more than 10 ZIndexes by inserting whatever ScreenGui is to be on top last? "

Yes, or just by using ChildOrder over ZIndex where possible within a given ScreenGui. Age of Glory actually has an object-pool of 16 statically created BillboardGuis that a manager hands out to other classes that need them because it’s the only way to get them to layer underneath our run-time created ScreenGuis event handling wise. [/quote]

And this was necessary because the client team said no when you asked for unlimited layers?

“And this was necessary because the client team said no when you asked for unlimited layers?”

No, it was necessary because there was no way to get dynamically created Screen/Billboard Guis to event-wise stack underneath statically created ones. It is going to be changed so that BillboardGuis always stack event wise underneath all other GUIs (as they should, since they already are visibly underneath all other GUIs).

Given the way it was implemented it wasn’t really a bug as per se, but it was an unintended consequence of the implementation, and it’s being changed to act in the more useful way.

if its so that screenguis have their own zindex, could you make a ScreenGuiZIndex property, that manages that tier of zindexes? I commonly use different screenguis for organizeational purposes, and this overlapping behaviour is rather annoying to deal with, what I do now as my hack, is load my top layer, which stores the mouse gui in it, after all other guis have loaded.