Very interesting update for sure, I understand the up’s and downs of this, however, it’s going to be very helpful to me when I test a script in both client, and server, and will be very simple to do.
3 Likes
I have been waiting eagerly for this ever since I heard it was being worked on. No more having to make code that loads client scripts!
4 Likes
Does this mean I can just parent my Init script in ReplicatedStorage instead of buried in StarterPlayerScripts? Yes!
Curious as to why you guys opted for having a unified script instance instead of just keeping the two different classes and adding a property to the LocalScript to make it run anywhere in the DataModel. Since client and server scripts are now going to have the same ClassName I can’t tell if a script is supposed to be ran on the client or server without checking their RunContext property with an enumeration.
5 Likes
Question, how will Client RunContext scripts behave under these circumstances:
With PlayerGui, PlayerScripts and ReplicatedFirst it’s pretty obvious, but what about Backpack and character model? Will all clients run the scripts or only one client?
11 Likes
Does this mean that if you change a Server Script (Script) to client mode, its code will be replicated to the client? If the RunContext remains as Server or Legacy its code will be protected and not replicated to the client no matter where it is, correct?
→ Also, will LocalScripts get superseded by this feature in the future?
1 Like
Unless I read the post incorrectly, the BaseScripts are still separate classes; the new feature is the property
1 Like
I have been waiting for this for a long time, such a wonderful update, will make script structure so much more intuitive.
However, it would be nice if we were to be given a few examples, and use cases. I have my own reasons to use this, but to see something laid out in code as an example would really help me and others, to get a firm grip on what this can do and how to use it properly.
1 Like
The only issue I can see so far is that it potentially allows bad actors to hide malicious scripts in places that would be hidden in the explorer (services that are normally hidden unless you enable a setting within the studio settings that new developers may not know exists).
This is less of an issue since the toolbox/plugin marketplace is more secure now than it has been in the past, but developers just getting into Roblox development may still be caught out.
3 Likes
Will we be able to use this feature in Legacy mode after it’s fully released? I have already spoken to my team about this and Legacy mode works fine for us. I do not see this as useful other than to cause confusion.
1 Like
Source containers other than required module scripts should never run when parented to a storage container. This functionality has been around since before even ReplicatedStorage/ServerStorage through Lighting and many of us rely on it in existing code bases.
This specific aspect is a breaking change for anyone who wants to try out the new feature, requires modification to existing code (however minimal), and really doesn’t serve a purpose.
5 Likes
This is an interesting update. It would be great if you guys could elaborate on exactly what this brings to the table other than just the ability to switch script types without making a new script.
As for allowing scripts to run in different places I think this is an extremely bad move. The current implementation, while not well explained at all, actually serves a pretty important role in organization of one’s codebase.
Server Scripts and Client Scripts should not exist together in a single environment because it paints a false picture of how the game will run. Not to mention anyone trying to work with a codebase that has this kind of thing will struggle to find their way around.
Client Scripts should only exist where they can run, same with server scripts. Allowing Server Scripts to run in ServerStorage defeats the point of the container.
Maybe I’m not understanding this right, but to me this change is a very bad move and will only cause less experienced developers to run into more problems, both confusing them and making their codebase virtually unreadable.
9 Likes
False. It’s actually going to make it easier as scripts will have consistent behaviour, regardless of location.
4 Likes
Does this mean we can now use normal scripts as local scripts? I don’t really understand this update tbh.
RunContext can only be changed by scripts with plugin permission so unless the script has that permission it will not be able to change the property (including its own).
5 Likes
The Legacy behaviour is not planned to be deprecated in forseeable future, right?
We have no plans at the moment to support running a single script in both contexts. If this is something you feel is valuable then make a feature request and we can review it.
9 Likes
@HugeCoolboy2007
I was referring to the distinction between LocalScripts and (Server)Scripts. This change allows for (Server)Scripts to be set to run on the client if the RunContext is set to Client. I would rather opt for a single property in LocalScripts that allowed for it to be ran anywhere on the replicated client
Testing around with this, apparently this change can also allow clients to dynamically change replicated (Server)Scripts RunContext to client and it will load that script’s ByteCode and run it, meaning exploiters can now get exposed Serverscript code if they’re not in ServerScriptService/ServerStorage.
I’ve also tested out with what @nidbahn asked and apparently if a script’s RunContext is set to client and gets parented to a replicated place it will run for ALL clients, despite the fact it’s parented to only one Backpack.
Repro (34.6 KB)
6 Likes
There are no plans for one but we’ll keep an eye on this request in case it becomes a common ask.
1 Like
One consideration was that this opens up the possibility of us adding additional RunContext values beyond simply Client and Server in the future for more specialized tasks, without us needing to pollute the engine with additional Script subclasses.
19 Likes
Except they won’t have consistent behaviour. This isn’t going to change the functionality of the containers. Replicated Storage will still replicate to the client before Starter Gui does. StarterPlayerScripts will still run after ReplicatedFirst. All this will do is cause players to wonder why their code is doing different things on the Client and Server and at different times. I do not see a need at all for Client scripts to be in ServerScriptService. It just doesn’t make any sense.
As someone who’s worked on quite a few large codebases, this will only cause more confusion for new developers.
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. Now we’ll have to explain that client scripts and server scripts are one and the same but also not one and the same. I do not see an issue with what we already have.
1 Like