Changes to Sibling Instance Ordering Sent at Game Load

Updates Announcements
#6

Thanks for the find!

The reason for this change is that it allowed us to make other changes to the Game Engine which improve game join processing.

13 Likes
#7

Such as what? I kind am of Curious.

#8

So is this improving performance? It’s a bit unclear what the actual reason behind this is, some clarification would be very nice.

3 Likes
#10

Are there any other services than ReplicatedFirst that will replicate in some specific order (for instance, ReplicatedStorage before Workspace), and will this update change the order those services replicate? Or instead will only change the order that the items within that category replicate to the client?

Also, with the new changes to :WaitForChild and now this, it would be super useful to have a :WaitUntilLoaded() function that will wait until each descendant has been successfully loaded into the given object from the server. That way we can avoid a million wait for child’s and all that.

2 Likes
#11

I think improvements to the game processing system will have nice long term effect, considering with every update people push the game past its limits. However how much of a performance increase will this generate?

#12

Specifically, we are targeting improving game join processing times, both on the Server and Client side. This is part of an ongoing effort by Roblox to improve the Game Join experience, much like the recent previous change outlined in this post: Return of Changes to Non-ReplicatedFirst Loading Order.

Some improvements that this change helps bring about are highlighted here: Return of Changes to Non-ReplicatedFirst Loading Order - #13 by LordRugdumph

14 Likes
#13

In at least two of my games, I have specifically-named instances in Workspace that my LocalScripts depend on. Since characters also exist in Workspace with their players’ names, there’s a chance that an oddly-named player can disrupt these LocalScripts. For example, “Multiplayer” in Open Flood Test, and “Mine” and “StarterChest” in ForbiddenJ’s Quarry. There are likely other workspace dependencies that I didn’t mention.

If players with these exact names join the game, players that join afterwards may have script failures because their LocalScripts are accidentally grabbing references to those characters instead of their intended targets, because those characters have the same name.

Historically, I didn’t have to worry about this because instances were sent in order (with StreamingEnabled off) and these scripts always grabbed their intended targets.

Are there any recommendations for accounting for this?

6 Likes
#14

I’m fairly certain this has been known to bad practice, I hope people aren’t doing this in the current year.

Awesome, this is what I like to hear :sunglasses: keep up the good work with engine updates

1 Like
#15

I can think of two methods for circumventing this:

  1. Call Players:GetPlayerFromCharacter (roblox.com) and see if it’s returning nil AKA the instance you’re expecting. If not then keep searching for it
  2. Use a special character in the instance’s name, such as :heart: AKA '\03'. This is something that I’ve done without issue and is the least resource intensive way I can think of going about it

Also there is CollectionService (roblox.com)

3 Likes
#16

I think this is a really good change, even if it ends up breaking games. Programmers should not be relying on arbitrary order of instances and instead should use things like CollectionService and FindFirstChild. To be honest, I wasn’t even aware that Roblox guaranteed the same instance order on all machines.

9 Likes
#17

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.

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).

4 Likes
#18

Perhaps run an if statement that tries to find a humanoid as a child, if it does, that instance is ignored?

#19

Is there anything being worked on to give developers manual control over replication of instances? There are many cases where I want to have instances in workspace on the server but not have them be replicated to the client, cases where I want to replicate to just a single client etc. The current networking API is very lacking and needs to be improved

2 Likes
#21

you can mend these errors by using WaitForChild again, like so:

local collectGui = p:WaitForChild("PlayerGui"):WaitForChild('Collect')
#22

What I’m trying to say is that this update is live in my game all of a sudden. I can’t even test this update in Studio, because my Studio has not received an update yet. I know how to fix that, I just wish I had some time to do that

#23

Sorry to hear that :confused: 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.

6 Likes
#24

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

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.

2 Likes
#25

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).

5 Likes
#26

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?

2 Likes
#27

@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.