Seems pretty good although I probably won’t use it since I don’t think its proper formatting to store both client and server scripts in the same location and don’t think scripts should ever run in storage.
What happens when the script is streamed in/out, does it restart or does it continue where it left off or something else? Same with changing the RunContext on runtime?
Is there anyway other than the disabled tag to not run a script or local, client or server, in storage services? I know we could use the disabled tag and then whenever its moved out we change it again but I’d rather not have to add extra code encase something breaks etc.
This is by far the most useful implementation i’ve seen, mostly beacuse of allowing the scripts to run on almost every place you parent it on, including Scripts with RunContext set to clients.
The only issue i have currently is that Client RunContext Scripts won’t work if it’s replicated to the client.
Not sure why, but trying to reparent the script from the ServerStorage to the Player’s PlayerGui won’t work.
I mean, I already do this. I hold ALL scripts in 3 locations. RepFirst ( local only) / Replicated ( easy enough used on both) / ServerScriptService (Server only)
I’m waiting for this feature to be released, since it will reduce many performance issues. It really seems like the replacement for disabling FilteringEnabled.
That’s what they said with LocalScript when it was properly introduced into Roblox. Client contexts run for all players, and if you tell me, you don’t have any single thing in your game that doesn’t have something only running for one player, then I can tell you’re lying.
It was clearly removed when the addition of StarterPlayer was added.
Though I disagree with users who think it is right to place scripts into the storage containers. It feels very wrong and unnatural to do so. Workspace should be your Go-To for this, since it was around even before ServerScriptService and ServerStorage even existed.
This feature seems to be stable in studio, and we’re really looking forward to using it in our live games. Any word on when we can expect this to get out of beta?
An additional issue was identified just before we rolled this out to live games so we have extended the Studio beta until that is resolved. No ETA just yet
I just realized that this update will help new scripters, because LocalScripts have the ability to run anywhere! However it can then be confusing if scripts run in ReplicatedStorage and ServerStorage, since they are just storage after all. It’s fine though, new scripters would like to have this to start off with, since it’s easy to understand and visualize.
This is also a very good measure, as I would have never thought of backdoors taking advantage of this!
Would this additional issue happen to be that scripts are running twice? I was testing some stuff with the Instance:Destroy() changes and was using it and ran into some impossible behavior and switching out my Script instance running in a LocalScript RunContext to a regular LocalScript instance fixed my issue. Very weird stuff.
This is definitely happening because the original script inside StarterCharacterScripts is running as well as the one copied to the character (which is intentional):
Why is this intentional behavior at all? If I put a script in StarterPlayerScripts or StarterCharacterScripts I dont expect the uncloned script to run at all because it has no use. Just seems like a regression in normal behavior and makes the feature harder to use.
RunContext allows you to run a Client script to anywhere the client can see it. This is absolutely intentional because it allows you to run a script under any circumstances.
If you want that behaviour, you should be using a LocalScript Instance instead. Normal behaviour still exists as it always did, you’re just attempting to use with a feature that was not designed for your use-case.
Client - Scripts will run anywhere in the place including services such as ReplicatedStorage but only on the client.
This is still a bit annoying as it would be nice to just treat is as a feature to change what context your scripts run as but yeah I definitely got it wrong. Just a bit misleading when you only see it from the properties tab in studio.
