Will inserted objects (hopefully) stop being immediately replicated to clients by either of the following?
- Not parenting inserted instances to InsertService on insert
or
- Making InsertService a non-replicating container?
6 Likes
@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.
15 Likes
I knew about this but never used it because I knew that it would allow exploits to have some more things they can use.
1 Like
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.
2 Likes
Also on a partially related note, will LoadStringEnabled ever meet this fate?
1 Like
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.
If you’re in FilteringEnabled, the PlayerGui doesn’t replicate.
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
No, it does. The instance replicates, but clientaide changes don’t as expected.
1 Like
What kind of latency reduction should we expect? Are we talking, like, entirely trivial or actually barely noticable?
@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.
1 Like
@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.
1 Like
@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.
1 Like
Couldn’t they just stream it as a binary RBXM file that the client could then reassemble for local usage, or would that take up too much bandwidth?
@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.
2 Likes
Also, this RemoteEvent/RemoteFunction should not take an arbitrary asset id.
2 Likes
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.
Is there a reason it needs to take AssetIds? On the server you can insert it through InsertService and then replicate the instances over Remote objects. I’m not a fan of asset IDs, because either way it’s ugly:
- Inserting assetIds from client -> server is essentially inserting models clientside which we just dropped support for
- Inserting assetIds from server -> client is the exact same as inserting through InsertService and replicating the instances manually, except there’s ambiguity to whether the server is doing this or sending the client an AssetId which it will insert itself
Not sure if this is what you meant by your comment, but I use a script to Parent UIs into PlayerGui and it shows up on that players screen. So you should be able to send other objects that way as well.
Bumping topic, we will be putting this change into effect this week.
1 Like