Warn when accessing local properties such as Players.LocalPlayer from a script

This was very confusing to me when I first started coding as a script would work in studio but not online.

Could a warning be added such that any script / module required by a script prints a warning to console when in playsolo whenever Players.LocalPlayer is accessed?

The problem is that this could go for lots of things, such as Workspace.CurrentCamera

Any client-side only objects that are accessed in play solo should have a warning for new coders. Not sure why that’s a problem?

1 Like

Sorry, ‘problem’ was a poor word choice. Rather, my point is that if you add a warning for accessing Players.LocalPlayer from a server-side script in Studio, then it would only make sense to add warnings to all other potential properties with the same behavior.

4 Likes

LocalPlayer and CurrentCamera aren’t client-side-only objects. The API has no such concept. We shouldn’t act against them for the same reason we shouldn’t act against misuse of FireServer/Client based on the type of script you’re running.

The root problem here is that you tried accessing the local player from a server script. If you want to be warned when you write code that won’t work online then you should just run a test server/client.

1 Like

I use this code snippet a lot:

local IsServer = not game.Players.LocalPlayer

if LocalPlayer is nil, then IsServer is true, and if LocalPlayer is truthy, IsServer is false.

I would like not to have a wall of warnings telling me about LocalPlayer.

3 Likes

RunService:IsServer( )?

@Sharksie
I feel like the key here is

which is exactly what this is, a misuse of the properties, there’s no reason these days ( As there are other methods to determine server / client, etc ) to access Players.LocalPlayer or workspace.CurrentCamera from a server-side script, and it’s a mistake from my experience new developers make often.

Another issue with this is that assuming a script’s behavior based on its classname is strictly wrong. You can run Scripts locally, and what would we do with ModuleScripts? What about BindableEvents/Functions? There’s so much nuance it’s not clear at all, and I think warning people who should already be aware of their script environment is not worth spamming the output of people with exceptional use cases.

What?

That’s for another feature request, this is purely properties

You can run a Script locally by putting it in the playergui.

I’m talking about bindables, not remotes: What does this warning mechanism do when I have a Script register .OnInvoke, and then call :Invoke on a localscript, and then the function that was registered by the script accesses localplayer? The call stack is mixed, so there is no clear definition of what environment the script is intended to be running in.

This is a huge can of worms. I’d rather not be spammed with weird messages for doing unexpected things.

what!

Wasn’t really intended to be part of the feature request, while would be useful, I feel is separate.

It’s not a feature I’m suggesting. It’s an implementation detail that needs to be considered for your suggestion to work at all. Scripts and LocalScripts mix in with each other all the time in play solo. Sifting through it to figure it whether or not to display a warning isn’t feasible.

I legitimately use LocalPlayer and CurrentCamera often enough on the server that this would annoy me to no end.

1 Like

Can you name a few? If there are legitimate use cases then I agree this shouldn’t be a feature.

The problem with RunService:IsServer() is that its an ultimatium, and end-all-be-all condition that doesnt consider what Im trying to do in code.

For example, if I want to play a sound effect when some code is executed, I want to make sure there is a live person around to hear it. Players.LocalPlayer is much more explict and nails down who I’m looking for (as an audience for this sound effect) much more concisely than RunService:IsClient() or RunService:IsStudio() does.
That’s a more simple example. I use it much more often when designing systems that both human and computer players have access to. Since most (if not all) computer/AI players are dictated by the server, I would rather not execute code on the server that serves no purpose for an audience that isnt present.

workspace.CurrentCamera is more of a hack right now. But parenting assets to the server’s camera used to be the only way to create server only parts for physics, raycasting, whatever you want. With collision groups, you could probably get away without using this trick.


TLDR: Players.LocalPlayer addresses what I’m actually looking for (just like using game:FindService(“NetworkServer”) can be used to determine if there is a server) much more concisely than the RunService methods

workspace.CurrentCamera is more of a hack

1 Like

I actually do that too, RIP.

Fair points, although no new player would do those types of things. Perhaps if a setting was added for “Tutorial” warnings for things like this and waitforchild infinite timeout warnings that could be toggled?

There’s also that you can position the CurrentCamera on the server to determine the thumbnail if you use the Save Place API (or build servers, if those still exist)

1 Like

In that case, CurrentCamera exists on the server so there shouldn’t be a warning for that property, where as LocalPlayer doesn’t exist on the server.