`Workspace.FallenPartsDestroyHeight` does not destroy models as expected

Bug Reports Engine Bugs
#1

Reproduction Steps
Currently, as of 1/31/22, the Workspace.FallenPartsDestroyHeight feature does not Destroy() models like it should, as documented in its API documentation. Instead, it simply does not Destroy() the model when the last part is destroyed below the destroy-height.

This issue only seems to occur when a Humanoid is parented to the model. Otherwise, it gets Destroy()ed as expected.

STEPS TO REPRODUCE:
Download & open this place file : FallenPartsDestroyHeight_Repro.rbxl (32.3 KB)

  1. Run a playsolo test. Observe the two unanchored parts near the edge of the baseplate.
  2. Kick both parts into the void. Observe that the Model instance they are parented to is Destroy()ed when the last part is Destroy()ed, as expected.
  3. Stop the playsolo test. Add a Humanoid instance to the model.
  4. Repeat step 2, but observe that the model is not Destroy()ed, even though both parts were kicked into the void.

Expected Behavior
It is expected that a Model will always be Destroy()ed when the last part of it is destroyed by the Workspace.FallenPartsDestroyHeight feature.

Not doing so causes unexpected behaviors in developer’s code, which leads to game-breaking bugs. In my case, it bricked an entire server because my round logic errored with

Model:SetPrimaryPartCFrame() failed because no PrimaryPart has been set or the PrimaryPart no longer exists. Please set Model.PrimaryPart before using this.

when it went to move player’s avatars from the lobby into the map.

Actual Behavior
Workspace.FallenPartsDestroyHeight does not Destroy() a Model when the last part in it falls below it and is Destroy()ed, if there is a Humaonid instance parented to it.

Workaround
Manually doing this behavior myself by listening to part ancestry changes.

Issue Area: Engine
Issue Type: Other
Impact: Moderate
Frequency: Constantly
Date First Experienced: 2022-01-31 00:01:00 (-05:00)

8 Likes
#2

Oh. I think this explains an impossible error I would see rarely in my servers.

2 Likes
#3

Thanks for the report and the detailed repro steps, I’ll take a look.

Edit: I’ve made a ticket and I’m directing it to the appropriate team. I’m not completely sure this is a bug, but I’ll let them decide if this is the correct behavior or not.

4 Likes
#4

If it’s determined to not be a bug, can the documentation be updated to reflect this? The documentation does not mention this at all.

2 Likes
#5

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.

6 Likes
Fallen Parts Destroy Height Does Not Trigger Destroying Event
#6

Is there any particular reason why Humanoids have a unique case for this?

#7

I’m not completely sure, but the intention is probably to allow for state to persist or scripts to run after the body has been destroyed.

1 Like
#8

I’ve tested this with NPCs and the HumanoidState is not setting to Dead for me but instead remains Freefalling. I’ve had to resort to checks on change in origin position or descendants removing (depending on my use-case) to force set the Humanoid.Health of my character models to zero and cause proper eventing of character Death for my game.

This has been a breaking change that doesn’t seem to function as the new proposed documentation is suggesting. Not sure if this a more recent issues since these changes went into effect.

2 Likes
#9

I’m a bit late here, but this was answered in a different thread: Character models fail to be removed after falling below the FallenPartsDestroyHeight in places with a custom StarterCharacter - #4 by V4_Ap3Dud3

1 Like
#10

This topic was automatically closed after 6 days. New replies are no longer allowed.