Player instance now created on server instead of client

Updates Announcements
#43

maybe exploiters were spoofing their UserId cuz it replicated from client to server

1 Like
#44

@KnightTakami This thread is about the Player instance being created on the server, but your code examples reference something completely different (a part in Workspace). I don’t really see the connection here? This is a very confusing thread to read. Are you saying that there’s going to be an entire paradigm shift on the way replication is handled on the platform as a whole?

WaitForChild is still a relatively new feature, so a lot of games don’t use it – and, in cases where it was not required, it has been considered to be bad practice by some to use excess WaitForChild calls. Local scripts don’t run until the game is fully loaded by the client (unless they’re in ReplicatedFirst), and what you’re saying implies that this will change. I hope that’s not the case.

Previously, PlayerScripts didn’t exist on the server at all, and PlayerGui contents were copied from StarterGui by the client. Additionally, items dropped into the PlayerGui would only replicate to that player specifically. Is this going to be the continued behavior after this update?

5 Likes
#45

None of what you said is relevant to what I’m talking about. Exploiters will ALWAYS be able to modify Workspace for their own client…

If they weren’t able to, then we wouldn’t be able to make our own parts in a LocalScript. That’s not what this thread is talking about.

2 Likes
#46

This is probably unrelated but while we’re on the topic of the Player object id like to bring this up. The Player object has been missing from the Object Browser in studio for a long time (over a year). Will we be seeing this added soon?

#47

I’m not too sure about this one. Player object represents a user in the game. Were you using it for something specific? (But honestly, I’m not sure about this particular question)

#48

I think because of the way team create works if you could spawn player objects it would show that in the player count of the game on-site but I’m not 100 percent on that

#49

He’s referring to the Object Browser window that shows a (really ugly and underdeveloped compared to the wiki) explanation of the properties, methods, and events of an object.

#50

To clear up confusion:

The post is meant to say, that you should continue to do what you should already be doing. This update will make no difference to you as a developer, but changes a lot behind the scenes.

If you ever reference an object on the client that is created by the server, you should always use WaitForChild() game.Workspace:WaitForChild("Part")

In LocalScripts, you can use game.Players.LocalPlayer to reference the Player object, LocalPlayer will never be nil.

You should always use LocalPlayer:WaitForChild("PlayerGui"), when referencing the client’s PlayerGui or any object inside the Player, because it is an object that is created by the Server later on in the join-game process.

8 Likes
#51

That’s not what’s being implied, as shown by the NicePart example, and for the fact that he said you’ll need to WaitForChild for it even if it was created in studio. What’s the explanation for that if I’m missing one?

If I was doing something with NicePart and it was already created in studio, I would just use workspace.NicePart. I wouldn’t use workspace:WaitForChild("NicePart") because it shouldn’t be necessary. Am I going to have to always opt for the latter?

3 Likes
#52

There is a chance that LocalScripts will run before NicePart is replicated to the client. So your script should hang with game.Workspace:WaitForChild("NicePart")until it is replicated.

If you are 100% sure that an object is replicated before a script runs, such as while you’re in Studio. then feel free to use game.Workspace.NicePart.

But if you’re developing for a game that players are joining, you’ll want to use WaitForChild() so you can wait for the object to replicate.

1 Like
#53

I thought playergui’s existence is guaranteed now?
https://devforum.roblox.com/t/multiple-levels-in-waitforchild-looking-for-feedback/90528/27

#54

I don’t believe that’s the case. Local scripts don’t run until the game has been fully replicated to the client. If the server’s still sending game data to the client for the initial load, the scripts will not start until that’s finished (unless your script is in ReplicatedFirst).

1 Like
#55

If I created NicePart in studio, then I would have zero problem indexing it as normally (workspace.NicePart). I never have. This changes that, and I have problems with the OP saying this is an invisible change that developers won’t notice.

#56

I believe the OP was saying that in LocalScripts you should write game.Workspace:WaitForChild("NicePart") when writing code for production ( players joining games ). You can continue to use game.Workspace.NicePart while in studio or in places where you know the object exists.

#57

I think that’s what he was saying too – which implies a very big change from the status quo. What the OP said implies that LocalScripts will begin to run immediately after they are replicated, which is troubling. There’s no reason to make that change since we have ReplicatedFirst anyways. I’m hoping OP just made an error in his example. Roblox has no reason to change this behavior so late in the platform’s life – especially when it’s just a major inconvenience and provides no benefit to the developer.

1 Like
#58

From how current things are, yes, the client is able to modify workspace to a full extent (even if people on other clients won’t see the changes) due to workspace copying over to the client; however, if workspace would be fully ran by the server and not duplicated over to the client when players join, clients would only be able to add parts so only they will see them and can only remove/modify parts they’ve added themselves, so localparts would still work.
This is based off of assumption this will happen the way I’ve described it. I might have gotten offtrack a little bit, but this mechanism they’re adding has tons of potential.

#59

LocalScripts already, to this date, run as soon as they are replicated. This is always how it has been.

1 Like
#60

From the sounds of it, this feature only affects people who are doing loading stuff at the very beginning of a play session, when the place is being loaded by the client.

Can you give insight on the necessity of using :WaitForChild() in local scripts with the following initialization conditions?

  • StarterPlayerScripts
  • StarterCharacterScripts
  • ReplicatedFirst
  • StarterGui
  • Local script delivered to client when server script detects player joining
  • Local script delivered to client when character is created
  • Local script delivered to client when character touches a part
#61

So what did you mean by your security comment? What you described is already how it works. There’s no way for a client to add new parts to the Workspace with or without this change.

#62

That’s not what’s being implied. Refer back to the answer on whether we have to WaitForChild on parts created in studio.