Release Notes for 430

Notes for Release 430


Client Difference Log

API Changes

Added Class ReplicatedScriptService : Instance [NotCreatable] [Service]

Added Property float PartOperation.SmoothingAngle {✏️PluginSecurity}

Added Function void WorldRoot:SetInsertPoint(Vector3 point, bool ignoreGrid = false) {RobloxScriptSecurity}

Removed Property DebugSettings.IsFmodProfilingEnabled

(Click here for a syntax highlighted version!)


This sounds cool. Would it allow the client to modify the server in a limited way? Or handle player input on the server?


I just want this:

to change to this:

as soon as possible!

I literally cannot wait until this gets released. It’s going to be great!


TL;DR: It’s a simple location where both LocalScripts and Scripts will run.

So you can distribute a single model that has both Local and Server logic without expecting people to move some part of it over to a location that does run LocalScripts, or copying over a LocalScript dynamically on character load. It also will serve as the simplest place to put LocalScripts which have a static lifetime.

What those LocalScripts and Scripts can touch is the same as any other Script or LocalScript, there’s no special magic rules for the new service.


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?

1 Like

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):

1 Like

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.

1 Like

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?

1 Like

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 :confused:

1 Like

Does this mean that ModuleScripts inside Scripts in this new service won’t be available to the client?

1 Like

It looks like they would be available.

This service seems to be a combination of StarterPlayerScripts and ServerScriptService combined into a new service

1 Like

This would be a good solution to the issue, as many developers (myself included) have all of their server modules within a Script.

1 Like

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.