This is great, solves a plethora of exploiting possibilities! 10/10 great work!
Excuse my ignorance, I didn’t know about this type of exploit.
But I understand that an exploiter can only change his own client, so he could only change his own character, right?
So, what benefit would an exploiter have in changing his own character and this being replicated on the server, since only he will suffer the consequences of this?
For example, the ability to delete items from your character and having it replicate to the server allowed a lot of exploiters to create god mode exploits where they could swap out their characters and humanoids
1 Like
Thank you very much! It will fix A LOT OF godmode exploits, and maybe, every godmode exploit!
osyris da 
im not even sure why this wasnt done before, such a huge vulnerability.
Wow this is great and was long overdue. Glad that this was released as it was a pain to account for client deletion. I’m wondering if theres a reason this feature was kept exactly (perhaps something related to humanoid dying, and if so why did it apply to every type of an instance).
However this legacy Filtering Disabled compatibility loophole should be fixed as well: Client can change Tool.Grip on Server
Also the fact that the client can entirely halt the behavior of Players.RespawnTime should be fixed as well (because it allows a quasi god-mode).
This probably exists to prevent desyncing of the client (and thats fine), but it should be nerfed so that if the client is normally sending data then it shouldn’t be able to throttle respawning.
The fix for this should be that if the clien’t is sending network data normally but not just respawning then the server should just enforce the respawning by respawning the character after a set period of time which would nerf this.
Of course the server should allow some leeway for this. (And this behavior should be toggleable)
2 Likes
That would be quite impossible.
Also what if the player has a ping of 10-120 seconds this is common if Roblox is loading a lot of assets (eg when ContentProvider.RequestQueueSize is over 100 or when the network send and network receive are high).
It should be able to account for infinite ping and data delay. How it should work is that it gathers the path a player walked to and records the time of each position and then sends that to the server.
This would allow supporting infinite ping.
Anchored parts already have network ownership on the server.
This is an incredible improvement! Character deletion exploits are horrible to deal with, this is a huge step in the right direction! Loving the transparency from Roblox recently! Keep it up!
1 Like
Amazing, i can worry less now about watching players in my game and banning less people
1 Like
This is actually a blessing. This will fix so much. Keep up the good updates.
massive W from roblox, finally a blow to the kids who use FE fling scripts and exploits to reanimate hats to produce NSFW actions and such.
2 Likes
Oh my god, this exploit almost ruined my game, best roblox update!
It's ironic how you acknowledge that the change is replicated to the server [aka, the server suffers the consequences too] before basically saying, "only the exploiter will suffer the consequences of this".
Benefits of character deletion replication from client → server: (non-exclusive)
- Godmode
- invisible fling deleting everything under your character except HumanoidRootPart, then spinning like a skiddy beyblade
- giving someone your undroppable tool(s) ie: Giving your friend a gamepass tool
- invisibility in games containing morphs where your character is set to Transparency 1
- A tool which has at least 1 other part can have its welds deleted while the handle part is over/inside a basepart with a
TouchTransmitter; allowing you to give that tool to a friend/foe to have the server detect that they touched the part you wanted them to - In games where you can trade other players your exact tool aka the server just sets the parent to their inventory you can delete anything required for the tool to work before trading it bonus points if it’s a desert game
- Games which
:Clone()a sound into a character or tool you are using when performing a specific action, like shooting a gun, can have the sound deleted to suppress it and thus prevent other players from hearing it - Games which
:Clone()a model inside of a tool into workspace, for example, time bombs, bow and arrows, etc, can have their contents deleted. For example, deleting the server script in the model of a timebomb before it is cloned responsible for the automatic detonation/cleanup of the timebomb would cause a timebomb to never get deleted… - Edit: Forgot to include
custom nametag deletion; common in Cafe games (deletion of billboardgui/etc for the purpose of anonymity; makes it harder for other players to identify an exploiter)
I hope this answered your question and or caught you up on this manner. 
8 Likes
Your max ping in roblox can only really be 120,000 ms. (2 minutes)
The server has to pull the plug when enough is enough.
1 Like
Ok well sure thats understandable. But a 2 minute or even a 10 second ping ping still wouldn’t work with a traditional movement anti cheat (which checks the delta position change with different timeframes (either per tick or per 1 seconds)).
Instead how it should function is the client sends a list of positions where the it was and at what time (with workspace:GetServerTimeNow). And then the server should validate them and if something is invalid teleport the player to the last position.
(Of course unnecessary data should be discarded and optimised. For example if the player walks in an approximately straight line get an end and start position instead of many positions)
Also in this data should be included all other actions (like shooting guns and pressing buttons) and the position at where the player was when they did that and the time they did the action.
Also another thing is that even though the ping can be not so high, Roblox can throttle data send for much longer.
If this helps anyone in search to prevent a player from “resetting” their character by disabling a motor, try this:
antiExploitMotor.rbxl (37.5 KB)
This will prevent the player from deleting their motors to forcibly reset or create CFrame animations. If your game has a ragdoll script, it will likely cause a false-positive.
However, it seems like this update changes that here.
Anyways, great update! I’m going to test this out on some of my games and see if it breaks anything, but I reckon that it won’t.
Edit: Yeah, they all work. No action required for me!
What does that have to do with anything? 
You’re still getting kicked after 2 minutes, even if it’s “throttled”.
What means by deleting? like :Destroy()?, how about falling to the void? Will be there any connections related to this boolean? Because I wanna do anything besides just generic respawning. (Kick) Also does this mean scripts like this are finally patched? Because i’ve seen exploits use familiar scripts like this to bypass anti-cheats.
local character = game:GetService("Players").LocalPlayer.Character
game:GetService("Players").LocalPlayer.Character = character
An example of said connection would somewhat look like this
workspace.CharacterRejected:Connect(function(Player: <player>?, Instance: <instancedeleted>?)
Player:Kick("Do not delete "..Instance.Name)
end)
It will just affect them on the client. On the server, the character appears to still be there. The prior behavior was seen when ReplicateInstanceDestroySetting was disabled. Now, it’s here by default.
Luckily, it won’t even respawn them, unless they die on the server. It will look like they’re lagging on the server when it happens, and they will freeze. On the client, their character is just gone, until they parent it back to workspace.
So, the hacker doesn’t even know what is happening on the server. They might see themselves getting shot at in that FPS game right before it’s too late though.
We cannot tell if it’s intentional to delete the character, so this isn’t a good idea.
The only issue I see is that people are able to delete stuff in PlayerGui so the server might error when trying to update it. This change doesn’t necessarily change that behavior, but it would be nice to be able to manage replication of destroyed instances.