Service Side Code:
local hrp = char:FindFirstChild("HumanoidRootPart")
Connection = hrp.ChildAdded:Connect(function(v)
if v:IsA("BodyForce") or v:IsA("BodyThrust") then
Essentially the exploit I am trying to patch, creates new instances such as BodyThrust in order to utilize a fling exploit.
When tested, even though a BodyForce and BodyThrust was created for the exploiter conducting the tests for me - it did not kick them. Any help directing me the right way to patch this would help greatly.
Try using InvokeClient to fetch the player’s character on the client, and then loop it on the server.
Connection = char.ChildRemoved:Connect(function(v)
if v:IsA("Humanoid") then
That is a script I used for getting rid of a kill exploit using teleporting with tools. It’s not an error regarding fetching the character.
Yes but if the child is being added on the exploiter on his client, then you would need to fetch what the client sees.
If the client is locally adding those instances, the server won’t see it.
However, all physic changes applied to the character by the client does replicate.
Regardless, a better implementation would be to perform a check to determine if the character’s movement seems reasonable. If the distance traveled by the player within a second is greater than some value, for example, then it’s probably expected that the player is hacking.
When exploiters use this exploit, they insert body movers into their character on the client which is invisible to the server.
Client-Sided anti-cheats may stop exploiters at first, but eventually they will figure out how your anti-exploit works and create code to delete it and even mimic the behavior of it if you have some kind of system in place that requires the client to incrementally tell the server the player is ok.
Anyways, I see two ways you could go about resolving this issue:
- Create a script that constantly checks the Magnitude of a player’s AssemblyAngularVelocity on their HumanoidRootPart and compare it to a set threshold to determine if the player should be kicked or not.
This will work most of the time but may cause a couple of misses or false positives in a situation where the player gets flung somehow or rotates their avatar quickly, or an exploiter finds a sweet spot where they can still fling players but remain under the threshold.
- Create collision groups with
PhysicsService to allow players to phase through each other.
This is the more solid solution but might be unacceptable if your game counts on players colliding with each other.
So you said its a SERVER sided code, it will NEVER detect the exploiter, exploiter changes are CLIENT sided ONLY
But in order to fling the character, the changes must be replicated to the server. That is where you can nail them.