Player instance now created on server instead of client

Updates Announcements
#1

Hi Everyone,

I wanted to share some information about the process of a user joining a game and some updates coming to that process.

As you may know, the Player instance has always been created on the client-side. This is changing: soon, the server will be creating the Player instance.

We want to keep you informed about the change but also want to ensure you that the change is meant to be completely invisible and seamless to you.

Moving forward, we are preparing a more detailed page on the Developer Portal regarding the client’s game join process. I will update this post when it becomes available.

—FAQs—

How do I prepare for this change?
We recommend that you check over Localscripts to make sure “WaitForChild” is used when trying to reference instances that are not created by that client. Localscripts should never assume an instance (created on the server) exists on the client without “WaitForChild” for that specific child instance.

Is there anything else changing?
Not for this update. If all localscripts are using “WaitForChild” correctly, there is nothing you need to do. The change should be seamless and invisible to you.

Is the update live right now?
Currently, the update is not live. No game behavior is changed. We expect this to go live soon. When we go live with the update, we will update this post!

Thank you everyone!

45 Likes
#2

I’m not sure I understand completely what scripters need to do about this change. Can you provide a code example that will break with this new change?

9 Likes
#3

There isn’t anything.

2 Likes
#4

Instead of ‘game.Workspace.Part’ use ‘game.Workspace:WaitForChild(“Part”)’

#5

:+1:

#6

The only thing he said that might break anything is

in which you use :WaitForChild()

#7

I use :WaitForChild() in everything that I script.
Shouldn’t be a problem.

3 Likes
#8

“Is there anything else changing?
Not for this update.”

Can you provide any more details on what else is changing if not in “this” update?

#9

What about referencing the LocalPlayer through localscripts? For instance, I have a variable that defines the player through “game.Players.LocalPlayer” on run time.

3 Likes
#10

Things I can imagine needs to be changed is how we use the Players.LocalPlayer property, and things like getting a player’s PlayerGui, Backpack, StarterGear and PlayerScripts - but examples definitely would be helpful to clarify as to what could break.

#11

@Kampfkarren

Sure thing! The place to pay attention to is in localscripts.

Say on the server side you have a part instance called “NicePart” right under game.workspace (This would be game.workspace.NicePart)

On localscripts, you’ll need to have the following to guarantee the reference is correct

local theBadPart = game.workspace.NicePart  -- this will not work
local theGoodPart = game.workspace:WaitForChlid("NicePart")   -- this will work properly

@Q_Q, game.Players.LocalPlayer is ok, there’s no need to change it

10 Likes
#12

Does this mean that the game.Players.LocalPlayer, when indexed by the client, can momentanely be a nil value?!

#14

@davness No need to worry about game.Players.LocalPlayer. It should never be nil in localscripts.

8 Likes
#15

Is NicePart an object created at runtime? Or one made in studio beforehand?

#16

@Kampfkarren

Good question! It applies for both cases.

#17

Thanks for the clarification.

Given my scripting style, it seems to fit the update. Yay!

#18

I think what he means is that anything created on the server will take time to replicate on the client.

This seems like basic networking stuff, so I would say you shouldn’t worry about it. It’s always been that stuff created on the server will need to replicate to the clients.

What exactly changes for existing code @KnightTakami ? I don’t really see how any issues would be caused aside from already-existing problems.

#19

@EmeraldSlash Yeap, this update should be invisible to developers given that WaitForChild is always used in a localscript. There shouldn’t be any changes needed to the existing code when WaitForChild is used properly/when needed.

Relating to @Kampfkarren’s question about objects created at runtime vs created in studio.
One case which we have discovered is that if a part is premade in Studio. And if you have a localscript that will be parented into the Player during onPlayerAdded, currently, there is a chance that this cloned localscript can reference the premade part with no problems without the use of WaitForChild. However, after the change, this will always require WaitForChild.

2 Likes
#20

FTFY
game.Workspace:WaitForChild("Part", 10)

Otherwise, you get spammed with warnings for anything that isn’t immediately there

#21

@PineCrumb

Sure, in this change, we are changing how the Player is created, by doing so, there are some slight adjustments to how things are replicated to the client when the client joins the game. The adjustments (most notably) is the order at which some of them are replicated.
We are working on a Developer Portal page that’ll provide more in-depth look at how the updated process looks like.

Again, the adjustment should be invisible to developers.

1 Like