I am wondering how I would go about reducing the number of teleport exploiters. This is a big issue because my game relies on sword fighting and stealing other player’s time, so when players are wrongfully killed they have to be restored the time they had.
My main question is this: Are client-sided checks for teleporting worth it? I have it on the server but it’s quite forgiving and doesn’t kick a player unless they’re flagged twice in a certain amount of time.
I have many checks in my client-sided anti-exploit already and without a proper bypass, checking for teleports could be beneficial in my case.
In short:
You should almost never do client sided exploit checks
They can simply just delete the script or just edit it because using a localscript will just allow them to access it
As for your teleport issue, i’m not sure about that
This logic is very flawed for the simple fact that it doesn’t hurt to have it, also you can’t “just delete” this anti-exploit, I send a remote every 2 seconds (which obviously can be bypassed, but a regular exploiter wouldn’t be able to just join and delete the script immediately unless they run the bypass first), but that’s besides the point. Even without that, why wouldn’t you have client sided checks?
You could make the server-side anti-teleport more strict, but make it teleport the player back instead of kicking them. You could also have some sort of report system in your game where players can report exploiters with video proof of them cheating (you can probably do this in a discord server with a ticket bot). Having client-sided checks also doesn’t hurt; if you make your client-side anti-exploit really annoying to deal with, you will stop 99% of skiddies
The majority of exploiters are skiddies so the whole “client-sided checks are useless” must be coming from people that don’t have games themselves and are just thinking out loud. I’ll for sure tweak the server-sided checks a bit to be less forgiving, and I think I will just instantly kick players that traveled a certain long distance in a short time. The in-game report system is a good idea but my game only averages about 20 players so for now it’s pretty controlled with the number of mods I have.
I really appreciate these ideas though, and I will see about some client-sided magnitude checks or something.
I agree, I rather have a client sided anti that 90% of exploiters can bypass then no anti at all. As a sword clanner, I completely understand the annoying issue of click tp’ers, circle reachers (includes hitbox expanders), and the body part CFrame kiddos. Honestly, I would probably just suggest the same thing as hell_ish. Making the server-side checks more strict, while adding other stuff such as report systems, moderation team, etc. Note that teleporting the player to his original position might result in a terrible experience for players, as if they are running and have a small spike → they might get teleported back into harms way. Also note that sometimes serverside detections can give false positives so a laggy player might trigger your anti (depending on how it works).
Another alternative would be to not give immediate feedback to the exploiter that he’s been caught. What I mean by this is don’t immediately punish the exploiter once he triggers the anti. For example, lets say an exploiter attempts to bypass the anti → he fails → he gets kicked → since he got kicked he knows his attempt failed → he will rejoin and repeat the process until he finds a bypass.
You could however delay the interval at which the exploiter is kicked/punished or attempt to cover the fact he triggered the anti. For example, exploiter triggers anti → After a certain interval (3 - 5 mins) exploiter is kicked and display a message like “A moderator has kicked you for exploiting in game”.
Downside, will be they will continue exploiting till the interval period ends. Upside, the exploiter will be unaware of whether or not he was kicked by the anti or if a moderator did in fact kick him for exploiting in game. Basically, “you can’t fix it, if you don’t know its broken” type of concept.
Hopefully this gives some insight or ideas. Goodluck!
The downside you mentioned is the exact reason why I have it kick sort of immediately, but I see what you’re saying. I’m sort of new to the sword fighting development scene and by far the biggest issue is the exploiters. It’s especially hard for sword fighting games so any new checks I can add to my client-sided anti-exploit is a godsend.
About the circle reach, this is the only one I know of that I don’t have checks for and I’m not sure how I can even check for it. Do you know of a way I can or is it something I have to deal with?
Again, thanks for the reply and it makes me feel nice that you know of my struggles with exploiters
Circle reach is a much newer exploit than its predecessor the simple “resize your hitbox” tactic. You can’t really detect it on the server as the server will still see the swords hitbox as normal. Sadly due to the way touched events work, you can resize or fire the touch event without the sword actually making contact (from the servers view).
Circle reach mainly became a thing due to a server sided exploit prevention measure that’s now used in most games/clans. Its quite literally just a simple magnitude check from the Players rootpart to the targets rootpart. If its within a certain stud radius (the default is 12, this is to account for latency and lag), then you can damage the target.
I personally have not looked into how circle reach works but I’m guessing its quite similar to hitbox expansion. Your best bet is to do the magnitude check (if you haven’t) and potentially make it more strict by maximum distance the players can be from each other. You could also try raycasting in front of the player a few studs forward from the rightarm to see if a player is actually within their range. If so allow them to do damage, etc.
The only real annoying thing about circle reach is that its hard to visually detect (via witnessing in game) due to the fast combat of sword fighting and latency/lag. So unless a player is standing still and damaging people behind them, clips of people circling will be hard to differentiate from laggy players.
I have the magnitude checks for my swords, but I actually looked into how circle reach works already and it basically uses a documented synapse function (it’s in other executors as well) called ‘firetouchinterest’ which basically creates a fake TouchInterest and fires it on all the parts inside the circle around the player.
I wasn’t sure if there was a known patch for this exploit or not, so I’ll try to look it myself.
The older method of just using a SelectionBox is easy to patch because you can just check when a SelectionBox is added to the game on the client and kick the player if one is added, but circle reach puts something in the CoreGui which obviously isn’t available for us to check through local scripts. The only method I can think of is making every other player’s Character nil so the script can’t fire a fake TouchInterest on the victim but that’s not the best for other script’s functionality.
You could also just write your own hit detection system using raycast or regions (wouldn’t really recommend regions tho). This would solve a lot of issues regarding reach exploits as exploiters would no longer be able to manipulate the hitbox. However, the downside would be you would have to do all the raycasting/hitdetection on the server which can result hits not registering for laggy players. Another downside would be the feel compared to traditional touch events would be quite different for older sword fighters.
Also tried this, but like you said it makes swords extremely laggy and not function as normal. Raycast Hitbox would in theory fix all reach exploits though.
positional checks, you ping a target and set a max position they could move in a single ping cycle,
then, should they exceed that max position they either got flung, or are exploiting. it helps a bit more if you exclude y movement (since i doubt you’re making anything that actually gives you a solid advantage in the y direction)
Setting the players character to nil might result in more issues if other local scripts utilize anything within the character. I know there is a “hacky” way to detect if something is added to the CoreGui but its inconsistent and unreliable (just do a quick google search if you’re interested in it anyways).
Tbh hit detection should always be on the server. Unfortunately on Roblox its custom to do it via client as most players don’t have good pc’s or connections.
If only this were true. Most exploiters will often set it to a smaller value (around 8 - 12 studs). When they fight and are wiggling/jumping it becomes much harder to determine if they actually hit the player or not. On your screen you can say “He didn’t even touch me, must be circle”, but I could just argue that its latency and that either you, me, or the server was lagging. However if the player is standing still (like typing/chatting) with his sword out and damages you from behind, then of course thats circle.
Yeah true, I guess it’s harder to determine if it’s circle reach or not when there’s a max distance of 12 studs in place. And yeah, I meant when the player is standing completely still and doing damage for the painfully obvious cases.
I’m just gonna make my punishment system more harsh on the server, I think I’m prioritizing user experience a bit too much here by having lenient server-sided checks, although it’s hard to find a good balance since a majority of the players are actually on mobile/tablet so lag is an issue for many players.
firetouchinterest simulates a Touched event, it doesn’t create any fake TouchInterests or put anythin in the core gui (AFAIK). The way circle reach works is the exploiter simulates a Touched event between the sword and a nearby target’s bodypart which replicates to the server (because Roblox).
I don’t really know if there is a good way to prevent this but you could try adding a client-side check (for minimal delay) to see how far the sword was from the hit part’s position when the Touched event was fired. Sadly, this can always be bypassed by exploiters, and might be a little bit annoying to set up.
Oh alright, I knew it was something along those lines. The thing put inside core gui was the actual circle representation of their exploited sword’s hitbox, but that may only be for the script I was shown. I think I will just have to deal with that for now because I don’t know of any sword fighting games like mine that have detection for it and they’re games are larger so I’m sure they would have been shown a method by now.
