![]() This is because we might get false positives from slower players who are still moving at 16 WalkSpeed but appear to be moving slightly faster to the server. They need to stay somewhat proportional to each other, or we might get false readings!Īlso note how I didn’t make maxspeed 17, directly above the default 16 WalkSpeed. Note the values for maxspeed and checktime. Local lastcf = root.CFrame -We will store the player's CFrame so that we can move the player there if they seem to be hacking. Local root = script.Parent:WaitForChild("HumanoidRootPart") -Get HumanoidRootPart so we can keep track of the player's position. If we make checktime too fast, like ".1", the script will be recording positions too fast and thus will fail to work correctly! Local checktime = 1 -How many seconds we wait before we record their speed. Let’s add some variables first: local maxspeed = 22 -The maximum distance the player can travel within a check time. ![]() ![]() To begin, place a script into StarterCharacterScripts. We cannot rely on properties like WalkSpeed or Velocity to catch a hacker, but we can compare their positions to see if they’re cheating! Don’t freak out if that sounds too complex for you, because it’s actually really easy. If a player seems to be moving too fast, we stop them. The best way to detect a speed hacker is to check their location on the server. This means we need a way to detect ALL speed hacks, not just a specific method of doing it. The most basic hack could alter the player’s WalkSpeed, and more advanced hacks can change their FPS. There is extensive discussion on exploitation-prevention through sanity and validity checks on the devforums, so I suggest you look up existing discussions first.Before we can stop speed hackers, we need to know how they speed hack in the first place! The truh is, there’s no single way people do this. The only exception is situations where you ask the server before doing something or you can limit what information is sent to the client. I can think of some fairly complex, hard-to-beat (but never impossible-to-beat) solutions, but the more complex they get, the less worthwhile they are to develop. Then you can ban then remaining ones that you find break through. You want to find a solution that will catch most exploiters while taking you only a small amount of time to develop. Keep this in mind.ĭon’t try to make a perfect foolproof system because it can always be beaten eventually. An experienced exploiter can beat any system that requires code to run on their computer. ![]() Something like that is actually a good idea if your game depends on players not being able to see past 300 studs, but it’s not foolproof. Replacing FireServer was actually a common technique in the past (and possibly now) to discover what RemoteEvents a game has. It’s also possible for them to replace the FireServer method so that it checks what script it’s being called from and doesn’t run if it’s not the exploiter calling it. It’s entirely possible for an exploiter to hook into the section that runs Lua code and check the source before running. Exploiters have to use programs that compile and run Lua code in a more complex way than just inserting a script. It can only run pre-compiled Lua code from the server. In fact, the Roblox client can’t run any new, from-source Lua code. ![]() Exploiters have access to more than just running Lua code. The server would still get the “hi” message. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |