But recently, Players have been able to break the script and it no longer functions, as it runs from a LocalScript anyways to detect the client. Took me a while before I gave up and decided to use the ScriptContext error event to kick the player if they broke it, but I’m worried as if it might break even though they didn’t really do it (faulty code). I decided to take a look at GetPhysicsThrottling, but there’s no information on it.
Btw, sorry if I’m posting too many threads, just wanted to get this out to you guys.
If they’re actually deleting the local script, you can detect that by having the local script ping the server every X seconds by firing a RemoteEvent. If the server doesn’t detect a RemoteEvent from a user within a certain time period, you can assume that the local script stopped running, and kick them.
I asked someone to test it in one of my places, and using the server console I found out that they’re changing the source of the script, not deleting it (aka script stops due to an error).
does scripts halting due to errors replicate to the server?
you could use one of the error monitoring scripts to determine if a script halts due to an error, and if it does the guy is hackering and you can safely get rid of him
They are apparently bypassing it by renaming the GetRealPhysicsFPS method name in memory, so the script errors when it’s called. Checking if the error message is “attempted to call GetRealPhysicsFPS a nil value” should be perfectly safe for legitimate players.
I don’t know if it’s possible to check FPS of other players server-sided, and WalkSpeed just doesn’t cut it. For now, let’s just hope that they don’t break ScriptContext.
Wouldn’t this equation solve your need?
(Torso.Velocity * Vector3.new(1,0,1)).magnitude > 17
If its true then that guy is hacking. You should also check if they are free falling or not.
[quote] Wouldn’t this equation solve your need?
(Torso.Velocity * Vector3.new(1,0,1)).magnitude > 17
If its true then that guy is hacking. You should also check if they are free falling or not. [/quote]
that won’t do anything because the velocity is determined by the client.
[quote] Wouldn’t this equation solve your need?
(Torso.Velocity * Vector3.new(1,0,1)).magnitude > 17
If its true then that guy is hacking. You should also check if they are free falling or not. [/quote]
that won’t do anything because the velocity is determined by the client.[/quote]
That’s not a legitimate answer. You assume that a user will actually know what ever the heck you do to check if he is speed hacking or not. Oh and at the client side, what are you going to do to make the velocity be 0,0,0 all the time? You’re going to anchor yourself and move the character like that? Checking for collisions and all the animations you’re supposed to do to create a proper character. And you expect a script kiddie to actually be able to do these stuff?
[quote] [quote=“Oseday” post=73300]Wouldn’t this equation solve your need?
(Torso.Velocity * Vector3.new(1,0,1)).magnitude > 17
If its true then that guy is hacking. You should also check if they are free falling or not. [/quote]
that won’t do anything because the velocity is determined by the client.[/quote]
That’s not a legitimate answer. You assume that a user will actually know what ever the heck you do to check if he is speed hacking or not. Oh and at the client side, what are you going to do to make the velocity be 0,0,0 all the time? You’re going to anchor yourself and move the character like that? Checking for collisions and all the animations you’re supposed to do to create a proper character. And you expect a script kiddie to actually be able to do these stuff?[/quote]
it most certainly is a legitimate answer: the client controls the physics of the character. Speedhacking is not walkspeed hacking, they are making the simulation run faster, and as a product of that the characters move faster. That means for a given amount of real time, there is more simulation time. Velocity is determined by the difference in position over the span of one physics frame. Increase the framerate and things move “faster.” If you speedhack and your walkspeed is 16, you’re only moving 16 studs per second in the simulation, even though in reality its greater. That’s why using part.Velocity is a bad idea: the parts are not moving faster, the game is moving faster. Also, the actual method of determining whether or not someone is speedhacking is fundamentally flawed even if it were able to distinguish between speedhacking and non-speedhacking: if the player ever gets in a vehicle and drives faster than 17, they’ll get kicked. If a player ever falls down or gets on a conveyor belt, they’ll get kicked. The solution is poor and has too many false positives to be an acceptable solution.
