How deferred events behave is unrelated to this feature.
2 Likes
This is a really useful change, but how did it take you guys nearly 20 years to catch this? Players/Characters have been an engine feature since around 2004-2005, and the scripting API since 2006, so surely this issue would’ve existed then as well.
1 Like
Why not add a character-removing function on the client of every player instead of using a remote? It seems easier to call a single character:Destroy() on the client when character-removing triggers.
Also, should I call character:Destroy() on the client before or after calling character:Destroy() on the server? Do I need to set character = nil on either the client or server, or is character:Destroy() sufficient?
1 Like
Thanks for this clarification as I was wondering why the instances on the client never detect being destroyed. I also assumed this character destroy behavior would actually call the :Destroy() which replicates to the client, but we love inconsistency so this is not the case.
As I’m using a custom character loading module, these changes is inconvenient to me in so many ways since the character is removed when a player disconnects, thus I can’t notify the clients before character is streamed out. This was possible with SignalBehavior Immediate (but that’s getting straight up removed in the future as well, yay!) because CharacterRemoving actually happened before the character was removed, but now with Deferred it’s basically CharacterRemoved.
I would appreciate if the engine devs actually worked together on these features including SignalBehavior Deferred, especially since they’re pushing these changes on all experiences.
With PlayerCharacterDestroyBehavior Enabled, SignalBehavior Deferred, and the Destroy() replication not applying in this case, it’s really annoying and unintuitive to detect on other clients whether the character was removed from the workspace due to something like StreamingEnabled’s stream out or due to a general disconnection.
Roblox is slowly pushing these features on all experiences and not considering how many hoops you have to jump through for them to work together.
I needed to vent this out here so thanks for reading and sorry.
A bit late but do you still agree with your post?
Hi
I’m working on a ragdoll system that places a ‘body’ at the location the player died.
To achieve this currently, I’m using the character model itself (no clone). I dereference it as the player’s character by setting player.Character = nil.
This works with this feature disabled. However enabling the toggle causes the ragdoll body to be removed at the player.Character = nil.
Should I use a clone instead?
But more importantly: should I bother? I.e. is this behavior going to be forced in the future?
Thanks
We are planning to change the default behavior of this property to ‘Enabled’ soon with a separate announcement on the forum.
You will still have the ability to set it to ‘Disabled’ for a limited (but pretty long) amount of time, so we suggest resolving any issues you might have using cloning if necessary.
2 Likes