Is it 'safe' to update player's WalkSpeed locally?


I’m working on a game that involves the use of crouching and crawling. To keep it simple, my code updates the player’s WalkSpeed locally. If they press the select key to crouchwalk, their speed is reduced, and when they are done, it reverts. As well as all the other fancy additions to make it a true crouch. My concern is whether or not updating walkspeed locally is safe in regards to potential exploiters? Or should I try to utilize another alternative to this? I’ve looked around, and I couldn’t find an answer.

Bonus: My game is also very dependent on the lighting conditions, which also updates locally. Could this be a problem too?



Exploiters would be able to set their own WalkSpeed anyway. You could set WalkSpeed on the server and use that as a basis to confirm that a player’s velocity or displacement doesn’t far exceed what the server knows the WalkSpeed should be around. This being said, I wouldn’t really call it safe because there’s nothing dangerous in the first place.

Ideally you want to set WalkSpeed on both the client and the server, or hold a reference to what the client’s WalkSpeed is on the server. The client sets it for minimal delays between speeding and not speeding, while the server uses it for security purposes.

When an exploiter sets their WalkSpeed, the server doesn’t receive the value. The only thing the server would get is the physics replicated to it by the client, as the client has network ownership of their characters.

Relying on the client may be a bit much, though.


Any hacker would be able to change their lighting locally and make it so they’re able to see anything. The hacker would be able to change his walk speed no matter if the server set it or not. You would have to have some sort of checks on the server if the player is going faster than they should be going. A simple thing that checks if the humanoid walks speed from the server wouldn’t work though. I would look at this thread


You should probably be cautious about doing this. Anti exploits could interfere.

Exploits execute code clientsided, meaning exploiters would change their walkspeed clientsided, or locally as you seem to address it. What an anti walkspeed exploits would do is check if the clientsided walkspeed = the server sided walkspeed. If you decide to legitematly set the walkspeed clientsided, then this method wouldnt work and you would have to take Another approach.

1 Like

Exploiters already have full control of the client. If you want to prevent speed hacking, you’ll have to do so manually with position checks as character position replicates automatically, even if the walkspeed property does not. It’s also not possible to completely prevent an exploiter from changing their lighting settings. You could have a localscript watching Lighting, but exploiters could easily just delete it or work around it.

Updating walkspeed from the client is perfectly safe and recommended, especially if you’re doing so in response to user input. Setting walkspeed from the server in your case would introduce input lag. All character controls should be handled locally.


Building on what @Kullaske said, the only way to prevent hall hacks and light editing to remove fog of war or similar game features would be to only stream visible objects to clients. Once an object is seen by the client, it can’t be “unseen” but you can stop sending updates making their information stale.

1 Like

Personally I always update the walkspeed via the server and haven’t had any problems, updating stuff on the client aren’t always the worst thing to do but making it a habit to do such stuff on the server is a good idea.

So in short, update it on the server and control if a player is going too fast all of a sudden.

1 Like

You could change the walkspeed locally and the server and other players will notice the difference in speed/velocity, however the number itself (16 by default) does not replicate. So the server will still think your walkspeed is 16.
You could use remote events to update this number.
That’s what I would possibly do.
Lowering walkspeed for crouching, prone, etc is fine by me, but if you’re going to higher the walkspeed again I would do a check to see if the walkspeed doesn’t go above 16 or something (or above 30 if players can sprint).
I would update walkspeed on the client first due latency, else you get input lag because the sprint/crouch/prone doesn’t immediately respond to your input.

1 Like