In the same way as how server scripts parented in non-server containers are still not accessible by exploits, I assume the same applies to RunContext changes also.
The bytecode is simply not replicated to the client.
The icons will be receiving a further upgrade in the future to distinguish between scripts running in Legacy mode and scripts using the new RunContext options.
Does that not really then just defeat the whole purpose of the RunContext cuz you would never be running server code somewhere only local code can normally run meaning you would need them not to be in the same area in the end anyways.
Hopefully it should be like what @PysephDEV said or something like this.
This isnât clear enough, the fact that this is only enabled in Studio is not communicated well enough and will cause issues if it isnât made more clear.
So if I set the script to client
, it essentially becomes a LocalScript? If so, doesnât that defeat the point of having LocalScripts?
Yes, except unlike a LocalScript, it will run anywhere, on all clients that can access the location where the script is located.
That isnât true they DO have different icons. Client had the icon of a Local Script and Legacy and Server have the icon of a Script. Also Localscripts are not going to be removed (at least not now).
I cover it a bit in my original reply about self-contained free models that have local code. Previously, you needed to copy your code to every playerâs PlayerGui in a ScreenGui
with ResetOnSpawn
set to false (or some equivalent) and copy to StarterPlayerScripts
. Now I just need to put it in a container like ReplicatedStorage
and I am done. I am sure other reasons exist. My guess is this is meant to deprecate LocalScript
long-term and have a generic âScriptâ as the paradigm.
Could this cause issues where the localscript are parented to a player however, Iâm assuming it will run on all clients which is definitely a problem for anyone migrating.
If you read my post, I was stating that server and legacy do not have different icons.
If they break LocalScripts a whole bunch of games would break lol
Yes. Because Legacy and Server work pretty much but without the Parent limitation.
Edit: As explained in Abcreatorâs reply and the post below it, this isnât a good idea. However, OP asked for a script conversion tool. Use at your own risk:
You can paste this into the command bar:
for _, Script in game:GetDescendants() do
if not Script:IsA("LocalScript") then continue end
local source = Script.Source
local newScript = Instance.new("Script")
newScript.Name = Script.Name
newScript.Disabled = Script.Disabled
newScript.Source = source
newScript.RunContext = Enum.RunContext.Client
newScript.Parent = Script.Parent
Script:Destroy()
end
But that limitation is an issue, that limitation could cause issues in-where a script that looks like it shouldnât be running is because of there being no icon difference.
This is not true. A LocalScript will not run in a container such as workspace, whereas a Script with Client RunContext will.
Donât do this
Any scripts inside a player-specific location (such as a player character), that is also replicated to other players will then run the code on all clients rather than just the singular client.
Iâve found an issue, if you put a script under StarterPlayerScripts, itâll run twice due to being in both StarterPlayerScripts and PlayerScripts. You can reproduce this by just simply putting a script into StarterPlayerScripts and printing the scriptâs parent. I think a simple solution would to not run any scripts in any Starter Services due to them being cloned and moved somewhere else.
This is likely intentional, use regular localscripts if you are going to place them in there.
Then that defeats the purpose of this new feature, doesnât it?
But⌠why would you want to use StarterPlayerScripts anyway, as now you can put it in ReplicatedStorage and it will run?