Fallen Parts Destroy Height Does Not Trigger Destroying Event

[nin900500 (nin)]

Reproduction Steps

Create a Destroying event for a part.

Let it drop off the baseplate.

fallen parts bug repro.rbxl (27.1 KB)
Expected Behavior

I expect the Destroying event to fire.

Actual Behavior

The event does not get triggered. I assume the Destroy() call should have been called internally?

Issue Area: Engine
Issue Type: Other
Impact: High
Frequency: Constantly
Date First Experienced: 2022-06-15 00:06:00 (-07:00)
Date Last Experienced: 2022-06-15 00:06:00 (-07:00)

[Qualadore]

This really shouldn’t be changed, documentation should be updated. I don’t want every single line of code I reparent part of a model to potentially error because it has been destroyed. This would be a major breaking change.

[Qualadore]

Destroy() Can Now Replicate to Clients

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.

`Workspace.FallenPartsDestroyHeight` does not destroy models as expected

Alright, I’ve checked with the team and this is expected behavior (and is a special-case for when there is a Humanoid under the model). If that were a regular humanoid and had a body, the state would be set to Dead, at which point you could run a script to clean up the rest of the character. I’ll make sure the API reference page is updated.

[asdfiji123]

Like @Qualadore said, this is indeed a documentation issue - we don’t want fallen parts to call Destroy(). We have already filed a request internally, but it looks like we haven’t gotten around to fixing this yet. I’ll follow up again with our Documentation team and see if we can get this fixed soon!

[nin900500 (nin)]

So what am I suppose to use if an Instance is destroyed regardless of whether by :Destroy() or not? AncestryChanged?

[asdfiji123]

AncestryChanged would work. You could also use GetPropertyChangedSignal("Parent").

I think what actually happens is that Instance.Parent gets set to nil, so you want your script to listen for that instead of the Destroying event.

Sorry for the inconvenience

[unmiss (Jack)]

I’m unclear on why it’s called FallenPartsDestroyHeight then.

[illuzive]

This still needs to be fixed, the issue is fallen parts are just re-parented or something, but don’t get the ‘Destroy’ method called on them.

This has nothing to do with the ‘Destroying’ event being called for instances just being reparented which is what was mentioned above. The behaviour of fallen parts is what needs to be changed.

Please change, current behaviour is unexpected and causing bugs, and is hacky to replace with just checking for Parent = nil.

(Bonus bug: if you keep a reference to the fallen instance and destroy it again after, it fires Destroying twice simultaneously)

[wittytoad]

Just to close out this thread, the description for FallenPartsDestroyHeight was corrected earlier this year. It no longer states that parts are ‘destroyed’. Thanks for reporting this!