Replication testing

[colbert2677 (Dreamseeker)]

UPDATE 09/24/2020: This project is no longer maintained.

---

I’m not technically versed by any means. I only know how to write basic code in Lua.

I’ve had a recent fascination in replication especially with all the support topics lately. Along with that, I strongly feel like I’ve been providing misinformation or misinterpreting some threads. With these things in mind, I’m going to log some of my tests here.

Why post it on the DevForum? I check here every day so it’s easier to remember than crowding it on my trashy computer. On the off chance someone discovers this thread, well, free resources and information to read up on. Not like it’s too interesting.

Hope this gives me better insight to replication and so I can provide better, more accurate information.

[colbert2677 (Dreamseeker)]

References

---

Official

LocalPlayer Timing Update

Hi All! Today, we have enabled a minor change that will delay the creation of LocalPlayer in preparation for another feature. LocalScript will still run after LocalPlayer can be detected, so this will not affect any LocalScripts in your games and should only affect Roblox’s CoreScripts. What does that mean for you? Nothing! This change should be completely transparent to you. There is no need to change any localscripts or how you detect Localplayer. The timing is delayed from before establis…

When to wait for replication to the client

Hi Devs! I wanted to share some information about some unclear points regarding the starting of localscripts and when replication occurs. I will also share the guarantees that we will provide soon. Until now, developers need to guess when localscripts starts running and what instances can be referenced at start. Today, I wanted to explain a little about some guarantees that will go live soon that will help you with what is needed and what’s not needed when writing code in your localscripts. T…

Speculative

Player instance now created on server instead of client

There seems to be a lot of confusion, so I made a diagram. Note that it is based only on my observations, and is not authoritative. [replication] Each step depends on the completion of the previous step (on the same peer, anyway). The client connects. A snapshot of the objects under ReplicatedFirst is queued to be replicated. The server starts replicating objects in the queue to the client. Once the client has received all the objects, scripts under ReplicatedFirst start running. A snapshot…

Player instance now created on server instead of client

Yes, and that’s one point where it gets confusing. It is important to remember that scripts run depending on where they are located. Theoretically, a LocalScript might replicate and then begin running immediately. In most cases however, any container where they could replicate is a container where they can’t run (StarterGui, StarterPlayerScripts, almost everything, really). And, for any container where they can run (PlayerGui, etc), scripts are copied from the respective Starter container (Star…

Notes

• Both posts in the speculation category are written by a platform expert, but are based on observations and are not representative of actual ordering.

• The official posts, specifically “When to wait for replication to the client”, explains (?) replication ordering but I frankly don’t know what to believe. I’ll try seeing if my tests align up with that. If so, I’ll have my answer regarding ordering.

• “When to wait for replication to the client” was written later than Anaminus’ chart, meaning that such discussion must have spurred engineers to respond with an official statement. I still use the latter post more often but maybe I should start using the former.

• These tests could be completely stupid and unnecessary since an engineer literally wrote a post about replication. I’d still like to test around a bit though, get the gears going.

[colbert2677 (Dreamseeker)]

New confirmations:

• WaitForChild is not required to access static instances in ReplicatedStorage for LocalScripts running in PlayerScripts.

• StarterPlayerScripts LocalScripts are protected by game.Loaded by nature of being a starter container (this should be implied given its name).

• PlayerScripts does not implicitly exist under the LocalPlayer, even to a LocalScript running from there. WaitForChild is required to access it externally. Not yet sure if script.Parent returns PlayerScripts despite this behaviour.

Testing materials:

• ModuleScript with default source in ReplicatedStorage
• LocalScript in StarterPlayerScripts

Source code:

Required ModuleScript:

local a = require(game:GetService("ReplicatedStorage").ModuleScript)
print(a) -- table: mem_address

PlayerScripts access:

local a = game:GetService("Players").LocalPlayer.PlayerScripts
print(a) -- Not reached, throws error

---

Several of my past projects as well as those I’ve taken part in or the helm over abuse WaitForChild for static instances in ReplicatedStorage, especially with regards to our library loader utility. As this module starts in ReplicatedStorage, it is static and WaitForChild is not required for it from LocalScripts.

I’m going to have a real blast refactoring, aren’t I…