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?
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.
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.
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.
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.
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.
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
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)
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.