Scripting Helpers is winding down operations and is now read-only. More info→
Ad
Log in to vote
3

When not to use a LocalScript? [closed]

Asked by 8 years ago

in what instance is it best to use a local script, and when is it not?

I've also wondered about whether or not all information in local scripts is always on the clients with those scripts, for example if I changed the torso transparency of an individual with a local script would other clients see those changes, or only that individual? (like with GUIs, for example)

Locked by User#24403, ee0w, and yHasteeD

This question has been locked to preserve its current state and prevent spam and unwanted comments and answers.

Why was this question closed?

1 answer

Log in to vote
16
Answered by
Link150 1355 Badge of Merit Moderation Voter
8 years ago
Edited 8 years ago

"LocalScripts" operate on the client; the player's computer. For this reason, they are also called clientside scripts.

Regular "Scripts" operate on the server; a really powerful computer located at the Roblox Headquarters which is responsible for hosting the game. For this reason, they are also called serverside scripts. Any change made to the server is "replicated" to all clients.

-

Now, depending on whether or not the FilteringEnabled property of the Workspace is enabled, LocalScripts may or may not be able to interact and change properties of objects on the server directly.

If it is enabled, the server will reject any changes from the clients, and so changes made from a LocalScript will only be noticeable by the player who owns said LocalScript (the local player).

Otherwise, if FilteringEnabled is disabled, the server will accept the changes and all players will notice them. An exception to that rule is the local player's humanoid. Any change made to the local player's humanoid will always be replicated to the server.

-

LocalScripts are generally used to handle user input, manage GUIs or manipulate the camera. LocalScripts will only execute if they are a descendant of:

  • A Player's Backpack, such as a child of a Tool;
  • A Player's Character model;
  • A Player's PlayerGui;
  • A Player's PlayerScripts; or
  • The ReplicatedFirst service.

Additionally, the ancestry of a LocalScript will determine on which client it shall be executed on.

-

Conclusion:

So the answer would be, when inserting a new script, ask yourself these two questions:

  • Is network filtering enabled? And, if so, should changes be replicated to all players?
  • Do I need to process user input, manipulate the GUI or Camera?

If you answered 'yes' to the first question then you should use a regular Script;

If you answered 'yes' to the second question then you should use a LocalScript;

If the answer is both a regular Script and a LocalScript then you should use both, and communicate through them using RemoteEvents and/or RemoteFunctions.

I Hope this helped. If so, please be sure to mark my answer as accepted and, optionally, give an upvote. It helps both of us. :)

0
thanks for the answer, although one question I have then is that what exaclty 'counts' as something being executed in relation to a humanoid? besides health and whatnot, do a players animations run for that specific player, or could anyone see them if they were in a localscript? (as much as I've seen that often, does this have to do with the exception you pointed out? and what else does?) ProgramsMan 100 — 8y
0
I have never actually messed with animations but I'd asume they can only be seen by everyone if triggered from a normal script, if that is what you mean. Link150 1355 — 8y
2
Actually, I just ran a test with a friend and apparently this isn't the case surprisingly; Animations are always replicated. Link150 1355 — 8y
0
The local script should be a descendant of blah blah could be reworded to say, "The local script must be a descendent of the Player". Because tools, guis, and the character are all descendents. EzraNehemiah_TF2 3552 — 8y
2
Everything is fine with my explanation. I don't know what you're going on about. Link150 1355 — 8y
Ad