So, if I create a server script with client run context that manages the purchases in some shop, would exploiters be able to hack it somehow? Because I’m unsure whether it is accessible by the client or the server.
It works just like a localscript the main difference is that it will run anywhere
1 Like
No, refer to the original post for more information about this topic.
Is this out of beta yet (aka is it publishable in “real” game instances yet)?
or will games with scripts under runcontext client still be run in their legacy context?
Nvm, it still is!
Wanted to give you all an update on when this would go live. The issue mentioned before has now been resolved and while we cannot give you a specific date we are looking at enabling this very soon so keep an eye out for the announcement.
Thank you all for taking the time to try this out before we release it!
17 Likes
ModuleScripts run on the script they were imported on, so no.
Will RunContext be able to be run in Live Games once this features comes out of beta?
1 Like
The meaning of beta is that it doesn’t run in live games 
.
2 Likes
Both of you are 100% correct. It will be available after RunContext is released (I believe it was stated earlier in this thread).
1 Like
I encountered a very strange bug when using this thing.
So for some reason scripts with Client RunContext recieve RemoteEvents from the server twice. However this does not accur in LocalScripts. I cannot post this in #bug-reports, so I am posting this here.
(my post if anyone needs - RemoteEvent is being recieved twice for some reason - #10 by AlternativeOrNot)
Quick question, where exactly was this script located within your game?
1 Like
It was located in the StarterGui.
This is in fact expected behaviour.
Your script wasn’t receiving the event twice, it was in fact being cloned into the Player’s GUI. Since StarterGui also replicates to the player, there were two active instances of the script.
2 Likes
Thanks. But why isn’t this a thing for LocalScript though?
Interesting question!
Since LocalScripts were introduced, they only ran in specific places. Meaning that if they were parented to anything else; even if the client could see them, they would not run it. You can find an up-to-date list of these places here: LocalScript | Roblox Creator Documentation
There are many reasons behind keeping this behaviour. For example, most tools with scripts in them would break completely as the LocalScript in them only ran for the current user.
To allow for a better code structure, Roblox needs to give a tool for developers to control for themselves where scripts run. RunContext is that answer. The consequence of this is that you as a developer need to handle whether the script runs or not by yourself. You could, for example (although I don’t recommend this as LocalScripts are not being deprecated at this time and perfectly suit your use case), add this to the start of your RunContext Client script:
if not script:FindFirstAncestorWhichIsA("PlayerGui") then return end
This should fix your particular issue, as it would prevent the script from running outside of a player’s GUI, when cloned.
4 Likes
Shouldn’t it be
if script:FindFirstAncestorWhichIsA("PlayerGui") then return end
?
Nevermind i just re-read the post.
If you need to do this, try creating a moduleScript and then having a Server Script and a Local Script that require it contained inside. For example:
1 Like
Has a new issue arrisen? Have been looking forward to this so I can use it live.
3 Likes
It’s been live since yesterday morning. There is the possibility that it could be turned back off though.
3 Likes
We enabled this quietly on Friday so you will now be able to use it in your experiences!
15 Likes