Modified Parameters/Attributes of an Instance are not guaranteed to be replicated before the object is destroyed for the Client.
This means if I attach an attribute an object, then delete it to soon, the Client will not be able to read this attribute at all.
However, it seems like adding child objects to the Instance being destroyed will still get replicated before it’s destroyed.
Here’s a small repro I made in an empty baseplate showcasing the issue.
In general the property being updated on a deleting instance is not supported. The Roblox engine is designed such that we move towards a concept of “Eventual Consistency”, meaning the latest state of the world is prioritized.
This means if you create an object, change some properties, and then delete the object, the final property changes are not guaranteed to arrive. The engine assumes that the deletion of the object makes those final changes irrelevant.
Is there a specific use-case you were relying on this for?
All good,
The usecase is a bit messy to write out all at once. I’m trying to spawn client ragdolls when server animals are destroyed in my game.
server destroys animal, client sees instance destroyed, spawns a ragdoll where the instance just was, reads some metadata about the animal to know how to setup the ragdoll.
However, this metadata needs to arrive at the same time as the object is being destroyed. This is tough because it’s generated on the same frame as it’s being destroyed, so I need a way to guarantee both the instance being destroyed and the metadata are given to the client at the same time.
Does a RemoteEvent sufficiently resolve your use case for this as a workaround?
I can see how replicating “final state before Destroy” can be helpful in some cases, my concern is that in most scenarios this behavior would cause a loss of bandwidth without much utility. Want to understand whether there is something else we could provide or whether RemoteEvents work well in this scenario.
You’re correct, that’s a fine workaround. I just thought the lack of replication before being destroyed was an unintentional bug. But now that I’m aware this is done for optimizing bandwidth, I can use other methods to accomplish my goals, like using a simple remote event call. Thanks for the clarification on this topic.
