repro :
Instance.new(“Sound”, game.Players.LocalPlayer.PlayerGui):Play()
I don’t know if this is intentional or not. I hope it was unintentional.
This is not intentional, it is a bug in our workaround for another bug! The chat attempts to re-parent itself to be the ScreenGui displayed on top whenever something is added to PlayerGui. We releasing a ScreenGui.DisplayOrder property soon, and this will remove the need for this. In the mean time, I can give you a version of the chat with a fixed temporary workaround for this if it is a big problem in your game.
2 Likes
A lot of things seem to cause the chatbar to unfocus in my game. It happens every time a ScreenGui is added to the PlayerGui as well. Also sometimes you can’t select tools in your backpack with the number keys on your keyboard anymore, but that’s probably unrelated.
Out of curiosity, why isn’t it named ZIndex? Or is it not an int e.g. Enum, etc
It’s fine. I parented the sound to PlayerScripts as a workaround.
If you don’t mind me asking - apart from parenting the sound to client only objects like PlayerGui and Backpack. Is there a way to play a sound ONLY on the selective client? I feel like I’ve missed the memo, here.
ZIndex leads to confusion with the other property. It is an int.
If the game is FilteringEnabled, sounds created on that client will only play on that client if they are created in Workspace.
It has the same meaning as the other property, though.
If DisplayOrder were instead ZIndex, it may mislead developers into thinking that ZIndex sorting works across all ScreenGuis, instead of only between GUI objects with the same ancestor ScreenGui.
If DisplayOrder were instead ZIndex, it may mislead developers into thinking ScreenGuis can sort relative to single non-ScreenGui GUI items, instead of just other ScreenGuis. For example, it would seem that this would display the TextLabel on top of ScreenGui2:
- ScreenGui1: ZIndex 1
- TextLabel: ZIndex 3
- ScreenGui2: ZIndex 2
DisplayOrder is for sorting ScreenGuis on the same level only. ZIndex is for sorting between GUI items with the same ScreenGui ancestor.
If ZIndex respected the parent object’s ZIndex then DisplayOrder and ZIndex would effectively be the same thing. Because ZIndex works between all objects that are ancestors of the same screengui, rather than just siblings, it is important to make a clear distinction between the two.
3 Likes
Maybe unrelated, but that “unexpected behavior” is what I’d prefer. I never have any reason to interleave cousin guis. ZIndex opens that up as a possibility, so in lieu of using ZIndex, I simply reparent all gui elements to bring them to the top. Maybe down the road ZIndex will behave like DisplayOrder (a man can dream).
DisplayOrder has the same semantic meaning and same purpose as ZIndex but with a slightly different implementation (that is, I don’t think the difference is major). I don’t think that’s enough to separate them. Separating properties leads to people having to look them up when coding (until they commit the differences to memory). The closest thing I can think of is Part.CFrame vs. BodyGyro.cframe vs. Camera.CoordinateFrame. That screwed me up for years.
It probably doesn’t matter too much, in reality. Just trying to give my thoughts.
I would prefer the unexpected behavior too.
I would also like to note that I agree that some properties, such as the CFrame properties of Part, BodyGyro, and Camera should have the same name. The reason that I think that DisplayOrder and ZIndex should be different has to do with the cases that can come up from misunderstanding them, not just that that their implementation is different. It’s possible to get in cases like I mentioned where it’s not clear what the behavior is, and it’s not clear to look up documentation because the names are the same. I think it’s better and more useful to developers to have to look up documentation than to get stuck and confused on a misunderstanding.