Changes to Sibling Instance Ordering Sent at Game Load

[asdfiji123]

Sorry to hear that but this update should not be live for any game at the moment. I don’t think this bug is due to the change this update talks about - it’s much more likely that some other change made to the Game Engine earlier today broke your game. Could you please file a bug report to give this more visibility? Then the right team on Roblox will hopefully recognize it and get back to you with a fix.

[ForbiddenJ]

@PeZsmistic

You should probably prefer to use folders to contain critical instances instead. The likelihood of a user joining your game with the same name as the critical folder is very low if the user already exists, and otherwise you can just claim the account if you’re worried.

I guess. Two of the examples I cited before are folders in the manner they’re used.

@PeZsmistic

You shouldn’t really have anything in workspace other than containers and parts and other rendered things, scripts should almost never be in workspace, and if there are there is certainly a better solution (e.g. collection service and a batch processor).

I did not know that accessing instances in workspace directly was a bad practice. I guess I’ll need to change the way the scripts get a hold of anything important in workspace.

I guess ObjectValues in ReplicatedStorage are a good solution for indirectly accessing them, because their values can be set to important things and the game engine would be smart enough to correctly replicate them.

[asdfiji123]

For all other Services, instances may arrive in arbitrary order (i.e. a descendant of Workspace may arrive before a descendant of ReplicatedStorage, or vice versa).

[TheFortex]

I don’t think I understand this very well so I’m gonna ask for clarification

Is this going to mess with UI order (using UI list layout or similar objects) if it sorts by layout order?

[IvyInPairs]

@asdfiji123 Please consider making a change to the parenting of player characters before this Instance ordering change goes live. It’s been safe for as long as I can remember to access statically created children of Workspace without having to worry about accidentally accessing characters, so this is a really big change.

If all characters were instead parented to a dedicated Folder inside Workspace, this wouldn’t be an issue. While it would break old code, where Workspace[Player.Name] was common, this code was already bugged due to the current ordering behavior.

CollectionService can be used, true, but it’s not always idiomatic, it’s less likely to be used in older games, and it’s not well known among beginners.

[jmt99 (jmt)]

@IvyInPairs

If all characters were instead parented to a dedicated Folder inside Workspace , this wouldn’t be an issue.

This seems like a significant and excessive change for something that is avoidable through many different methods:

• The easiest fix, and is good practice regardless, is to properly organize the Workspace. Nothing should really be direct parented to Workspace and should instead be parented to various categorized Folder objects. You could even parent everything under a single folder to get around this issue if you wanted.
• Like you said, using CollectionService, which is made to deal with exact cases like this.
• Implementing this dedicated character folder yourself with something like this:

local charFolder = Instance.new("Folder")
charFolder.Name = "PlayerCharacters"
charFolder.Parent = workspace
game:GetService("Players").PlayerAdded:Connect(function(player)
	player.CharacterAdded:Connect(function(character)
		if (character.Parent == nil) then character.AncestryChanged:Wait() end
		game:GetService("RunService").Stepped:Wait()
		character.Parent = charFolder
	end)
end)

[IvyInPairs]

@jmt99

Nothing should really be direct parented to Workspace and should instead be parented to various categorized Folder objects.

A name conflict is still possible with the Folder and a character. It has been suggested in this thread to register usernames to prevent this, which I don’t think is reasonable.

@jmt99

which is made to deal with exact cases like this.

Using CollectionService when there will only ever be one tagged item is not idiomatic, and can mislead someone into thinking they can add the tag to more objects without an issue, which may not be true. ObjectValues are another option, but this is also awkward. It should be easy to safely refer to a child of Workspace, even for new developers.

@jmt99

Implementing this dedicated character folder yourself

I don’t think this is reasonable, and the naive approach is actually unreliable. Developers would have to set Players.CharacterAutoLoads to false and manually set and respawn Player.Character.

I’m not sure why you think my suggestion would be a significant change. It would mostly impact code which is already bugged, and which uses very old coding practices (to be fair, checking if Character.Parent is Workspace may be more common). In terms of breakage, I think there would be a far higher impact from the ordering update without this change.

[LordRugdumph]

@TheFortex

Is this going to mess with UI order (using UI list layout or similar objects) if it sorts by layout order?

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.

[asdfiji123]

Thank you for bringing this up! We understand your concerns about this, and we’re currently discussing potential solutions.

[jmt99 (jmt)]

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 Players that references an object that character models are parented to by the LoadCharacter methods. Could be called something like Players.CharacterContainer.
• This new property would be set to Workspace by 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.

[GuestIsJustBest]

@jmt99

This new property would be set to Workspace by default. In the future, Roblox could add a new dedicated default location for character models by just changing the default value of this property.

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.

[jmt99 (jmt)]

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.

[asdfiji123]

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!

[Y35X (Maxatal)]

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.

[litozinnamon]

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

[centraltrains]

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!

[LordRugdumph]

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.

[LordRugdumph]

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)

[asdfiji123]

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.

[AbstractAlex]

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?