A month ago, RejectCharacterDeletions was forced to every roblox experience, to “patch” exploits regarding to removing welds from the client for them not to replicate animations.
This did not patch hats, which meant you could still mess with them from the client, and funny enough, even exploiters decided to make their own limbs to reanimate again:
I’m not going to explain how it works (If you have basic lua knowledge you might understand now), as it would probably get this thread deleted, but here’s my script to patch it.
-- Important
RespawnAntiDeath = true -- Respawns exploiters with antirespawn
--- Punishments
ResetVelocity = true -- Resets it to default and makes the hats fall
Kick = false -- ONLY USE IF YOU ARE SURE YOUR SCRIPTS DONT MESS WITH VELOCITY
game:GetService("Players").PlayerAdded:Connect(function(Player)
Player.CharacteracterAdded:Connect(function(Character)
while Character do
task.wait()
if Character.Humanoid:GetState() == Enum.HumanoidStateType.Dead and RespawnAntiDeath == true then
task.wait(game:GetService("Players").RespawnTime)
Player:LoadCharacteracter()
end
for i,v in pairs(Character:GetChildren()) do
if v:IsA("Accessory") and v:FindFirstChild("Handle") and v.Handle.Velocity.Y ~= 0 then
if ResetVelocity == true then
v.Handle.AssemblyLinearVelocity = Vector3.new(0,0,0)
v.Handle.AssemblyAngularVelocity = Vector3.new(0,0,0)
elseif Kick == true and Character.Humanoid:GetState() == Enum.HumanoidStateType.None then
Player:Kick("Yo..")
v.Handle.AssemblyLinearVelocity = Vector3.new(0,0,0)
v.Handle.AssemblyAngularVelocity = Vector3.new(0,0,0)
--print(Character.Humanoid:GetState())
end
end
end
end
end)
end)
I don’t recommend using kick, unless you are 100% sure your game doesn’t mess with velocity in any way, now what resetting the velocity do? Exploiters wont have network ownership to their hats, and oof! They fall into the void.
Why would it? RejectCharacterDeletions is meant to patch a legacy behaviour prior to the introduction of a proper client-server model where a client can delete instances in their character and the change would authoritatively propagate to the server. It’s unrelated to physics exploits.
Resetting velocity doesn’t change the network ownership of accessories. A character is network owned by the player it belongs to and that includes the customisation assets its given on construction. Resetting velocity is just resetting velocity, it has no implications on network ownership.
RejectCharacterDeletions does not patch the client-server when the character is dead, exploiters can delete their bodyparts on death, which is the current method exploiters use to “reanimate”.
Resetting velocity doesn’t change the network ownership of accessories. A character is network owned by the player it belongs to.
I mentioned this as you actually have to delete the welds off, and since the character is dead it will be replicated and you can mess with the accessories. The player with the most simulationradius would have networkownership of the hats and could do anything they want with it as it is unanchored. Exploiters usually set the velocity to a value higher than (0,20,0) to keep them intact.
Are you saying this because you’ve tested it or because you’ve seen it? I’m checking here in Studio and a quick repro doesn’t really match up to what you’re saying. If it’s the latter, then how can you be so sure that the experience in question hasn’t opted out of RejectCharacterDeletions?
-- Executed on client
workspace.colbert2677.Humanoid.Died:Connect(function () workspace.colbert2677.Head:Destroy() end)
-- Executed on server
workspace.colbert2677.Humanoid.Health = 0
-- Head does not disappear on the server view, ergo not replicating
If a character is dead and the physics of its parts are replicating, then as mentioned regarding the “seeing rather than testing”, how can you be so sure that the developer doesn’t restore the legacy behaviour of giving the client network ownership of their character on death? Currently, part of the automatic network ownership contract is that the server is given ownership of characters on death.
I’m interested in seeing a repro made by you showing the behaviours this code is supposedly trying to fix. As far as I’m aware, this fix is being provided on non-empirical grounds. Experiences that are still liable to this exploit either have different setup and requirements that incidentally enable this behaviour again, or I might be wrong as are my tests, but that doesn’t seem to be the case right now?
It doesn’t directly work like this, I can PM you the script if you need it as I’m not going to explain more here I’m not trying to get banned for explaining how an exploit works.
That’s fine if you want to, but you aren’t going to get banned by explaining how an exploit works at a high-level, that’s not how we do things here. On the other hand, you would be banned for encouraging or otherwise distributing exploits on the forum explicitly.
There are many threads here on the forum regarding exploit countermeasures that also need to do their due dilligence in explaining how something is a problem to present a solution - in this case, there is no such explanation for that problem.
I would also suggest writing a bug report (with a private message, if applicable) on this topic so it be triaged for engineers to review. It would help if you would be able to contribute to having a native fix in the engine as well rather than a code sample that may not be applicable to most experiences.
