This is amazing! All of my games run on my game framework, this will let me condense my framework code into one singular place which will allow for easy installation and separation of core and user code
This is the very first thing that came to mind too, really excited for this!
Would clients be able to view source code of modules in here though? or will we be able to set what the client can or cannot read?
Just a question about the new, “ReplicatedScriptService”, will all scripts, both local and server scripts, be replicated towards the client? Or just the local scripts? Or none?
I’m asking this because there wasn’t a documentation on the Developer Hub.
And damn, someone discovered it before it was announced (wait, that’s illegal):
It is not possible to set what clients can and cannot read as they need to be sent the source code to be able to execute it. As a general rule of thumb, anything client has access to, they have complete control over.
LocalScript source and ModuleScript source is replicated to the client, Script source is not. For modules it doesn’t depend on whether the module is only used by the server, if the client can see the ModuleScript object then they can see the source.
Is ReplicatedScriptService usable currently? The feature is marked as pending, but some people seem to be seeing it.
Given that not all clients would have updated (eg iOS), is it risky to use it?
Essentially this new service is designed to contain things like your modules that are shared between client and server then? Meaning ReplicatedStorage can now be exclusively used as storage, much like ServerScriptService is designed for your code, and ServerStorage is designed exclusively as storage. If so, that’s awesome.
I’ve just made a new module that I plan on using a lot, and this new service is the perfect location to store it.
To follow up on this, there are also guarantees we have introduced with this service. A LocalScript will not run until LocalPlayer
is assigned. You can be confident the Player instance will always exist and be ready to use when your scripts start running.
Clients will be able to read the source of a LocalScript and ModuleScript (in the same way they can now if you put a module in ReplicatedStorage). However, the source of a Script is off-limits to the client as it is not replicated. We are considering solutions for ModuleScript but do not expect to see this any time soon.
When the feature goes live I will write up a full post going into more detail about how to use the service and some of the useful things you can do with it.
Isn’t the solution to this simply placing server-only ModulesScripts in ServerScriptService? What’s the user case for another solution?
The purpose of ReplicatedScriptService
is to provide a container where both server and client logic can exist. This will make it easy to distribute code as they can now live in the same folder.
A Script
instance does not have it’s source replicated to the client, however a ModuleScript
instance does. Since developers are likely to write server-only modules we are looking at providing a way to do this while still allowing them to live in the same container.
Is there any technical difference between this and ReplicatedStorage or are they identical containers? There’s already so many containers in the DataModel
Does this mean that ModuleScripts inside Scripts in this new service won’t be available to the client?
It looks like they would be available.
This service seems to be a combination of StarterPlayerScripts and ServerScriptService combined into a new service
This would be a good solution to the issue, as many developers (myself included) have all of their server modules within a Script
.
ReplicatedScriptService is the counterpart to ServerScriptService while ReplicatedStorage is the counterpart to ServerStorage. Fundamentally each is the same as its counterpart with the addition that the replicated variants are replicated to clients.
I see… so does this mean StarterPlayerScripts is no longer needed and could be deprecated? Is there any difference in behavior between the two from a client perspective?
StarterPlayerScripts does not exist on the server, and cannot be used from the server at all, so if ReplicatedScriptService does actually replicate I’d kinda think that StarterPlayerScripts would be deprecated since it’s the same, just with better functionality.
gametest1 and gametest2 builds can be downloaded with Roblox Studio Mod Manager and it also allows you to edit FFlags locally, so people already do this all the time intentionally haha… It’s fun hunting out new features, finding their associated FFlags and seeing how exactly they work so that you have an understanding when they are ready for release.
Also, wondering what SmoothAngle is … Sounds very interesting.
Yes! Finally I can stop putting local scripts into starter gui (or player scripts)!
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.