This is a reminder for the upcoming removal of the ReplicateInstanceDestroySetting on September 15, 2022. You may disregard this post if you have already set ReplicateInstanceDestroySetting to Enabled or Default.
Over the past couple of months, we have been working to make it so that calls to :Destroy() on the server will replicate to clients. So far, we’ve seen massive adoption of the feature to replicate Instance:Destroy(), and are preparing to complete the roll out.
We intend to remove ReplicateInstanceDestroySetting on September 15, 2022. Please reply and let us know if you need more time to enable Instance:Destroy() replication.
Basically, before Instance.Destroyed was a thing, if you destroyed an instance on the server that was also on the client, parent lock didn’t replicate to client, which means client was able to reparent the “destroyed” instance to another distance.
To fix this, Roblox added Instance.Destroyed alongside with ReplicateInstanceDestroySetting under workspace to give developers time to fix any effected code by this change. They are now planning to remove this setting on September 15th and use the new behaviour for every game.
Since it’s a talk about :Destroy() and Replication are you guys planning to do anything about the player being able to delete absolutely anything from their own character(such as values, folders, etc) and when the character is nil they can delete stuff from their player instance(these are in exploiter cases of course) or do you guys not deem this important and will continue to ignore it? Sometimes it’s annoying having to put instances in the Player/Exclusive Replicated Storage Folder when certain PVP code requires the instance in both the attacker and the victim to work properly and an exploiter then being able to delete it from their own character and bug both players, gets tiring checking if the target is a dummy then if it isn’t, get both players, find the instance in them, reference it, otherwise if its a dummy, find the instance in it, reference it, etc you get the point, just adds unncessary checks that could be prevented if I could simply use instances in the character without the possibility of them being deleted by an exploiter WITH REPLICATION(which is just by itself absurd) causing server-sided problems. So many things in my current code could be abbreviated with the removal of this possibility so I would love to hear if you guys have any plans on it or atleast that you don’t so I could stop hoping, don’t wanna finish my entire framework by using the Player/ReplicatedStorage method then have to switch later to make future work easier.
Thanks!
I thought you were bluffing but it seems you actually can (to a limited extent) delete instances in the character model on the client. That’s interesting. Even still, you may want to write your code more defensively to avoid such scenarios causing errors.
Yeah I absolutely do but its just aggrevating as in that I’m forced to do it even though the “feature”/“possibility” has no benefits, not security/performance/lag reduction nor anything else, quite the complete opposite, that is the only reason I want this change, no benefits just adds additional code for no reason.
First of all, I wanted to say that I am happy with this change as I probably had many leaks before this was put in place.
Now, I wanted to ask a quick question. Is it so hard for you guys to add a IsDestroyed() function for each instance that returns a boolean value indicating if the Instance has been destroyed or even a property called Destroyed for us to check if the Instance has been destroyed?
I am honestly tired of checking if is parented to nil or even if is a descendant of the DataModel when is not accurate at all.
I won’t be doing a feature request because as I have said in some previous posts, is something that is very important to have and should have come already with the addition of the Destroying event and the changes made to the replication of Destroy().
How can it be used?
It will be useful whenever you need to do a task while an Instance is not destroyed.
It can also be used so when you pass an Instance to the function, and this one requires Instances that are not destroyed to be passed to it.
When you are iterating through a table of Instances on the client that the server can destroy at any moment, it will be good to have this as a feature as I can check if they are destroyed before doing something on them.
Between others…
To answer back to all those people that have replied to me with non-sense code (that doesn’t do at all what I am requesting), here it goes:
local Object = Instance.new("Part")
--> First Method:
if Object.Parent == nil then --> This is not an accurate method of knowing if an Instance is destroyed.
print("Is destroyed!")
end
--> Second Method:
if Object:IsDescendantOf(game) == false then --> This is not an accurate method of knowing if an Instance is destroyed.
print("Is destroyed!")
end
--> Third Method:
if Object:FindFirstChild("Object") == nil then --> This is not an accurate method of knowing if an Instance is destroyed cuz is literally doing nothing related to it, is just checking if an Instance with name 'Object' exists.
print("Is destroyed!")
end
--> Fourth Method:
if Object then --> This is not an accurate method of knowing if an Instance is destroyed and it will literally be true all the time.
print("Is destroyed!")
end
All of the above will literally print “Is destroyed!” when in reality is not.
I was looking into it and you’re right suprisingly I haven’t thought of this before
local bonusDamage = character:GetAttribute"BonusDamage"
local damageReduction = target:GetAttribute"damageReduction"
--as opposed to(with the character deletion replication change)
local bonusDamage = character.BonusDamage.Value
local damageReduction = target.damageReduction.Value
You cannot compare FindFirstChild to what I am requesting honestly.
if CurrentInstance:IsDestroyed() then
print("Is destroyed!")
end
if CurrentInstance:FindFirstChild("Object") then
print("This is not useful to know if the 'CurrentInstance' is destroyed.")
end
What does that have to do with my point? Why are exploiters able to delibaretly delete ValueObjects, Folders, Configurations…etc created by the server from their characters with replication, does this not sound absurd to you? I understand this change, it is nice but it has nothing to do with my point. Now destroy will replicate from server to client my question is why does destroy replicate from client to server in a case where the object was created by the server.
Now, I wanted to ask a quick question. Is it so hard for you guys to add a IsDestroyed() function for each instance that returns a boolean value indicating if the Instance has been destroyed or even a property called Destroyed for us to check if the Instance has been destroyed?
How can it be used?
To answer back to all those people that have replied to me with non-sense code (that doesn’t do at all what I am requesting), here it goes: