That would be horrifying. Localscripts grow up with roblox, and now they’re removing them? 
They won’t be completely removing them. They will just be deprecated. You can still add them by checking the checkbox show deprecated items in studio settings and then clicking the plus button. It isn’t confirmed by them to deprecate them it’s just a thing people assume might happen.
2 Likes
Found a bug. Script with RunContext set to Client does not provide autocompletion for client-only methods or properties (LocalPlayer, FireServer, etc.), while LocalScript does.
4 Likes
Hey, I’m having an issue with the new update where every time I’ve left the studio and reopened it, Scripts set to Server default back to Legacy every time.
Not sure if this has been reported already but just wanted to report it here. It’s happened every single time I’ve left studio and reopened it on the place.
3 Likes
This literally would change nothing for that.
That’s not true at all. Now I won’t have to write the code in the models for reparenting & replicating the local scripts to all current clients and then set the original in starterplayerscripts.
2 Likes
Question: would you still have to create separate scripts, for the Client and Server separately? One script with RunContext set to the ‘Client’ and the other set to the ‘Server’?
You still have to write the install script, this literally does not change anything for you at all.
Apologies if this is bordering off-topic. But this beta feature raises the question of: can the “X Context” concept be included in other kinds of instances in the future? For me, converting an image label to an image button just by setting its “GuiContext” from “Label” to “Button” would be a lot more useful especially for people like me who want to go back and change a Frame to a ScrollingFrame or a Viewport Frame and don’t want to have to copy each individual property that I modified (and sometimes forgetting which ones I did modify)
If this is the case, then can you explain what this means more accurately?
2 Likes
Same Issue I’ve had, I think its something to do with team create and having people that aren’t enrolled in the beta feature, haven’t tested it yet, but I think its that
This is really cool and really useful, my only issue is that for some reason UserInputService seems to always fire events twice? While on localscripts it doesn’t???
Oh yea and autofilling always assumes that if the current script is a Script then it always presumes server autofills (FireClient, etc)
4 Likes
We have a fix for this in the pipeline. Expect to see it soon!
3 Likes
Do you have collaborative editing enabled? If so this is a known issue and will be fixed in an upcoming release.
1 Like
Yes, but you can store shared code in a ModuleScript which can be required from a script in either context.
2 Likes
Thank you for your reply, I do indeed.
1 Like
Does “Client” RunContext work exactly like LocalScripts?
I’ve made use of LocalScripts a lot in order to especially fill out User Interfaces automatically from data tables and data sets passed through events and ReplicatedStorage in the past. Will I have to modify any behaviours of this or could I in theory just copy and paste the LocalScript contents into a Client-RC Script and have it run as if it were a LocalScript
Yes, though the Client-RunContext script will likely live in a different place in your hierarchy (It would go under Workspace or ReplicatedStorage rather than one of the Starter containers)
1 Like
Will Players.LocalPlayer still work the same as well?
(I know it’s probably not a good question to ask but it is trippy to think about Players.LocalPlayer finally returning something in a regular Script instance).
Exploiters can’t abuse it right?