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.
I think you completely misunderstood what I meanât and didnât read my post. My point was the ping for the player can be lower. But certain data can have more of delay to be senât. For example all other data might arrive in 30 seconds but physics data might take 5 minutes. This is because the engine prioritises certain data over other data when sending it in large delay scehnarios.
But that wasnât even my main point, just a side note. My main point was that a traditional authorative character movement system wouldnât work here Iâll elaborate here.
Normally:
Normally a character anti cheat would check the delta distance between two points and if there are any objects colliding in that area. But the prolem here is that if in that time frame there happens multiple actions at different time or/and the player goes around walls then this approach falls flat. Letâs take an example:
In this example the player sends data every 30 seconds. But in this time the player goes around two walls and shoots a player.
Here the traditional approach just doesnât work. Instead we should use a new one.
With the approach the client should send every communication a list of positions where it has been between the current communication and the last communication.
And the exact time it was at what position.
Of course it should optimise the list of positions sent. Instead of sending every position at time frames where it goes an approximately straight line, in this case it should instead just send the end and a start position.
And when the player completes an action in game like shooting, clicking a button, mining ores, opening a door, getting in to a vehicle or collecting a coin it should send the time that the action was done and the position of the player in that list too.
when will you make it default to enabled because I am to lazy to go through 30 games and enable it
Wouldnât the client be able to just spoof the position by sending completely fake data?
Yes, but thatâs why you do sanity checks. If a client sends an reasonably outdated timestamp or one in the future (which is normally impossible), then obviously thatâs not a valid timestamp. As far as player positioning, you can see if the distance between the data given and their current location is realistic. Thereâs a lot of things you can do to verify the validity of things like this. Rollback Netcode is designed on this premise.
2 Likes
Itâs been around for 5 months and I was waiting on this fflag to be released for months, Iâm happy that finally this is a great way to prevent exploiters from flinging, and most importantly the most annoying exploits of today which is reanimate.
I have seen exploiters bypass this is my games. I have found out how to patch this and will make a post about it soon, but itâs really annoying how insecure this isâŚ
For anyone wondering what exploits this patches here is a list:
Fe Hats
Fe Animation
Save Tools exploits
Invisible fling
Invisible godmode
Tool replication exploits
HumanoidRootPart deletion
Pretty much every single FE exploit/script
Source: V3rmillion thread about this change.
2 Likes
Correction of what this patches:
Save Tools exploits
Invisible fling
Tool replication exploits
HumanoidRootPart deletion
1 Like
Not exactly. Fe hats are no longer working. Itâs been confirmed by exploiters.
They still are, I have seen exploiters in my game move hats. They just cannot remove them
They can manipulate cframes because they have the networkownership of it! But they cannot delete the mesh!
The same thing also applies to humanoidrootpart teleports.
2 Likes