Yes! Thanks! Luckily some of us might have noticed this post, why quietly though? The roblox studio notifications channel is really useful for us the developers 
1 Like
By enabling things a few days before announcing them we have an opportunity to monitor them before they are adopted by developers.
6 Likes
Noticed this being enabled, very helpful for saving server resources for some things in my game. Glad this is being released!
1 Like
For those saying this has no use case, you can now place a localscript inside of an instance, so that when that instance is deleted, the localscript is deleted too.
Iām actually using this behaviour in an ECS Iām developing to make object oriented programming more powerful and reliable. This change just allowed me to have oop instances automatically clean up their connections.
Yes, I could have coded this with tags, but this saved me a ton of code, and made everything surprisingly more organized, as the functionality tied to the entity can now be found as a child of the entity, which is easily accessible, instead of having them all crammed up in one space.
And no, I canāt just use a metatable, those donāt clean up automatically like a deleted script does, I donāt want my programmers to have to take care of complex memory leaks.
9 Likes
Are there any plans in the future to apply this change to ModuleScripts?
Modules can run anywhere already depending on what type of script you require it with
Yeah, thatās exactly my problem, I donāt want any funny business with exploiters.
Then again, maybe I should opt myself with different methods instead, since my use case isnāt optimal: a ModuleScript wonāt stop running once deleted, therefore my request is void now that I think about it.
1 Like
When I put a script with RunContext set to Client in StarterPlayerScripts, it will print āhello worldā twice. Is this intentional behaviour?
Edit: I scrolled up and found the answer.
Hey there! After using run context, Iāve really liked it. But thereās a problem: Iām trying to print the run context of a script by doing this: script.RunContext.Name, but it errors saying I donāt have to print permission to edit it even though Iām just reading off of it.
What is your use-case for reading RunContext at runtime?
I was trying to make a custom debugger system that told you the context of the script requested. I just donāt understand why we canāt read it because it doesnāt change anything about to e script.
In my case, I need to determine if a script has a RunContext so I can disable it accordingly in one of the storage containers (e.g., ReplicatedStorage, ServerStorage), and then enable it after cloning and parenting the script.
Does this debugger operate as a plugin? If so you are able to read RunContext from scripts running at the plugin security level.
Just wanted to ask, is the client able to read the contents of server sided scripts that reside in a place the client can view? As you said, I am pretty sure it only sends the bytecode to the server as usual.
From the original post:
1 Like
Alright thanks for the info.
One more question:
Do you think I should disable scripts before re-parenting them? or will they be fine.
From my understanding:
Script with RunContext set to Server ā Runs anywhere on server
Script with RunContext set to Legacy ā Runs in most places on server
Script with RunContext set to Client ā Runs anywhere on every client
LocalScript ā Runs in designated places on the client that it belongs to
You are correct. I find this update useful mainly because I can keep all my framework scripts inside of ReplicatedStorage without having to move them. It also cuts down on LocalScript instances because they donāt get cloned every time a player joins.
1 Like
Just wanted to mention:
They can run on the client as well, just not containers that are cloned like StarterPlayerScripts.
say one uses a script under ārunContext = clientā. would this mean exploiters could edit the script?