Yes, under the new model a Script with RunContext = Client will run on all clients which it is present on regardless of where in the hierarchy it is, eliminating the need to have separate LocalScript Instances for each client to drive local behaviors.
Note that you can stack this favorably with StreamingEnabled, in that the RunContext = Client script will run on exactly the set of clients it has been streamed in on if you put it under a part in the workspace.
In the far far far future, will LocalScripts lost their support? Should we slowly start to migrate our scripts to this new feature?
Also, Iām a little bit confused about the Legacy feature - were we all the time able to use ānormalā scripts in places like StarterGui to run as LocalScripts? I assume now we can, so ā¦
Continuing to use LocalScripts is completely safe.
The worst thing that may happen is that eventually we may build some new features that you need to be using RunContext to make use of (for now thereās no plans to do that), but you can be sure that existing LocalScripts will be supported effectively indefinitely since literally every game uses them to some extent.
This is one of the best updates ROBLOX has implemented.Going to make a huge change to my teams workflow. Canāt wait for this to come out of beta.
Hey wouldnāt that make a Local Script useless if we have this??
I really disagree, I dont understand why ROBLOX added this and I see it like as a denaturalization of the system. It was not complicated, to make scripts on the client side you had to put the script in a dedicated client location, for the server you had to put it in a dedicated server location. No chance of deceiving this and mixing up brushes. For proximity between the two sides creating a double side coded module placed in the ReplicatedStorage is and will remain the best option. I see this update as a more complex and an attempt to make things simpler for kids but I donāt see anything really good in this update. I hope to change my mind and hope I just donāt understand the update but right now Iām confused.
Itās not bad to have more freedom to where you wanna put your scripts. Itās a āwantā not a āneed.ā If you want to put your (local)scripts in the workspace, this update will tell you āgo for it.ā Itās not forcing it onto you. I hope this change will not turn out bad for you and I, because I really think it has no bad intention.
No, they can 100% steal your code; if the Scriptās RunContext is Client then it will replicate its bytecode.
In case you didnāt know, bytecode is what exploiters decompile.
Iām excited for this change, mostly because it would make a lot of my bad code easier to write (client scripts in the most convenient places)
Thatās a good update, but it renders LocalScripts Useless
how would it render modulescripts useless?
My bad, I was thinking of something else while typing that
All this update does is allow people to ditch localscripts in favor of solely using serverscripts, and then having a toggle property that allows the serverscript to switch between run all its contents on the client, and running all its contents on the server. Thereās no strings attached, it basically just allows you to, with the press of a button, change the behavior of a script.
This also means that we no longer have to memorize/pay attention to which containers will run which types of scripts, and that scripts can appear anywhere, so you can bundle scripts that actually go together.
For example, I can have a client combat script AND a server combat script under the same container, as opposed to placing the client script inside StarterPlayerScripts, and placing the server script inside ServerScriptService or some other container that is supposed to run serverscripts. There is no downside; this system is just better.
As for exploit concerns, thereās no need to worry, it was all stated in the original post that scripts donāt alternate between running on server/client at runtime.
In the OP, thereās talk about merging the behaviour of scripts and client scripts. If this were to take place, would LocalScript become a deprecated instance or would they be automatically converted at runtime to scripts with a client RunContext (depending on their container)?
Yay! i cant wait to someone do the CSGDictionaryService backdoor again!
I noticed RunContext = Client scripts under ReplicatedFirst run after StarterPlayerScripts have been cloned, is this intentional?
This is answered in the original post:
Are there any plans to make it so that Modules scripts, can also be sectioned off and not automatically replicated?
I mean, of course, I can just keep them separated as I do now with a legacy to ensure this, but for those who use heavy module code, seems strange to not offer the same kind of sectioning.
At this point Roblox should add Replicated property to toggle replication.
So whatās the difference between a localscript and a script with its RunContext set to Client?