[Live] Script RunContext

Updates Announcements
, , ,
#355

Obviously and exactly.

#356

even in serverscriptservice? if so then i have to look for something else…

#357

I don’t think runcontext client works there. Only in stuff like Workspace.

#358

its a shame, but it makes sense. thanks

#359

I think the server can only edit RunContext. It won’t actually send the script to the client if the client changes it.

#360

Actually the client can edit RunContext is just won’t be replicated to the Server. RunContext also has PluginSecurity so no normal script can edit it.

#361

Yes, but there’s no point in the client editing the property. The only thing they could do is stop scripts with client runcontext.

1 Like
#362

No, as we don’t replicate the source code of scripts to clients. We also don’t replicate changes from the client to the server so even if the client could the script would only run on their device and not anywhere else in your experience.

#363

image
image829×86 33.5 KB

RunContext Client is really broken in ReplicatedStorage.
This seems to occur only in mobile or all devices randomly.

in example error picture above, “script” variable changes from roboball to SceneService somehow (or something else is happening like game mistakes location of both scripts)
roboball code:
return script:WaitForChild("ModuleScript")
child of roboball runcontext client code:
require(script.Parent)

also note: RunContext under SceneService is same script ( require(script.Parent) ) as the roboball one

@WallsAreForClimbing

1 Like
#364

I didn’t actually know about this until today. Is this really needed?

#365

It would be nice if there was a way to prevent the bytecode in ModuleScripts from being replicated. Bytecode can still allow exploiters to reverse engineer server-side security if replicated, which means many modules still have to be split off into ServerScriptService if they contain any server logic you don’t want exploiters to see.

3 Likes
#366

We should be able to disable replication of server scripts with a Server or Legacy RunContext (the Script instance itself) since it just isn’t needed on the client.

#367

Scripts with these specific RunContext enums already don’t replicate their bytecode to the client. While the instance itself may replicate; the code won’t.

2 Likes
#368

Yeah, so why is the instance replicated? Why can’t we choose what instances are replicated?

#369

Oh my god finally now I can use AncestryChanged to detect the script is deleted with RunContext!

(not really :frowning:)

1 Like
#370

This would most probably be part of a separate feature.

#371

RunContext actually makes backdoors more efficient

1 Like
#372

I think this one’s a bit buggy.
I was trying to make an ability and when I pressed my UserInput ONCE it ran the script in a weird order, twice.
Meanwhile with a regular local script it did it the way it should do it.
Also found out the printing in a Client runContext script doesn’t work the same way as in regular local script. It prints the same thing over and over, meanwhile the regular one prints it once and then goes like Hello World(x78)

(runContext - Client)

image
image1014×472 124 KB

(regular Local Script)

image
image1041×234 40.1 KB

1 Like
#373

Are you cloning the script from somewhere? Scripts that use RunContext can run anywhere inside the data model, and this includes the client scripts. So the original script might be running at the same time if it is enabled.

1 Like
#374

The regular local script was disabled at the time of running the RunContext script and vise versa.

There is only one script of each kind(local and runContext)

The code inside the scripts is the exact same