I have good news for you, it already does :Destroy()! In fact, it’s one of the ones that didn’t in the past but was upgraded to do so (relatively recent change, I think it was changed to destroy a couple years ago)
18 Likes
You know what would be even better? If Destroy replicated to the server. Not in a way where the client can destroy instances on the server, but rather send a signal telling the server to stop replicating data to that client.
3 Likes
I think that behavior should be kept away from the Destroy() function and added to some future feature where you have more fine grained control of the replication behavior of stuff.
4 Likes
Edit: Never mind, I just saw the answer when rereading the original post. It fires on both client and server.
Will this fire on the server also?
1 Like
Know what would be even better? Stop allowing clients to remove ANY instance from their character model, even scripts, values and their own humanoid -_-
11 Likes
There’s a good reason for this: Roblox uses distributed physics. That means that in some rare edge cases one physics simulating peer may decide that something fell off of the map, while the actually authoritative peer does not agree, so it has to be possible to “undo” the thing falling off the map.
5 Likes
Great to hear! I heavily rely on Debris, so it using the new behavior is almost a must for me.
1 Like
Since when is the server authoritative at all when it comes to physics? Roblox doesn’t seem to do any sort of latency correction, prediction, anticheat etc. just interpolation.
1 Like
I adjusted the wording, really the new authoritative peer. Basically the problem scenario may occur during physics handoff when the server is adjusting which client should be handling the simulation for the falling object.
3 Likes
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.
8 Likes
The only detail I am missing that could be useful is a IsDestroyed() function to check if an Instance has been destroyed or not.
2 Likes
I agree, but this would be a good temporary solution since it won’t interact with existing projects.
1 Like
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?
8 Likes
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)
1 Like
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
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
- Will still show up in CollectionService:GetTagged?
2 Likes
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
No, CollectionService only tracks stuff that’s in the DataModel.
4 Likes
Sound’s good! Should’ve been default to begin with. I’m going to test on all my games
2 Likes