There is a possibility but I doubt it
correct me if Im wrong, but this means that normal scripts can also act like a localscript? and if so does this mean acual localscripts will be depreciated?
No LocalScript wonāt be deprecated because thereās still core engine workflows which will require LocalScripts / Scripts with RunContext = Legacy. For example, when youāre making a Tool thatās meant to be portable between games youāll still want to do that using traditional LocalScript / Script.
3 Likes
What are the implications of this in relation to services like StarterGui, StarterPack, StarterPlayer.
Prior to this scripts in these locations could never run because these services are designed to be ātemplateā services and the contents are cloned to other locations.
It isnāt uncommon to find people that donāt know LocalPlayer exists and will write:
local player = script.Parent.Parent.Parent -- (Player > PlayerGui > MyGui > script)
However if these scripts will now run in all locations that means the scripts will also run in these ātemplateā locations without a way of stopping them short of just returning to Legacy behaviour?
In cases like the above mentioned code this would result in returning BasePlate (not really what I expected to begin with) which can lead to random errors coming out of literally nowhere.
You can find the answer to your question in the FAQ. If you are asking more specifically about what this means for those containers then we have no plans to deprecate them.
1 Like
To be honest I dont know if this update is something useful or needed to, probably it is just a question of time to roblox ādeprecateā Legacy context.
i have same question, but I think that even if it is, the exploiters will always find a way to access the scripts
1 Like
May not be needed but it certainly can help organize things
1 Like
Everyone needs to stop obsessing about exploits and actually think about how this can be used. A little less conversation, a little more action. For my team, this is the best thing ROBLOX has implemented in years.
1 Like
I love this update but I have a somewhat controversial opinion:
Scripts should NEVER be allowed to execute from anything marked āStorageā.
ReplicatedStorage and ServerStorage should be completely inert - they donāt run physics, they donāt render, they have no collision, and they should also not run scripts.
I canāt think of a good case for why you would want things inside storage executing scripts, because storage is meant to be the place you parent/deparent things from or clone templated objects from.
I can back the idea of having a purist vision of āscripts can run anywhere, just use disabledā, but I think this case warrants further review. Perhaps a compromise would be a flag on ServerStorage and ReplicatedStorage that explicitly allows/disallows script execution, and it defaults to off?
(On the same idea, itād be very nice if we could have āShows in workspaceā flags on them too, but thatās a completely genie-wish-level request thereā¦)
6 Likes
Indeed, itās not necessarily that you want scripts executing in every storage location.
Itās that the price that you pay for having them not execute there is changing the number of special cases from zero to more than zero, and thatās a high price to pay.
4 Likes
Iām a bit confused, I thought you were able to run scripts with RunContext set to Client anywhere. Iām trying to run a simple print in ServerScriptService and itās not running at all with it set to Client.
When setting it to server or legacy it works as intended, am I misunderstanding how this works?
The reason it is called āLegacyā is because it essentially refers to āOld Behaviourā
1 Like
Now that the importance of script ancestry has been substantially diminished, protecting ModuleScripts will likely become somewhat less intuitive. For the sake of conformity, I think it may be beneficial if ModuleScripts were also given a context, which would determine if they could be required on the server, client, or both. Without such functionality, many game developers will still struggle to design self-contained systems, as modules are highly useful for organizational purposes.
1 Like
Thatās what I asked about.
1 Like
Yay! This will make creating models for the marketplace a thousand times easier! Thank you.
1 Like
Donāt see a big use for this update. The only thing I canāt think of using it for is making a toolās code run before itās equipped. I canāt wait to leak my gameās major scripts by accidentally pressing the down or C key after clicking on the RunContext property!!! 
1 Like
ServerScriptService and ServerStorage do not replicate to the client meaning client scripts do not run there.
2 Likes
Clients will still be able to see the bytecode of any script that runs on the client (LocalScript, ModuleScript, or RunContext=Client), but not source code.
1 Like
So a popular practice before this update was creating a local script for each individual player which could handle events such as special effects or sounds. This was useful for making such effects customizable without putting pressure on the server.
With this new update (assuming I understood it correctly?) you should be able to have a single Local Script with a Server RunContext property, that controls all client-sided effects / sounds, without having to place it as a descendant of the player / character (effectively replicating the client script to each player).
Anyone can feel free to correct me if I am wrong, I was confused about this at first as well.
2 Likes