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.
I agree with @Serrattor. Destroying anything on the client should not replicate to the server
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.
For the values, you can use attributes. If you set them on the server, exploiters can’t do anything about it.
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.
The method I am requesting is:
local Object = Instance.new("Part")
print(Object:IsDestroyed()) --> false
Object:Destroy()
print(Object:IsDestroyed()) --> true
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.
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.
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.
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.
Yeah, so many issues that just seem solvable?
They can’t. Did you read my post or OP? They said things deleted on the server are deleted on the client.
Mm that is the same thing? I don’t understand what does that have to do with destroy replication from client to server not server to client
The replication to Destroy is one way I believe. Server to client only, and not the other way around. If an exploiter deletes something on the client, nothing will happen to the server. I believe you are confused.
If anyone can prove this, I’d be happy.
I’m not sure you get me brother, create a value in your character on characteradded then go into playtest, delete it manually from the explorer on the client side then switch over to server side and it will replicate that is the problem you can test it yourself, as Max said above he tested it too.
@Serrattor is saying that when you destroy an object under the character using a LocalScript (from the client in other words), it replicates to the server.
How the server sees it before the client destroys it:
After the client delete those objects this is what the server sees:
This is indeed an issue, if it were to be parts ok then, but anything else like deleting ValueBases, BindableEvents, among others, even Scripts is just too much.
I have just realised it works with bindableevents/functions too and I’m using like 3 of them in the character why is this a thingggg.
(I can’t use defensive mechanisms here either since some of my code looks like this)
plr.Character.Actions:Fire("AddStun",{
--stats n stuff
})
target.Actions:Fire("AddStun",{
--stats n stuff
})
used hundreds of times too, if for example the target deletes their actions event then the code errors and the character never gets unstunned, before assumptive workarounds I do have a duration setting with a task.delay set up on the bindable but for some cases I’m setting duration to math.huge which doesn’t trigger the task.delay so I can manually unstun the player after a randomized time in some cases.
This is literally a huge security issue at this point and I have to get to migrating to the player instance again, honestly…