Well, perhaps we are reading it differently.
The way I understand it, with this change, even Legacy, can run anywhere within their client/server scope.
Maybe I am wrong, but that’s how I interpret it.
that proves my point if im not mistaken? a serverscriptservicewith script with its RunContext set to client, cannot be accessed by the client
Okay, i understand now, thank you.
This is not a fact of interpretation, try it, put a script with the legacy context in ServerStorage and see if it runs. It won’t. Then try the same with the context set to server, it will run.
Yeah, it’s even mentioned in the OP
3 Likes
yes, i just found out, thank you so much!
WAIT… im quite confused, so does that mean they are safe or?? because the other guy said that its replicated to the client…?
Scripts in ServerStorage and ServerScriptService are not replicated whether they are server or client, so they are safe
2 Likes
Omg thats so good to hear then! thank you so much!
To summarize all this:
-
If your code can’t be run on the client (Because it’s a
ServerorLegacyscript), then it won’t ever be sent to the client (to avoid accidentally leaking code). -
If your code can be run on the client, but is in a non-replicating container (E.g.: A ModuleScript in ServerStorage), it also won’t be sent to the client.
Really the only case you have to be careful with is ModuleScripts containing server code which you want to keep private. You have to make sure to put those somewhere like ServerStorage because if you put a ModuleScript in ReplicatedStorage we have to assume your client code might require it at some point and can’t automatically protect it.
15 Likes
Okay i get it now, thank you so much, this update might help me alot.
And you expect others to be able to know where you suddenly put your files? The entire point of for example frameworks is that you know where things always are and this helps defeat such purpose. Now If I jump into commission as a programmer for a project, I’ll have to look around, ask them where the files are instead of actually just knowing where they are.
Personal preference is not always the way to go and when it comes to programming, things should be organized and structured.
2 Likes
You are correct, I just tried it myself, and indeed, Legacy is holding onto the old restrictions of which container it can run on, there DOES need to be an icon change for this, as it is very important to be able to see at a glance the scope of a script.
2 Likes
Well, this update is something. Don’t know what I would need it for however…
1 Like
But programming isn’t the only aspect of Roblox development.
There are other things that scripts need to work with, and with this update it will be much easier to integrate scripts into other structures.
2 Likes
Just tested this, if you leave ‘RunContext’ on legacy it won’t run
1 Like
Anywhere??
Even inside CoreGui??
2 Likes
if you can put scripts anywhere then I want to put a script in core gui to remove core scripts
1 Like
I just tested this. Really neat! Now client-sided scripts can actually run in the workspace, which will make certain things a lot easier to script (such as objects of which you want a variable number.)
1 Like
Hey this is weird but my live games completely fail to update the scripts I can only experience changes in studio (for reference its a team create place)
5 Likes
So we should discourage following guidelines and organizational structures which helped everyone involved so that people are free to do it the wrong way? I don’t see how it’s good for the individual because doing it the right way helps them become better. There are reasons why for example in code, we use PascalCase, camelCase, UPPER_SNAKE_CASE for different scenarios, there’s also reasons why private functions are declared with _func(…) as examples.
It’s because great programmers have come up with a global standard for how things should be written so that we don’t just throw in things randomly and organizational structure is no exception.
3 Likes