This is absolutely amazing!
Now I can finally put client scripts in Workspace and other locations where normally server scripts would only run.
This is going to make it much easier to make a singleplayer-oriented game where I just want most logic to run on the client and not change the locations of the scripts.
Restricting where scripts can execute as a place-wide setting might be a good deterrent for “virus” free models. A lot of malicious scripts parent themselves to hidden services, making them harder to detect.
I’m sorry, but I don’t feel like there is much of a use case to this. Because of the fact that plugins can change a server script to a local script in ONE click.
We also can’t change the scripts run context from other scripts. Making this just like having a local script in a script. When we could just change it in an instant instead.
Please explain, how this is useful? Have I misunderstood something? Or is this feature just something Roblox decided to spend time on for no reason?
I am having a similar issue when I open up older versions of scripts it just flat out crashes my studio and its done it ever since this update
This needs to be fixed
I am using version: 0.541.0.5410422 (64bit)
Really don’t understand why this was needed. Seems like a waste of time for the engineers. I think the current system was fine.
We tracked down the script version history issue. Reverting to previous versions should work again now after a Studio restart, sorry for the trouble.
FYI: We had to disable the code that changes the script icons depending on the RunContext to fix it. RunContext will still behave they way it should but the icons won’t switch depending on RunContext for the time being.
No, in a server-side context, reading Players.LocalPlayer will always return nil. The server is a manager of all players, not just one. Only a LocalScript, ModuleScript required by a LocalScript, or a Script with its RunContext set to Client can successfully get a value out of it.
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.
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.
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
May not be needed but it certainly can help organize things
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.
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…)
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.
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’