Destroy() Can Now Replicate to Clients

Updates Announcements
#24

I love this change a lot! Also could you guys add a property that indicates if is destroyed or not?

Instance.Destroyed --> Boolean (Readonly)

Instance:Destroy() --> Sets the property Instance.Destroyed to true.
9 Likes
#25

The only detail I am missing that could be useful is a IsDestroyed() function to check if an Instance has been destroyed or not.

3 Likes
#26

I agree, but this would be a good temporary solution since it won’t interact with existing projects.

2 Likes
#27

The documentation for Workspace.FallenPartsDestroyHeight may need to be updated then, as it suggests that parts are removed with Instance:Destroy() when they hit the height.

Regardless, if there are still possible ways that parts can be “destroyed” without being :Destroy()'d, it somewhat negates this whole feature change as we will still need to put in the extra steps to account for such cases and cleanup accordingly. Is there any way the behavior could be changed so that .Destroying does fire when the authoritative peer determines it did indeed fall out of the world?

9 Likes
#28

I didn’t actually see anything in the post saying whether this was live in games or only available in studio testing when enabled or not, I only saw coming soon, is this the case? (ReplicateInstanceDestroySetting)

2 Likes
#29

The reason why I would like a function to check if it has been destroyed is that we had an issue in a semi-popular shooter game where we used an object pool to reuse instances that had some issues with destroyed objects.

This object pool occasionally returned destroyed instances, even though we could not see any reason for why it would. It ended up with us doing a duct tape check with attempting to set Parent wrapped in a pcall to detect if the Instance had been destroyed, with a proper IsDestroyed() check it would have become a much more clean solution.

Edit: The event should probably mitigate situations like we had, but hard to predict beforehand in which cases an “IsDestroyed()” check could be useful. Especially with deferred events.

1 Like
#31

My question is not where it’s located, but if it’s enabled in-game when the setting is on, or whether it’s only for testing in studio at the moment.

1 Like
#32
  • Will still show up in CollectionService:GetTagged?
2 Likes
#33

Whether this change is on or not is decided by the property ReplicateInstanceDestroySetting of Workspace. If you set this to Enabled, then Destroy() will be replicated in live games.

3 Likes
#34

No, CollectionService only tracks stuff that’s in the DataModel.

4 Likes
#35

Sound’s good! Should’ve been default to begin with. I’m going to test on all my games

2 Likes
#36

It appears that the Default behavior is currently Enabled. This change broke our game in new servers. I had to go in just now and change it to Disabled in order to restore the game’s functionality.

3 Likes
#37

Yes, we are so sorry for this problem. This has been fixed very recently, you should no longer see Default behavior as currently Enabled.

3 Likes
#38

I love this change a lot! Also could you guys add a property that indicates if is destroyed or not?

@SamSwifthoof

The only detail I am missing that could be useful is a IsDestroyed() function to check if an Instance has been destroyed or not.

A solution for this can be to just check if the instance has a parent, i.e:

if not Instance.Parent then
    -- im ded
end
1 Like
#39

Yes finally! good update for me!

1 Like
#40

This could be problematic for my custom replication, please give advice:

My problem is that I need to be able to take a model from the server, replicate it to a specific client, and then clean up that model from only the server (essentially “downloading” the model from the server to a client, making that model entirely local to that client and nowhere else including the server).

The way I currently approach this is extremely hacky, but what I do is the following:

  1. Parent model to client’s PlayerGui (or Backpack or any of the other client folders) - Now the model is visible to both the server and said client.
  2. Fire a remote to said client with reference to said object, so client knows it exists (remote doesn’t get received until other replication jobs are complete, in this case being the replication of the object).
  3. On the client, reparent the model to wherever it needs to go (for my case I put it in nil until I need it, just holding onto it with a variable).
  4. Fire a remote back to the server telling it that the client has received the model, triggering the server deleting the object. (Using Destroy, which in the old behavior would only destroy on the server, and the client would hold reference to the object so wouldnt be cleaned up on the client too).

Now, would it be possible for me to simply set the parent of the model to nil on the server and remove references to said model from the server to clean it from server memory without interfering with the client? I assume this would work, but I have not tested it. I currently use Destroy(), and with this new change my replication will break.

2 Likes
#41

If you’ve moved the object around to a different place on the client. I believe any calls for the server to Destroy said object doesn’t exist in the client’s exact Data-model location anymore.

Have you attempted to toggle the feature from workspace properties?

1 Like
#42

I think you have a couple of options here that I can immediately come up with:

  1. Destroy()-ing an Instance will not replicate if the Instance is not a descendant of a replicated service. So, you could do something like reparenting the Instance to nil or ServerStorage before calling Destroy() to prevent the Destroy() from being replicated.
  2. On the Client-side, instead of using the model that the Server sent, you could clone the model that the Server sent, and use the Clone. This way, even when the Server calls Destroy() on the original, the clone the Client is using won’t be impacted.
7 Likes
#43

Oh, those are both very good solutions. So if I move a model to a non-replicated container, it is “detached” from the client copy in a sense?

I appreciate the help!

1 Like
#44

Finally! I’m glad this is finally almost out. I remember seeing the .Destroying event in the v500 changelog and I’m glad it’s finally almost here.

4 Likes