Afaik this is what PF does, except as punishment they switch off damage.
I donât think this will be an issue if you set your thresholds high enough.
None of these should trip instantly, or if they do then their individual thresholds should be fairly high. For example, passing through 5 parts, teleporting 200 studs, or flying for 10 seconds. No high-ping player should activate those, but exploiters probably will.
If you have low thresholds individually, then you need to be looking for multiple trips instead of activating on the first one. For example, only punishing the player if you get 4 trips in 10 seconds.
How tightly you check for these things will need different values per-game. Itâs probably not going to be a single set-and-forget. Youâll need to tweak it such that it doesnât catch high-ping players but does catch exploiters. Thereâs a lot of variables to mess with to get it right.
Fun idea: adjust the thresholds with the ping. Low-ping players get tighter thresholds. This will prevent low-ping exploiters from taking advantage of the high thresholds. Iâm not sure how this would work out with high-ping exploiters, or exploiters that intentionally increase their ping, but Iâm confident that with the right tweaks it will work well enough to deter exploiters without affecting legitimate players.
4 Likes
I have created a RayCast from the last position to the current position every frame, and sometimes the ray gets registered when they walk super close to a wall, any way to ensure it was an exploiter to filter out those that just touched the wall?
If youâre raycasting from the last center of the HumanoidRootPart to the current center of the HumanoidRootPart, then that should only rarely happen on corners if the player has high ping.
That is one such case where you need high thresholds. Either only trip on 2 parts between last and current or only trip if the user passes through multiple parts in a short timespan.
One workaround I can think of â if you donât want to increase thresholds â is to calculate the âdepthâ that the user walked through. You can do that by casting from last -> current and from current -> last and getting the distance between the hit positions. You can also look at the surface normals and see if itâs a corner.
If both casts hit something, then the user passed through something and is on the other side. You can set a threshold for what depths/distances youâre okay with here.
If one cast results in a hit and the other does not, then the user is or was probably inside a part.
Legitimate players should never be inside a CanCollide = true part.
If you want to take it even further, you can check which sides/faces of the part were hit and where on the part it was hit. If itâs near an edge or if the faces/angles are like an edge, then itâs probably just a player passing by a corner.
I would try just increasing the thresholds first. The above can take a bit of work. Maybe increase the thresholds then do the above if that leaves too much room for exploiters.
11 Likes
Donât exploiters also fly by repeatedly jumping by changing the sitting value of their humanoid, or has that been batched? You should probably check for that too.
Iâve added some checks in the past but I would think that having the server check all the players every frame with multiple raycasts could get heavy? On top of that, it probably wonât work for that long. Smart exploiters can just make themselves have a tiny advantage, cheating the system. (If you took out people with those tiny changes, youâd hurt lots of people that experience lag)
You can try having local scripts that check for these changes so that it doesnât lag the server.
I know that now youâre thinking that an exploiter can easily remove them, but most wonât go a long way if itâs too much work.
Canât you just have multiple local scripts in different hierarchies that detect if the others have been removed, and another that gets placed into the PlayerGui on spawn, but after connecting the events the local script removes itself? It would be too confusing for most exploiters, I would assume.
1 Like
Patched. Robloxâs method was actually interesting though. Jumping immediately after sitting takes you out of sit mode without propelling you upwards like a normal jump. By the time you have sat long enough to allow upwords propulsion by jumping, youâve already fallen considerably, so that method is dead.
1 Like
This is already checked for.
If the player is doing this, their position will be too high off the ground for too long.
There is a reason I advocate for checking just position. The client could actually sit and jump repeatedly while the server-side Humanoid says false for both sitting and jumping the whole time.
This is true. I would still go for the reliable, impossible-to-workaround fix first. If it would catch legitimate players then the exploiter canât be doing any better than some players could do.
I put the checks I mention in the category of âsanity checkingâ.
I put the client-side checks many people are mentioning in the category of âsecurity through obscurityâ. I say this because they can always be worked around by a determined exploiter. Most exploiters just arenât determined enough to work around them.
âSecurity through obscurityâ never works 100%. Itâs certainly a great deterrent, but it shouldnât be your first step. âSanity checkingâ, on the other hand, always works 100% for the situations itâs designed to catch. I would suggest implementing sanity checking first, then the âsecurity through obscurityâ client-side checks last if you still have an exploitation problem after implementing sanity checking. This makes your worst case âexploiters are slightly betterâ instead of âexploiters destroy everyoneâ.
Certainly for most, but if anyone is determined enough to break through it, then they can give out or sell their exploit. Then you still end up with many exploiters instead of one.
You can change your anti-exploit method to make the exploiter redo their work, but you still had super-powered exploiters flying around your game for a while. Wouldnât it be better to have slightly-better-than-normal exploiters in these situations instead of having super-powered ones?
Iâll reiterate that client-side checks are not bad, but they are not a guarantee, unlike server-side sanity checks. I think it makes the most sense to implement the reliable method with a guarantee before the unreliable method that can be bypassed.
1 Like
Itâs always more reliable to have server checks, but I was pointing out that it seems excessive.
Youâre checking for everything every frame for every player, I havenât ran that many checks so I canât speak for the performance but I assumed it was heavy for the server.
Thatâs why I suggested just keeping the checks for those exploits on the client, and that if set up correctly it would deter almost all exploiters.
Of course it can be bypassed by the advanced, but under that worst case scenario; the game still has FE and correct server-client relationships (or I hope). These cheats donât have to always be looked at since they usually donât affect other players, but some games decide to check them.
I just thought it would be best to check the client so that it is not heavy on the server, and that itâs fine to just check the client since it will stop nearly all exploiters for these little exploits. But if youâve ran this with lots of players in game Iâd be interested in knowing if it has an effect on latency or not.
Whether or not this will be excessive depends on players per server, map complexity, and your thresholds.
If raycasts are your main performance concern, then I can tell you that I can support casting 200 random, length-50 rays at 30 times per second in Crossroads at around 55 FPS. Thatâs 6000 rays per second.
That would support between 50 to 100 players, if the Lua checks are not considered.
Worst case scenario, you might have to check less often and up your thresholds a lot. Having some sanity check for player positions is still better than no sanity check. I think sanity checks are an important part of âcorrect server-client relationshipsâ, and Roblox does no sanity checks on player position by default. Player position is still part of the âserver-client relationshipâ, even if itâs mostly programmed for us already.
That depends on the game. I think the ability to walk through walls, fly, and teleport affects most games. It will affect most action games, which are many of the games on the platform. The main games I can think of that it wonât significantly affect are social games, driving games, and games that donât use the Roblox character at all and have their own sanity checks for these things.
I sadly have not. I have implemented a form of this in an unreleased game, and it hasnât caused any issues. I also implemented a rudimentary version years ago that only checked for flying, and I did not see any performance issues.
1 Like
Really depends on how much the exploiter cares. Itâs not impossible to pattern match packets and remove information you donât want sent.
Also, funneling all your traffic through a single remote event/function is not worth it from an organization point of view. Just make your code secure in the first place.
Always assume the client is lying. You can usually stop script kiddies by obscurity which is the whole point of doing client sided checks, but hackers can only be stopped by air tight server code.
Er, security is not why you do client side checks. It can be a neat bonus to having them, but you have them for instant response when the client tries to do something they canât.
2 Likes
Ye, thatâs what Iâm sayin
Yes, but do you allow players to sit without a seat tho(Example a Sit button in a RP game)? if not then you can check if the player sits without a seat
Hum.Sit(Bool,Seat)
if not Seat then
Kill
end
something like that
ofc that is not the full script but you get the idea.
1 Like