It does not, you are supposed to use this feature for placing LocalScripts (well scripts in a client context) in places such as ReplicatedStorage
4 Likes
That is a good point, but from an organisational perspective, I usually only put scripts that will be used by both the Client and Server in ReplicatedStorage, and Client exclusive scripts in StarterPlayerScripts. And the reason Iâm pointing this out is because it differs from the previous behaviour of LocalScripts in a way that isnât really desirable.
1 Like
This is going to make distributing packages so much easier. Is LocalScript going to slowly get phased out when this is released since this is much a better workflow for scripts.
Iâve been privately messing with this using the two related FFlags and itâs powerful beyond belief.
For anyone wondering how this works for the client, if the client can replicate the sourcecode with RunContext set to Client, it runs the code.
6 Likes
This probably wonât ever happen, just due to the fact that it breaks any current localscripts if they were to be converted to the new type (they run twice, as they are in a container (which they would now run in), AND they still get duplicated)
2 Likes
What about Module scripts? Can we have the ability to switch to them to?
Anyways Love the update Thanks!
�
Anyway this is pretty cool
2 Likes
You can require module scripts in local and server scripts, they donât run automatically
Yeah but how about having a feature to turn them into Module scripts?
Just use a regular ModuleScript, it doesnât seem necessary for that to be an option
2 Likes
I read the op a few times over and to me, it sounded as if scripts defined as âClientâ would be able to run in any container in which they could feasibly run. The majority of the containers are limited to one environment anyway, so this would only affect a few containers such as ServerStorage, ReplicatedStorage, workspace, maybe StarterGui?
If oneâs codebase is organised properly, then these containers can work rather well together. Most of the time itâs the lack of explanation of what the containers do that makes developers question which places their code should be. I donât think this is a consequence of the containers themselves, but rather the lack of explanation of them and the lack of experience of the developer.
I do agree that the containers are rather messy though and a smoother implementation could be used. However this update will not eliminate them. They all serve a purpose that a lot of games rely on that you cannot simply remove.
There are some benefits to this update if this is the implementation they decide, as shown in your examples. I originally thought that the containers acted as a sort of âfrontâ to where theyâd actually run. I.e. you could place a client script in ServerScriptService and itâd default to PlayerScripts on runtime.
My concern with this update is that, although there are some cases where this makes sense, the majority of instances will act against the purpose of the container. Workspace is technically the serverâs copy of workspace which is then replicated to players, but yeah, I agree that having local scripts exist there is a good move. As for the other containers, I do not see the need to change their behaviour outside of a complete overhaul of their layout.
2 Likes
this might sound like a weird question, but does this have anything to do with keeping scripts safe from exploiters, for example, the script was on startergui, but its RunContext is set to Server, will that means its not gonna be accessable for the exploiter?
2 Likes
Love this update! this might help keeping some scripts safe away from exploiters.
Server and Legacy have the same exact purpose.
Any script set to Server can only run on a server and a âScriptâ (server script) set to Legacy can only run on a server. So why would they need a different icon? Both can only run on the Server.
Every script that is replicated to the Client, can be accessed by the client. (Doesnât matter if itâs a local script parented to StarterGui, or a script with RunContext set to Client).
I donât think you understand, scripts with server context also run in places like ServerStorage which legacy scripts do not.
The ByteCode is not sent if it is a server script, only the existance of the script.
1 Like
From how I understand it, even scripts with Legacy, depending on if they are local scripts or server scripts, will run Anywhere, server or client, depending on if they are script or localscript
are u sure? iâve tried but it doesnt seem like it does show the script, iâve checked places a client can access, such as PlayerGui, PlayerScriptsâŚ
This is incorrect, legacy scripts do not run in container objects such as ServerStorage
1 Like
Read my reply, I was answering his question about LocalScripts or scripts with RunContext set to Client for that matter. They wanted to know if Exploiters would not be able to access those local scripts, which they can because they can access everything replicated to the client
2 Likes