Still Need to wait for LocalPlayer in ReplicatedFirst?

[kaan650 (Kaan)]

I found this old screenshot from 2022 while going through my notes:
It used to be on the official Roblox Docs, explaining that when using ReplicatedFirst, there’s a chance that your LocalScript might run before Players.LocalPlayer is available

This makes sense because ReplicatedFirst scripts execute very early — even before some client-side objects are fully ready.
But when I checked the docs today, I couldn’t find this info anymore. It seems to have been removed or deprecated?

So my question is:
Is this still something we need to worry about in 2025?
Has the engine changed in a way that ensures LocalPlayer is always set when a LocalScript runs in ReplicatedFirst?

Any official clarification or updated insight would be appreciated

[legendaryjimmy12]

It seems like this has been patched but I have not been able to find any official clarification either. I have searched some topics in engine bugs but still nothing. It might be buried in old roblox announcements, but I believe It has been patched as it does not have the same issue anymore.

[ow9u]

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…

does this topic help with your question?

[kaan650 (Kaan)]

No,

• In the 2018 Developer Forum announcement, it was stated that:

“game.Players.LocalPlayer will always be non-nil”

• However, in a screenshot I took from the Developer Hub in 2022

“The LocalPlayer may not be valid at the time a LocalScript in ReplicatedFirst starts running.”

So we’re seeing a clear conflict between what was announced and what was later documented — even years later, the guarantee doesn’t appear to have been finalized or reflected consistently

[ow9u]

@kaan650

However, in a screenshot I took from the Developer Hub in 2022

they’ve might be taken this piece of code from even older docs that existed before (developer.roblox.com, not create.roblox.com). how can we prove that it’s written in 2022 and not taken from an older page?

also i’ve just indexed Players.LocalPlayer or Players:GetPropertyChangedSignal("LocalPlayer"):wait() and found this topic from 2017, so it doesn’t end on 2018-2022 for sure.

i could dig in more, but i feel like procrastinating unfortunately.

@kaan650

So we’re seeing a clear conflict between what was announced and what was later documented — even years later, the guarantee doesn’t appear to have been finalized or reflected consistently

for sure. but to be fair the page you found from the screenshot is hidden somewhere not in plain sight. they could just mark it archived if it’s not i think..

[2112Jay]

It’s still the same due to how all that works…

while not game:GetService("Players").LocalPlayer do
	task.wait()
end
local lp = game.Players.LocalPlayer

[ow9u]

not even?? LocalPlayer is accessible before the start, you don’t have to wait for it

[2112Jay]

@kaan650

ReplicatedFirst

He is talking about a script in ReplicatedFirst.

[ow9u]

i’m talking about a script in ReplicatedFirst as well

[index_self]

If memory serves, the Players.LocalPlayer property is still not guaranteed to be set before ReplicatedFirst runtime. It’s possible the instance could be instantiated before any scripts run regardless, but I’m not too sure.

Regardless, there’s no harm with doing checks like these. Worse case, you do actually have to yield and start the loading screen a millisecond late or whatever.

[Yarik_superpro (The_GrandOptimizer)]

doesn’t metter now i guess
If you are paranoid just do:

local Players = game:GetService("Players")
if Players.LocalPlayer==nil then
Players:GetPropertyChangedSignal("LocalPlayer"):Wait()
end
local Plr:Player = Players.LocalPlayer

[ow9u]

it’d be ideal for roblox to build the system that covers these cases tbh. but roblox wasn’t that good feature-wise in the past, and it’s built on legacy code mostly.

there’s might be no problem with these checks, but it’s not actually too friendly to newcomers…

[kaan650 (Kaan)]

Here is the original respond from roblox staff: