I wonder if we make something like bullets move to the gun’s look vector and the gun look at the position where the player is aiming at so we can detect that from the server
1 Like
It’s really not hard to find and disable the correct script. But even for the exploiters out there who know nothing about anything, keep in mind all it takes is one single person with any ounce of knowledge to publish a script for that game that will completely bypass all client-side anti-exploits. Exploiters can also just disable client-side kicking on top of that, which anyone can do easily.
This isn’t to say that you can’t use client-side anti-exploits, it’s just to say that they’re a weak and temporary measure that will only do so much. A server-side anti-exploit is the only thing that can guarantee that it will work (at least as long as you’ve coded it correctly and take into account false positives).
For basic attacks, this would work if you also obfuscated the code. I think this is about as protected as client-code can get. It’s still possible to get through any obfuscation, or the exploiter could just rewrite their own client script to do everything, but it’s a good start.
1 Like
No. This is just assuming that you’ll never update your anti-cheats. Staying competitive with exploits out there will leave a trail of “broken” bypasses that are almost always detectable. One person isn’t going to completely undermine your efforts if you are doing your job properly.
it’s not enough to just make an anti-cheat. You need to update it and stay competitive with it. In the same way you iterate on parts of your game you need to iterate your anti-cheat.
People use scripts from other games because enough of the features transfer over, and people use generic any-game hubs/scripts all the time. Even if people do write bypasses for your game you are still going to catch people who don’t have your-game-specific exploits using client-side detection methods.
There is no reason to not use client-side methods. “It can be disabled” doesn’t hold any weight in real world applications. Just don’t depend on them. It’s that simple.
2 Likes
Exactly, you don’t depend on client-side anti-cheats. As I said in my previous reply, it’s something you can optionally use along side a proper server-side anti-cheat. Spending your time constantly updating your client anti-cheat is time spent away from making actual relevant updates to your game. There’s one of you and potentially thousands of them. Catching people hardly matters when there’s plenty more to take their place.
This is exactly what I meant by only requiring one person to make a game specific exploit. People tend to look up game specific exploits before going in with anything else. It’s also very easy to detect changes that have occurred since previous updates, as well as sandboxing the client. All client-side anti-exploits do is delay the inevitable. It’s perfectly fine to use them in conjunction with other more reliable methods, but it’s ultimately a losing battle.
1 Like
Exploiters can see what is inside of local scripts and they can delete entire local scripts and replace them with their own local scripts. This won’t work. There is no way to patch aimbot fully without the help of ROBLOX.
Not even server authoritative characters would help to patch aimbot because people can just write more realistic aimbots to get around your checks and balances.
Thread is a joke take it down
if walkspeed > x bans thousands of exploiters every day in big games.
Each ban is more enjoyable experience for players in this specific server.
There are methods way better than this of course, intermediate exploiters won’t go beyond __index hook, you can patch it easily and ban so much more exploiters, providing more enjoyable experience for your players.
Every single detection, no matter how bad it is, will influence the amount of exploiters banned (if your game has stable ccu).
Each banned exploiter is more enjoyable experience for your players.
This is all about the charts…
I mean yeah, but that’s as far as anyone should realistically take it unless they want to devote all of their time to a losing battle. The server can also detect that, albeit less accurately (not that you couldn’t use both, and that would be better anyway).
But what I’ve been trying to say this whole time is that client-side anti-exploits are perfectly fine and there’s nothing wrong with using them. But they are objectively unreliable, so they cannot be used as the only means of anti-exploits. You can use both, but don’t rely on only client-side anti-exploits.
While it’s true than an exploiter who knows even a little bit of scripting can bypass the majority of client-side anti-exploits, I think that’s a bit harsh. As I’ve said, nobody should rely on these client-side anti-exploits, but they do work to some extent.
(Plus there’s no reason to bash them for making something like this and publishing it. I’m not sure why everyone gets hostile when exploits are involved in the topic.)
1 Like
As a person who runs a decently sized game, and knows people who also run decent sized games, this is wrong. It is a part of your game, you don’t get the luxury of ignoring your anti-cheat to develop the rest of your game. You are failing your players if you see your anti-cheat as a seperate from your game.
Catching people matters on any level. If your anti-cheat method gets results, it wasn’t a waste of time.
What’s wrong with that? I’d rather delay it than allow it to steam roll into existence. Approaching anti-cheats with this theory-first methodology is bad advice for actually implementing them.
You’re not wrong but this fact hasn’t stopped my client side detection from being effective. The most exploit-generic client side detection I have in my game has banned over 63k accounts, and everyone and their mother has been telling me for years “it gets bypassed all the time”. To this day it still gets a substantial number of bans per month.
Stop arguing against client-side anti-cheat methods. There is no valid argument against them in real world applications for anti-cheats. I don’t understand this paradox of continuously arguing that they’re bad practice while also acknowledging their effectiveness when used properly.
2 Likes
Any anti-cheat method is fine as long as it works as intended. Client-sided is easily removed yet at the same time provides some of the easiest ways of detecting exploiters. Server-sided while not easily bypassable proves to be a bit more challenging to detect exploiters.
Both are acceptable despite their flaws.
2 Likes
Certain dark dex doesn’t even let you delete stuff without breaking most of the time. BESIDES! You can detect destroying on server! (Just parent it to character)
I can agree to some extent, but this is mainly a luxury for those who actually have the time to work on those sort of things. An FPS or mainly PvP type of game will likely not need content updates as much as other types of games. Although I suppose PvP games are the kind of games where it would be most useful. But what I’m arguing is more that you should focus on server-side anti-cheats that are virtually impossible to bypass, rather than so much of a focus on the client.
Clearly you haven’t read anything else I’ve written here, but I’ll say it again. Client-side anti-cheats are perfectly fine to use, however they should never be relied on. This has always been the stance on client-side anti-cheats. They work, but they’re not an end-all be-all. I always bring this up due to the amount of people that overly trust their client anti-exploit.
The reason I said what I did on this thread is because this thread was about a client-side anti-cheat that can be disabled. Yes it’s usable and it will catch people, that’s fine. But there’s going to be plenty more people who won’t be caught by it.
I never said that you couldn’t or shouldn’t use it, only that it isn’t guaranteed to work.
(Although, reading back, I do see that I use a lot of definitive words like “pointless”. I meant to use those terms in regards to preventing any exploiter, rather than some.)
The server wouldn’t be able to detect the script being disabled. Also don’t bother with one of those systems where the anti-exploit is pinging the server with a code so that the server can detect when it’s disabled, because an exploiter could easily replace those pings while also disabling the client-side anti-exploit script.
Although, the harder you make your code to understand, the harder it will be to figure out how to mess with it. If you’re going with the code method, I would recommend either having it change randomly or have the server send the code once on player join (as most people aren’t recording remotes on join and even fewer know how to look at memory), then have the ping use an encrypted version of the code using the same encryption that the server would use. Something like a timestamp-based encryption could work, but that’d be a weak point for anyone to reverse engineer the encryption.
But all of this is over-engineered when you can just edit the script to remove the anti-exploit part and keep the rest.
It should be done on the server. Raycast from the player to the enemy if they’re visible, simple.
“silent aim”, on the other hand, might not be as feasible to engineer an anti-exploit for.
thats true however if they dont it will work
1 Like
depends on the gun system, a dahood gun system would work with this
After reading the code itself, it doesn’t seem very optimized.
you can improve it if you wish to
ohhhh thats much better, also i recommend instead of kicked just killing the player
