![]() ![]() I’ll start with bad player experience, which I’ll define as not punishing potential cheaters effectively. UX, or user experience goes both ways here. This also includes vertical momentum, so even if you’re falling too fast, this will go off.Īs for alternatives, I would suggest measuring strictly horizontal velocity, and detecting for consistent time intervals that the speed goes above the norm. Running event fires does not pass the value of the Humanoid’s WalkSpeed, but rather the velocity at which the HumanoidRootPart was going when it does. This is a bad way of detecting (and dealing with) speed hacks for a few reasons, but the main one I’ll point out is that this can be set off by physics acting up. I’ll use a recent example of a false positive gold mine. This can be for any number of reasons but usually boils down to a small oversight on what the developer believed was possible at the time of writing their code. Speaking of false positives… False Positivesįor those who don’t know, a false positive is when someone is incorrectly labeled as an exploiter. I advise against memory checking not only because it can be bypassed within 10 lines of code, but also because it can return false positives on players with lower-end hardware. ![]() In summary, don’t rely too heavily on client security. If you want to learn more about spoofing, do check out this thread. They’re able to completely override any method called on the client. I’ll go over a brief list of common client-sided anti-cheat measures which can be bypassed within minutes.Įverything listed above can be spoofed by an exploiter. Anything the client can do, an exploiter can do. The second and most important reason is that the exploiter has full control of what the client does. While it’s not a terrible idea to secure the client a little, I just hope you understand that it takes one competent exploiter to release a script to the masses and forever nullify your client’s security measures. My personal big three of the bad practice list are ![]() Now while these posts are met with valid criticism, and usually get locked within a few hours, I’d like to attempt to educate any aspiring anti-exploit developers with a few of the most common bad practices I see in such posts. Repost because I accidentally posted it earlyĪlmost every day the # resources:community-resources section is blessed with an anti-exploit which can’t even do its job because it indulges in some bad practices. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |