Upcoming Changes to Destroy()

Hi developers,

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.

We plan to remove the setting ReplicateInstanceDestroySetting under Workspace, and enable Destroy() replication for all Roblox experiences to make memory clean-up easier for all developers. Please reference our previous announcement for more information around this removal.

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.


Thank you


[Update] September 7, 2022

200 Likes

This topic was automatically opened after 10 minutes.

alright so this basically just gives us a little more options on what to do before something is destroyed fully
pretty neat feature ngl, thanks broski

it’ll be useful for a range of things :+1:

17 Likes

finally body velocity dash issues on laggy players are gone thank you roblox team!!!

9 Likes

Who actually relied on the old behaviour intentionally?

15 Likes

I don’t even know what that was

6 Likes

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.

9 Likes

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!

35 Likes

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.

6 Likes

I agree with @FLEXTARO. Destroying anything on the client should not replicate to the server

13 Likes

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.

3 Likes

For the values, you can use attributes. If you set them on the server, exploiters can’t do anything about it.

5 Likes

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.


:red_circle: 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().


:green_circle: 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…


:yellow_circle: 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.

The method I am requesting is:

local Object = Instance.new("Part")
print(Object:IsDestroyed()) --> false
Object:Destroy()
print(Object:IsDestroyed()) --> true
12 Likes

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

Thank you very much.

3 Likes

What would be the difference then just doing :FindFirstChild? Not sure I really understand this.

I believe that exploiters can only delete stuff that they are locally controlling.

Re-read this.

2 Likes

I’ve also encountered many artifacts from pre-filtering behavior that’s really annoying/impossible to counter with.

  • Descendants of Players replicate deletion if Player.Character is set to nil.
  • Welds (Likes ones created automatically with Seats and Tools) replicate their C0 and C1 properties on creation.

Player’s also do not get properly destroyed on leave which is extremely bizarre and basically means every game using .PlayerAdded is leaking memory.

2 Likes

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
4 Likes

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.

1 Like

Yeah, so many issues that just seem solvable?