Upcoming Change: InsertService will no longer auto-replicate instances to all clients

Hello Developers,

Within the coming weeks we will be changing the behavior of InsertService to stop it from automatically parenting assets to itself. This change is a follow-up on the removal of InsertService.AllowClientInsertModels to provide speed and security improvements when using InsertService.

A frequent case where developers may rely on this behavior would be as follows:

local model = InsertService:LoadAsset(12345)
game.ReplicatedStorage.HandyRemoteEvent:FireClient(game.Players.Alice, model)

Prior to this change, Alice would receive a RemoteEvent with model. When this change is implemented, Alice will instead receive “nil”. The code can be modified to parent model elsewhere prior to firing the RemoteEvent, like so:

local model = InsertService:LoadAsset(12345)
model.Parent = game.ReplicatedStorage
game.ReplicatedStorage.HandyRemoteEvent:FireClient(game.Players.Alice, model)

The above code will once again allow Alice to receive the RemoteEvent with model.

The behavior change is expected to go live during the week of October 16th. Any questions, comments, or concerns may be addressed to @LordRugdumph.

We highly encourage our developers to discuss how this change will impact your Roblox game(s). Feedback is always appreciated by our team! :slight_smile:

Thanks,
Developer Relations Team

41 Likes

This is actually a pretty useful change for those of you who are unaware of the nuances of InsertService. One of the larger problems with it was that all inserted assets uncontrollably replicated to every client. If you inserted something to be parented to ServerStorage, it would be replicated to clients anyway when it was inserted. If you inserted something to be previewed only by a select few/one client, it would be replicated to all clients anyway.

This had major performance and security rammifications. Not only would someone previewing an inserted item have to download an asset, but the entire server would have to expend network bandwidth and memory to download the asset. Malicious users could also sit in your game and wait for private assets to be inserted to steal them, even though they were intended to be serverside only. Now you can safely have local previews (e.g. for a shop that inserts synced assets across a universe) without performance costs for the entire server, and not have to worry about serverside assets being stolen.

17 Likes

Been waiting for this for quite a while. Hopefully this will improve the performance for a few games and minimize, well, security breaches.

:+1:

This is brilliant. Now I can load in all of my scripts and assets securely.

2 Likes

This is great news! But will inserted models still be permanently stored on the server after they’re inserted causing increased load times for joining clients?

For example:

  • You insert a preview model and parent it to a player’s playergui
  • The player changes preview model, so you delete the model from the player’s playergui
  • Now a new player joins, and it previews the same model as the first player. Has the model already been loaded on this client because it has been inserted by another player before, or is it inserted again (which i want), so players who may not preview that model any time during their session won’t have to load it when they enter the game?

They will not be permanently stored unless you explicitly do so. If you parent a model directly to the PlayerGui, it will not replicate to other clients – only that one client and the server (since the server created it), and when the client leaves and the PlayerGui is destroyed, it will be garbage collected on the server as well.

Is this the case currently? Because then my problem is probably related to replicating mesh/union physics data and not InsertService (Which i guess is being permanently stored on the game since load time increases with the more unique mesh and union assets i insert, and persists after inserted items are destroyed).

No, currently inserting via InsertService automatically replicates to everyone in the server, but only those in the server and not anyone who joins after if you parent it somewhere else. Longer join times would be the fault of either something else or cloning instead of changing the parent.

1 Like

This will be very helpful with transferring my main modular that runs my entire Disneyland UI system!

TL;DR: there will still be some overhead for MeshPart and CSG, we have some ideas for fixing this but we haven’t scheduled time to work on it yet.

There is a separate issue we need to tackle in the future for MeshParts and CSG. For a few reasons, we currently keep a “Dictionary” of physical geometry for MeshParts and CSG. This dictionary is unique per “shape” (e.g. if you have one MeshPart duplicated 100 times, you will only have one dictionary entry that all 100 share). However, in running servers we currently do not clear items out of this dictionary (so if you delete all 100 of the MeshPart, you will still have the dictionary entry for it). Also this dictionary is not aware of PlayerGui, if you use PlayerGui to replicate a MeshPart we still send the dictionary item to all clients. We have some plans for addressing this but we don’t have an ETA when it will be implemented.

8 Likes

Bumping thread: this has been enabled today

5 Likes

Wait, who is Alice :face_with_raised_eyebrow: ???

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.