We have added special handling for UIs, all existing UIs including sorts and layout orders are expected to continue working as they do today without requiring changes on your part. The children will not be ordered, but they will show up in the correct order on the screen.
3 Likes
Thank you for bringing this up! We understand your concerns about this, and we’re currently discussing potential solutions.
3 Likes
After thinking about the character name collision problem a bit more, I think Roblox should introduce a solution to this. I don’t disagree with your premise, I just do not like the solution you proposed with a new arbitrary folder in Workspace, as there is many problems I can think of with that.
A better solution, which does not break backwards compatibility, and is more customizable & elegant:
- Introduce a new property in
Playersthat references an object that character models are parented to by theLoadCharactermethods. Could be called something likePlayers.CharacterContainer. - This new property would be set to
Workspaceby default. In the future, Roblox could add a new dedicated default location for character models by just changing the default value of this property. - The developer can now then change the property to point to their own custom folder in
Workspace.
They could also add a new additional version of LoadCharacter that just returns the character model instead and does not parent it for you.
1 Like
If your solution is meant to not break backwards compatibility, then Roblox should not change the default value of this property in the future (except in templates). There are a lot of Games not being updated that depend on the Character being in Workspace.
Yeah, I don’t think they should ever change the default if they make that. I was more or less trying to demonstrate how this solution is highly customizable and elegant.
1 Like
Hi Devs,
TL;DR: We will be enabling the change today on Studio as planned, but we acknowledge the problem with Player-introduced name clashes and are working on a solution so you won’t have to worry about it when the change goes live globally.
@IvyInPairs made a great point in an earlier comment on this post: with guaranteed Sibling Order, developers didn’t have to worry about Players’ names clashing with the names of statically created Instances parented under Workspace, but if we no longer guarantee it, this could become a huge problem for some games. Though there do exist workarounds for this kind of thing, we agree that name clashes between in-game Instance names and Player names aren’t something that developers should have to worry about.
We will continue to explore this so we can deliver an elegant, developer-friendly solution in the future. For now though, because we are very excited to bring you the improvements to the Game Join process that we’ve already implemented, we will simply guarantee that when a player joins a game, Character Models will be parented to Workspace AFTER all other Instances, so that developers can continue to use functions such as FindFirstChild to find statically created Instances without worrying about a clash with a Player name. We may lift this guarantee in the future when we implement a better fix, but for now, we believe that this should allow developers to continue to work with statically created Instances as they have been.
Again, we will be enabling the feature today on Studio as planned, to give you guys a chance to make sure randomizing sibling order does not introduce any bugs into your game. We will NOT be releasing this change globally until we’ve released the fix that parents Character Models sent during Game Join to Workspace last, so you won’t have to worry about this bug showing up in your published games.
Thank you for bringing this to our attention, and please let us know if you have any questions!
8 Likes
I agree. Although this update wasn’t made to put an end to how programmers get instances, it did, and that’s great considering how unreliable this method of part detection is.
There is an edge case with sibling UI elements that share ZIndex values that this new change breaks.
It used to be that we can reliably order these elements simply by cutting and re-pasting back into a parent UI container to achieve the desired sibling order despite sharing same ZIndex values.
Example:
Simple overlay of a white textlabel and a slightly offset black textlabel underneath both with same ZIndex
After this change, the effect is no longer consistent; we now have to explicitly set the white textlabel ZIndex to be strictly greater than the black textlabel ZIndex for consistency
4 Likes
This is proving a bit of a nightmare for GUIs.
Bit worried that older games might suddenly stop displaying correctly - perhaps might be an idea to consider an exception for items parented to a GUI?
I can force myself time to do this by not relaxing in the evenings… yay!
2 Likes
We previously (a few months ago) enabled a mechanism that was intended to cause guis to still respect server sibling order (if the gui comes from the server), and local insertion order (when guis are created from local script). This attached place has three guis created on the server, and they are supposed to display with consistent layering order despite having the same zindex
However it appears that mechanism has stopped working:
expected:
actual:
Gui_zindex_order.rbxl (25.3 KB)
We have automated tests that should be watching this. We will investigate immediately.
2 Likes
If you can link me to any places that repro this issue, it will help make the investigation more robust (ensure that it covers everything)
Hi Devs,
@litozinnamon and @centraltrains mentioned that this change is negatively impacting UI’s. This didn’t make sense to us, as we had previously implemented special handling for UI that wouldn’t preserve the order of children on the Client side, but still have them show up in the correct order. We investigated further and have discovered a bug in our special UI handling. As a result, we are postponing the Studio release of this change until we fix this issue.
Thank you for letting us know! We will update this thread when we are ready to re-enable this change.
5 Likes
This change has negatively impacted World // Zero 
We see the issue but it’s going to take time to sort out across the entire place.
Is 3 weeks the guaranteed amount of time we will have to address this? Could we get a date that we should have our fixes pushed by?
2 Likes
Hi AbstractAlex,
For now, we’ve halted rollout of this change. When we do re-enable this change on Studio, we plan on giving developers at least 3 weeks before enabling the features globally.
Before we enable the feature globally, we will give you guys a warning (either by updating this thread or making a new post) a week in advance. If we find that developers seem to need more time, we may push the date back then.
We want to avoid breaking any games if possible, so please make sure to communicate with us when the time comes, especially if you feel you need a bit more time!
3 Likes
Hi Devs,
Previously, @litozinnamon and @centraltrains mentioned that this change is negatively impacting UI’s. We’ve since identified the bug, released a fix, and done QA testing with the fix to verify that the issues with GUIs reported last time no longer occur.
Now that we’ve got this resolved, we will be re-enabling this change on Studio ONLY on March 29, 2021 . We will wait AT LEAST 3 weeks after March 29 before enabling this change across all games on production. If any of you feel you need more time as the deadline approaches, please let us know, and we can discuss potentially pushing back the production release date.
We will be updating this thread in advance before we enable the change across production games to give you guys a chance to ask for more time should you need it, so please keep an eye out for updates!
Thank you guys for your patience!
6 Likes
Hi Devs,
It’s been a little bit over 2 weeks since we enabled this change on Studio ONLY on March 29, 2021 . If you guys are ready, we would like to enable this globally on production next week, on April 22, 2021 , so we can unlock some more join time improvements! Please let us know in this thread if you guys need some more time to modify your games to accommodate the changes to sibling order.
A reminder: some Devs were concerned that usernames could match the names of statically created Instances in their game and mess with calls like FindFirstChild in LocalScripts if the player’s Avatar gets parented before the statically created Instance (see: Changes to Sibling Instance Ordering Sent at Game Load - #13 by ForbiddenJ). We have already released a fix that will force the Client to parent players’ character models AFTER the Client parents all other instances it receives when joining to the DataModel first. If you suspect that unlucky usernames or bad actors can still interfere with your game via this exploit, PLEASE LET US KNOW and we will investigate.
Again, we don’t want this change to negatively impact any games - please let us know if you guys need more time to accommodate this change!!
5 Likes
Hi Devs,
As a reminder, we are planning on turning this feature on globally on production tomorrow, April 22, 2021. Please comment on this post or message me if you think you need more time to accommodate the changes to Sibling order!
Hey there @asdfiji123!
I was wondering if I can workaround this behavior by waiting until the game has loaded and then start replication or does it always happen?
I have a game that loads in a map every round and I’d like the Floor to replicate first before any else to prevent players falling into the abyss of death.
So my question is how do I FORCE certain items to replicate before others?
My game has been negatively affected by this change due to how items are replicate and aren’t displayed in an order they were added as a child / descendant.
1 Like
Hi @RuizuKun_Dev,
I sent you a DM so we can talk about your specific place and diagnose the issue together!
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.