[Live] Script RunContext

[BenMactavsin]

It does change icon though, you should’ve tested it first before making this reply.

[WallsAreForClimbing (Climber)]

@bostaffmanbulgaria1

Does this mean that we can just make contact with client and server scripts easier without sorting each on a different place?

Yes. You can parent both scripts to the same container alongside other instances such as remotes.

[Dev_30234]

This is good change, i can now run freemodel scripts locally on the client and don’t need to re-code them into modules.

[PysephDEV (Pyseph)]

This is a good change and would help in some of my workflows, but the wording is a bit confusing. “Legacy” implies at least towards some extent that it’s old and/or unwanted behavior, which is definitely a bit off putting considering everyone’s codebases use said ‘Legacy’ behavior as it stands now.

EDIT: additionally, have any considerations been made towards script icons which would visualize scripts with non-Legacy contexts? I can imagine developers getting very confused trying to debug why some scripts run and some don’t, without there being any clear visual distinctions.

[Dev_30234]

I think they should call it “Default” or “Standard” or something

[PysephDEV (Pyseph)]

I was also going to mention “Default”, but Roblox uses it in a lot of automation contexts, where “Default” is a bit non-descriptive and subject to change. Of course, I’m not a staff member, so they know the better decision to make even if it may not be one we’d agree with.

[MagmaBurnsV]

If that’s what this change is meant for, then the behavior of how changes to RunContext are reacted to needs to change.

Going off your recommendation, I would have a setup similar to this:

But now the client can change my Server’s RunContext to Client and it would allow it to read its bytecode, efficiently allowing exploiters to completely copy my game’s codebase.

[xKiiyoko (Kiiyoko)]

@MagmaBurnsV

But now the client can change my Server’s RunContext to Client and it would allow it to read its bytecode, efficiently allowing exploiters to completely copy my game’s codebase.

I’m guessing this is definitely not intentional behaviour. I don’t think the bytecode would replicate over ingame.

[PysephDEV (Pyseph)]

As mentioned in the thread, the context can only be changed by plugins in studio. It is not editable at runtime.

[nidbahn]

@RoyallyFlushed

I do not see a need at all for Client scripts to be in ServerScriptService. It just doesn’t make any sense.

Yep, I don’t either, especially considering the fact that ServerScriptService is not accessible to clients. It won’t run in any case.

@RoyallyFlushed

It’s hard enough explaining what all the containers are for in the first place as Roblox’s documentation on them is extremely lacking, especially when looking at the caveats of each of them.

And thanks to this update, we will be able to get rid of some of them!

@RoyallyFlushed

I do not see an issue with what we already have.

I do. It’s an inconsistent mess that forces developers to put scripts in certain locations, resulting in scripts for one thing being scattered all over the place.
Like, why do Scripts run in Workspace but LocalScripts do not? This seems like nonsense to me.

This update will make development a lot more straightforward in certain cases. Look at these examples:

@nidbahn

For example StreamingEnabled: if your client code depends on a part in workspace, instead of using CollectionService and a localscript, you can put the script in a part and set RunContext to Client.

@TheNexusAvenger

This change is huge for me as someone who creates free models that add local scripts while being self-contained. The loading code I had in the Innovation Inc Railgun, Nexus Admin, and Nexus VR Character Model is something I will be happy to finally remove.

[Voidage]

I think exploits allow scripts to run with an elevated privilege, allowing them to edit stuff like this.

[tnavarts]

@MagmaBurnsV

But now the client can change my Server’s RunContext to Client and it would allow it to read its bytecode, efficiently allowing exploiters to completely copy my game’s codebase.

The client can change the RunContext to client… but as with any other local change that change will be well… local, and won’t replicate to the server, so the attacker won’t get anywhere that way

[PysephDEV (Pyseph)]

Elevated execution privilege wouldn’t allow them to bypass network restrictions and replicate non-replicable changes. Even if they could, I’d presume there is no code which listens to RunContext changes in the engine to begin with - only in studio. Changing it at runtime wouldn’t achieve anything.

[texticks (tex)]

Allowing Localscripts to run in workspace without needing a player instance is honestly really cool. Great update!

[Voidage]

Didn’t say it would allow them to get anywhere. I just said with elevated privileges you can change things that are normally not allowed to be changed.

[Automationeer (Eleanor)]

Will RunContexted scripts run in hidden instances? If so, this could be utilised by malware plugins to hide backdoor or other malicious scripts in games.

See also: Script Injection Vulnerability

[LifeDigger (Life)]

This update although is good is gonna make me get confused and take time for me to get used to why there is code running locally in the workspace or other place local scripts don’t normal go. I think there should be some better type of indication that it’s not just a normal local script.

[MagmaBurnsV]

I was referring to the client actually getting the scripts bytecode, which can be decompiled and converted back into normal Luau, allowing the attacker to read my Serverscripts and potentially be able reconstruct my codebase. I would never want anyway for clients to have access to that.

[TheNexusAvenger (Nexus)]

Your best action would be make it so the client never sees the scripts with services like ServerStorage and ServerScriptService. If the client can see the bytecode - which changing the RunContext locally shouldn’t affect since it shouldn’t force the server to give up the bytecode like that - your best bet is to make it so the client never has a chance to see it if it doesn’t need it.

[Abcreator]

This update negatively impacts my workflow as I am no longer able to search ‘LocalScript’ to get all scripts running on the clients context, may I ask how this makes the developer experience any better than just being able to run LocalScripts in Workspace and ReplicatedStorage, and making ServerScriptService basically useless (as ServerStorage can work for it too)?

Also, there seems to be no icon difference between the server and legacy RunContexts which is misleading as those scripts do have different runtime behaviours (one running in containers while the other one does not)