You are trying to sanity check… input? There would be no difference even if UserInputService worked on the Server, because only the Client knows what buttons are being pressed.
1 Like
None of the messages above this one are important to this conversation anymore and the only thing that will benefit all of us is reading this that explains everything I was trying to say from the start
Roblox acquired a company for $11.6 million, and they’ve successfully managed to shut down every exploit that was present at the time, partnering up with one as well, and forced most exploiters to use Android, which doesn’t have Hyperion (anti-tamper) as of yet.
Also, if you want a fully Server-authoritative character that prevents exploiters from changing their speed, you should look into Chickynoid:
1 Like
I do appreciate this and I think it holds value but the whole idea of replacing the entire character physics/replication it seems a bit too far for performance reasons. I think there should be a simpler way to solve the problem described with magnitude checking anti cheat and how exploiters can grant themselves freedom by using your own checks against you
1 Like
It’s what many games outside of Roblox which care about competitiveness do, like CS2 or Valorant.
This really shouldn’t be a concern unless you are simulating thousands of characters, in which case Humanoid also start performing worse (I also remember the author of that resource saying it performed better than Humanoids).
Are you referring to this?
In this case, I think the problem is that kicking is such an excessive countermeasure that you are implementing a bypass to avoid impacting innocent players. Instead, you should prefer to remove the player’s Network Ownership of their character for a few seconds. This allows them to be flung, allows them to still control their character (albeit with input delay), and also allows you to avoid programming in a specific, exploitable bypass by instead only doing your magnitude checks when you know the Client can interfere with their character (i.e. checking whether they have Network Ownership over it), which they cannot when it is owned by the Server.
This is much better design for an anti-cheat that depends on magnitude checks, because it also reduces impact on players with a poor connection. You should avoid strong punishments with detections that can generate any false positives. All it takes is one kick for someone to be completely dissuaded from playing.
Knockback is hard to deduct from teleportation as you’ve made clear. I’ve come up with a solution for this though which I have not tested but should work relatively well.
First of all, I’m assuming your anticheat will:
- One: be detecting this based on 2 axes, x and z, to avoid falling from a high ledge from triggering the anticheat.
- Two: be based on the following equality (or any other walkspeed based equality) to check for movement cheats.
Magnitude > Leniency + WalkSpeed/TimeSinceLastCheck
You can add a variable to your anticheat which you can trigger for players upon knockback.
- When this variable is disabled, you can do a regular check based on WalkSpeed.
- When this variable is enabled, you can do some math to figure out how many studs a second a player is moving based on the applied velocity (which may be rather difficult) and then substitute this value for WalkSpeed in the previously stated equality.
These extra checks should make your anticheat less prone to false flagging, as well as minimizing cheaters.
Some extra recommendations as well is that instead of kicking players when they are flagged, simply rectify their position to a previously verified one which you can store however you like.
And an extra FYI I almost forgot to mention, no anticheat is perfect. This is especially true for an anticheat meant for every type of game on Roblox, which is basically impossible to achieve. Instead of trying to make something that can work for every game, I would recommend creating an anticheat for specific games to avoid further issues.
Of course, if this seems too difficult to implement, you can always use DisplayName’s solution
1 Like
I’m not worried at all about it being difficult to implement. I am worried about the following exploiter steps being taken and abused to their advantage regardless of your solution. Let’s pretend we are the rat(the cheater) and we want our cheese(to win the obby). Read the steps carefully.
Step 1: Activate explosive part that disables the anti cheat
Step 2: Teleport/Any movement based hack to the exact position of the next checkpoint in the obby while the anti cheat is disabled
Step 3: Repeat until you reach the end
If you are 1000% confident that the very moment they touch a part the exploiter isn’t given the power to reach the next checkpoint every single time they want to, then I’d say it’s worth using. Please let me know and thank you
This solution functions relatively similar to how a normal WalkSpeed check would work.
WalkSpeed is how many studs a player moves per second, hence why we are dividing this plus our extra headroom (to prevent false flags) by the time since the last check.
When the variable denoting that the player is currently having knockback applied is enabled, we do basically the same thing but instead we substitute WalkSpeed with a new value which we calculate based on the same way WalkSpeed works, but with the applied knockback’s velocity instead.
Based on this logic I can assume this solution will work well for your edge case.
Do remember that you are meant to be finding how far a player should move per second based on the knockback you applied, not by the player velocity, to avoid this check being completely useless.
Does removing the player’s Network Ownership of their character prevent them from moving entirely? This is the solution if it works but if it’s only for a small period of time this isn’t a great solution either. Theoretically I should be able to make it to where if a cheater steps on an explosive part, their network ownership is stripped from them for a minute, they cannot teleport or move whatsoever and movement is only based on the humanoid state they are in on the server(knockback until they reach death or a landed point), and then the anti cheat re-enables
It prevents them from moving in a incorrect way, i.e. they cannot teleport or fly or speedhack. Only their movement direction is replicated, and the Server applies physics based on their WalkSpeed/JumpHeight, so essentially it would be like none of their character exploits were active.
2 Likes
This is really interesting I am going to test this right now and see what it does
This works as well, I forgot about network ownership. I would recommend this solution over mine as it is far less of a hassle to get working correctly.
Absolutely horrible solution as far as fun goes. Takes away the entire knockback effect. The only thing it does is fix the problem, it doesn’t actually allow us to do anything exciting from the server(I can show you a video if you need)
This will have to wait until tomorrow because I need to go to bed now. I will gladly mark an answer to this problem as a solution when I wake up if I see any. DisplayName did fix the problem at the expense of creating a new problem, so that in my eyes and in everyone else’s should not count as a solution because I won’t be using it and I don’t think anyone should either unless you absolutely careless about how little movement you can actually achieve once you’ve set the char networkowner to nil
1 Like
Alright, if you have any issues make sure to let me know and ill get back to you as soon as I’m available. Good luck!
1 Like
Based upon your message, I was actually able to come up with the best solution on my own for all competitive games. It is not perfect as you stated but on an edge case like this where I am the supposedly insane developer that wants people to have tons of fun with lots of dev products to choose from… this will work the best for me and anyone likeminded. In this example, it will be for an obby.
Optional Leaderboard System
-
Anyone who chooses to be on the leaderboard must report to the developer for verification where I will spectate them beat my game legitimately. Otherwise they will be banned because they have been caught cheating or using my gamepasses/dev products to reach the highest on the leaderboards(for obby completion time, wins/coins can be exploited until you catch them at an absurd number where you can just ban them, you can always track how much of a certain item/statistic that a player has and when someone has too much of it you can kick/ban them)
-
Free to cheat game that bases everything on elapsed time. You can totally cheat, use dev products or gamepasses, etc. You set a reasonable amount of time which you believe is the fastest possible time a player can beat the game, and if they beat it any faster than that time you can simply kick them telling them that they beat it too quickly.
This is just an example, but it provides the information that everyone would need to make a competitive fun game where exploiters have power until they try to do the unthinkable and then regret it. Oh yeah and as a bonus you can always add plenty of client sided anti cheat/smart sanity checks on the server/baiting(Example: Putting a remote event that automatically wins the game and once fired the exploiter gets banned) that won’t interfere with the fun of your game at all 
Hope this helps everyone! This is definitely the solution made simple for you all. Cheers 
1 Like
Well, I don’t know how you implemented it, but in my implementation it works fairly well. The obvious problems are that on knockback, it can seem jittery as network ownership is switched (which could potentially be solved with some replication shenanigans), but I’m glad you seem to have found a solution that works for you.
1 Like
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.