[Live] Script RunContext

[WallsAreForClimbing (Climber)]

Hey Developers,

We are excited to announce RunContext.

What is RunContext?

RunContext is a property of Script that allows you to control where it will run in your experience. Initially it has the following options but we may expand on them in the future:

• Legacy - Scripts will run when parented to specific containers. This is identical to the current behavior many of you are used to and is the default for this property.
• Server - Scripts will run anywhere in the place including services such as ServerStorage and ReplicatedStorage but only on the server.
• Client - Scripts will run anywhere in the place including services such as ReplicatedStorage but only on the client.

Each option also has a unique icon to make it easy to tell them apart when you’re editing your experience in Studio.

You can try it out by opening up Studio and changing the RunContext property of any Script in your experience.

Why are we making this change?

Here are a few of the motivations behind us making this change:

• Client and server code can exist in the same place making it easier for them to share resources and for asset creators to make models that ‘just-work’.
• The behavior of Script and LocalScript can be consolidated into a single instance making it easier for us to introduce new script types in the future.

How can you use it?

As mentioned before, client and server code can be put in the same place making it easy to create packages that have both! Here’s an example using our Selfie Mode developer module.

To start with we are enabling this feature in Studio to give you time to try it out and for us to ensure there are no outstanding issues. Please try it out and share your experience here! Once we make sure we address the feedback we will enable it in live experiences across the platform.

Documentation

• RunContext Property
• RunContext Enum

FAQ

Will this let players see the source of my scripts?

No. We never replicate the source of your scripts to the client. Instead, if the client needs to run the script we will replicate its bytecode. This only happens if:

• The script is a LocalScript
• The script is a Script with its RunContext set to Client
• The script is a ModuleScript

As an added security measure RunContext can only be changed by plugins in Studio. Even if there was a backdoor in your experience an exploiter would not be able to take advantage of this to change the RunContext and get the bytecode of your server scripts.

What will happen to the 'Legacy' context after release?

Legacy is just the name we are giving to the existing behavior. It will continue to be supported after we fully release this feature so you can continue using it if you prefer to.

How does this affect LocalScripts?

We are planning to update the icon of LocalScript so that it is different from the icon we use for the Client RunContext. Other than that we understand how important they are to so many experiences so we have no additional changes planned for them.

How does RunContext interact with 'Starter' containers?

Starter containers work by cloning their contents locally therefore they will make a copy of any scripts contained in them. If you are using one of the new RunContexts such as Client or Server then both the original scripts and their copies will run. Therefore, you should continue to use the Legacy RunContext or LocalScripts in these containers.

What if I don't want scripts to run in certain places?

Scripts can still be disabled through the use of the existing Disabled property.

What happens if RunContext changes at runtime?

RunContext can only be changed in Studio, either from the properties widget or with a plugin. If its value changes while the script is running then the existing thread will be terminated and the script will start running in the new context.

How does RunContext work with Streaming?

As scripts are streamed in and out from the client they will naturally start and stop executing.

Are there plans for a 'Plugin' RunContext?

Some of you might have noticed that the RunContext enum also contains ‘Plugin’. In the future we are planning to add an option for scripts that should run in plugins specifically.

Known Issues

• You may experience different behavior in Studio as we handle replication differently. We are looking at ways to make this more consistent with how RunContext works in experience.

[rabbi99 (Stellar)]

This is a fantastic update for me and the fellow scripters on Roblox! I was wondering why this was not added sooner, but I’m so glad it’s added today! This’ll be very useful for making client-sided scripts to be ran in the workspace for every client and other things of course, but mainly that! Keep up with these awesome updates! Can’t wait to see what other improvements will be added!

[Codesense (Code)]

I really love this update. This is going to make systems so much more compact and easier to use across multiple projects. I made this comment before using it in a project and realizing its significance:

I’m not sure of the use cases for this? Is this more just to remove the confusion between different kinds of scripts? Can’t wait to give it a try.

There are so many use cases for this feature.

[Corruptux]

Can you change a script’s RunContext using itself?

Amazing update btw!

[LordMerc (Merc)]

What was the most needed use-case for this? This doesn’t truthfully seem like a needed thing.

[Alts_alt (Joe)]

Will there ever be a RunContext that runs the script in both Client and Server.

I’ve had a few occasions where I’ve had to have 2 script do similiar things with slight changes. and just use RunService to modify. Currently the workaround is to just have the Script and Localscript require the same module.

[Jas_nRuski (Jason)]

This is exciting, I suppose, but also brings a bit of confusion and worry to my team.

• Is RunContext meant to replace some LocalScripts?

• Can you invoke client-only methods by a script with run context set to client?

• If a script has its run context set to client, does that mean the source of the script will be exposed as well?

• What’s the practicality of this feature? Wouldn’t this be prone to some sort of exploit?

[SharpSerious]

I anticipate this will bring more problems than it solves as it was perfectly fine before. I don’t see any propose or use-case for any of this and I’m a little confused to as why this is added due to the confusion it brings for pretty much everybody.

There’s also the case to be made that forced organisation of where scripts should be is actually better, because then anyone can hop into a project knowing where everything is.

[cnr123451 (Cnr)]

Awesome update! Two questions:

• Will there be a built-in LocalScript migration feature?

• What is the difference between Legacy and Server as of right now? Will there be more differences in the future?

[BlueyHeeler96 (Bluey Heeler)]

Actors for parallel scripts on clients won’t be restricted to being parented under the character/player anymore. I won’t have to cram them all in one spot anymore.

[UnderMyWheel (Wheely)]

What is going to happen to scripts running under the “legacy” system once RunContext fully releases?

[BenMactavsin]

@cnr123451

What is the difference between Legacy and Server as of right now?

Your question is already answered inside the post:

@WallsAreForClimbing

• Legacy - The script will run in specific containers (identical to the current behavior)
• Server - The script will run anywhere on the server

[SharpSerious]

It could just be modules inside ReplicatedStorage with a runtime script inside character. That’s what a ton of people do with for example Knit

[librashards (libra)]

The original post mentions a good one.

@WallsAreForClimbing

You will be able to quickly switch where a script runs. No more copying source code from a Script to a LocalScript.

[Eddxys (eddy)]

So this means that LocalScripts aren’t needed anymore? I could just pop a script and change its RunContext to client. Does that make any difference from the LocalScripts?

[librashards (libra)]

LocalScripts will behave the same as changing a script to client,
FAQ mentioned it.

[MrAfoba (Afoba)]

I am quite confused as to what uses this update as over what was in place. Can I be illucidated?

[Jas_nRuski (Jason)]

But this wouldn’t be practical and will essentially make module and local script useless. Furthermore, I feel like it’ll expose the server itself to potential vulnerability to the server itself such as running server-sided exploits. If my statement stands, it will essentially make knit, arrow, and other dependencies/frameworks useless.

[OppaStoppaStomppa]

@Jas_nRuski

• Is RunContext meant to replace some LocalScripts?

Obviously this isn’t an official statement but it appears that one of the biggest use cases for RunContext is to effectively “bundle” scripts that work in conjunction with each other. In the example screenshot provided you can see that there is a ModuleScript named SelfieMode, which contains a local script and client script.