Currently, as of 11/7/22, the Workspace.FallenPartsDestroyHeight property does not work for locally created parts. Instead, these parts get frozen at Y -500, even if Workspace.FallenPartsDestroyHeight is higher than -500.
Steps to reproduce:
Open the attached repro file
Run a playsolo session
Observe the balls spawning. Kick them into the void.
Observe that the fallen balls are frozen at Y -500, and are not being Destroy()ed.
It is expected that Workspace.FallenPartsDestroyHeight would Destroy()any baseparts and models that pass its Y value, regardless of if they exist on the server or the client.
Actual Behavior
Workspace.FallenPartsDestroyHeight does not work at all for client parts.
Workaround
None
Issue Area: Engine Issue Type: Other Impact: High Frequency: Constantly Date First Experienced: 2022-11-07 00:11:00 (-05:00)
In general, we try to design the Roblox engine so that most changes to the DataModel happen on the server and replicate to clients. Particularly for physics, this is important for preventing desynchronized states, which currently cause a lot of problems.
We could probably redundantly Destroy() parts on the client because if the part is below the Y on the client, it’ll probably be below the Y on the server and get destroyed there too. But, it’s theoretically possible the part dips below the Y for a frame on the client but the server doesn’t see this, then the client deletes a part and we get into a bad physics-desync scenario because the DataModels don’t match.
We could investigate this more, but my instinct is that we should keep the engine behavior simple and only destroy on the server. If you have more context about why you’re making local parts, that could inform the priority of making local parts work better.
It’s been a while since I worked on the feature in my game that required this, so I don’t fully remember the details. If I run into this issue again I’ll be sure to ping you & provide the full context.