I can kinda see why this is cool to have because, you don’t need to directly place scripts into said container because you have a “switch” that does it for you now. However, I think that the ambiguity of this feature is a bit off-putting. It would be better, at a minimum, if each option told us where it’s going. Today, upon first glance, I wouldn’t know and to me, that sounds like a red flag for new users thinking this is some sort of cheat code to quicker code completion. Echoing what was said above, I still don’t know of a reasonable use case where I’d prefer this over normal convention for production-ready stuff. I can’t think of a reasonable reason why I would want my context to change or why this option exists. Just seems like an excuse for less organization and more hassle when searching for scripts.
Finally! Developing single player games will be so much easier! I can basically turn every script into a local/client script without parenting them to player/character containers
Of course not, they still keep the same limits as before this update.
Hmm… Well, that’s weird… I thought up a use for Client RunContext scripts today (“equipping” VR tools to a folder where LocalScripts don’t work then using RunContext to run their code) but now that I know the code would run for every player, I guess that’s not an option.
I think that property you suggested would be useful in both of our use cases. Otherwise, I’ll just have to use LocalScripts in the PlayerScripts folder and enable/disable them as needed.
So this means that Scripts set to Client RunContext can’t be manipulated?
No, nothing has changed except the fact that these “local” scripts can be put anywhere, which shouldn’t make a difference exploiting-wise.
this is great and im imagining the potential use cases for anticheats
one of my questions though: when is the expected release date for this, outside of studio? i really look forward to the ability to be able to ensure that the anticheat im developing using this works properly
I’m curious for the release date as well. I’m developing a feature for my game that is reliant on RunContext, but I didn’t realize it was a part of a beta until I published it and tested it in a live server.
In this “feature”, I have numerous problems.
- I cannot use LocalScripts that are parented under a part, like those used for ClickDetectors.
- AutoComplete is showing me server autocompletes, for example: RemoteEvent giving me autocompletes for :FireClient instead of :FireServer.
- The icon is not updating for me, Client RunContext scripts still appear as a script.
This is on a fresh install of RobloxStudio, 0.542.1.5420511.
Issues two and three are covered in the known-issues section of the original post. The first issue you mention is expected behavior. You should use a regular Script with it’s RunContext set to Client if you want it to run in a part on the client.
I have even more problems to report.
- Clients under teamcreate who don’t have the beta enabled override the RunContext variable to “Legacy”.
- This is not expected behavoir, LocalScripts are that: Local scripts. Are LocalScripts now disabled and cannot run under parts anymore, and only function under StarterPlayer/Backpack/etc locations? This was never like this before, and checking on the Wiki, I see that this behavior was altered at some point in time, where LS objects were prevented from executing anywhere. When was this changed, why was it changed, and why is a new feature being added to bring it back?
This “feature” has caused numerous development issues and I am forced to disable it due to severe production setbacks caused by this disaster.
The feature is enabled for all users but only in Studio. To each of your points:
- In the original post there are a list of known issues, the issue with team-create specifically is mentioned and will be fixed before the full release.
- LocalScripts have never been able to run anywhere. They can run in Backpack, PlayerGui, ReplicatedFirst, and the Character of the LocalPlayer.
I love this! Please release this feature soon! This allows me to write features that are game independent that can easily be imported without any additional movement of scripts.
Are there plans to make it have module scripts as a option?
We’ve been having a lot of success testing this feature. It’s been great for our workflow and has allowed us to make much better use of Actors, in circumstances where we couldn’t before.
Are there any plans to release this feature out of beta?
This works pretty well for me! I just forgot that its in beta and released an update to my game with it lol…
After some playing around I’m really excited about RunContext. For asset creators in particular this is going to really enhance the organization of packages and and ease-of-use of larger applications. Thank you to the team behind this for the awesome feature!
I was so confused as to why my script only worked in studio and not official servers lol… this feature is great imo hopefully it goes live soon
When is this going live? Ive actually found a really good use for this in my game, but I dont want to start making it until this goes live (so I dont have to wait a long time to publish the update)
I’ve been loving this feature, it’s been really helpful to both me and my team. Keep it up!