Roblox is currently planning to remove support for the “AllowClientInsertModels” checkbox for insert service in studio. Once support for this property is removed, client-side scripts will no longer be able to use InsertService directly, instead developers can use RemoteEvents to accomplish the same functionality moving forward. For more information, please read the following thread on the Developer Forum [Coming Changes to Insert Service].
This change will help us continue to improve the security of your assets while also providing a latency reduction within your Roblox games. We expect these changes to go live approximately 3 weeks from the time of this announcement. We advise all developers using this current method to update their Roblox games before the change is implemented.
If you have any questions or concerns please feel free to tag @LordRugdumph in this thread.
@ClutchDeveloper glad to hear you don’t use this, originally we always allowed clients to insert things, then we migrated to by default not allowing clients to insert things but left this checkbox as a loophole, this update is just closing that loophole.
@EchoReaper Yes the main purpose of getting rid of this checkbox is to eventually remove the mandatory replication of all models inserted with insert service, that change will be a later follow-up.
Can we have a reliable way of replicating instances through Remote objects? Last time I checked, it doesn’t work reliably because instances are passed by reference, and unless the object was replicated out in a visible scope to all clients, the object reference becomes null when it crosses the server/client boundary.
You can parent to PlayerGui from the server (instance is visible to the server, but changes made clientside e.g. cloning of StarterGui don’t replicate back) and it will only replicate to that client, but this is pretty much a hack and should only be used until we have a better solution. It would be nice to have a more officially-supported way of doing this.
So the client won’t be able to insert anything outside the game? But will it be able to clone and parent stuff that is already in the game? @LordRugdumph
@TjazBuilder This change only affects functions on InsertService. All of the functions on InsertService that would load a model/asset will not work at all when run from a client (regardless of weather the model is currently in the game or not), but server scripts will still be able to do everything they do today. If a local script needs to insert something you can set up a RemoteEvent or RemoteFunction to assist. Cloning and parenting logic is not changed at all with this change.
@Maximum_ADHD
Replicating instances in Remote objects that have not already been replicated via another means: this is not currently on the roadmap, but I will pass this idea on to networking team. It would involve a non-trivial change in our replication layer so I can’t promise it.
LoadStringEnabled: we do not have work scheduled at the moment to remove this.
@Visleaf the latency reduction will only affect games that use InsertService, and the amount will depend on how much the game uses insert service & how complicated the inserted models are.
@Maximum_ADHD correct that is roughly what is needed; instead of rbxm format we would use the network format we use for sending all instances that are created remotely, but same idea.
However, implementing this in the context of the rest of the existing networking code is not currently trivial (it is doable, but it is not so simple that we can just work it out in a single afternoon per se). So to be conservative I don’t want to promise it on this (tangentially related) thread.
Unless it’s whitelisted by your server scripts as being something valid for the client to request. Say, for instance, a hat model so that you can display it in a 3D GUI.