I have sprinting in my game, problem being that script is entirely client-based
i was thinking of using remote events to sprint, but the problem is if the client has like 200 ping, sprinting is extremely delayed
but having sprinting on the client entirely just makes it easily exploitable, and i do not run any speedhack checks on the server
Obviously, Since your using remote events. Hackers could simply keep on firing the same remote over and over to gain infinite speed.
No, This is not a good practice to be honest.
I am no expert but this is how i would do it:
SprintModule.rbxm (3.1 KB)
There are a bunch of clutter features in this module.
Dont worry about them just extract what you need.
I don’t believe using remote events would be any safer than putting it directly on the client, as your lack of sanity checks on the server means that the client could literally modify its runspeed anyways and you’d have no way to knowing.
You can’t really do anything about the ping, since it’s the player’s issue. So you should prioritise preventing exploiting
If the entire sprinting/movement system is on the client, then you’re making it a lot easier for exploiters to… exploit, with remote events you can perform sanity checks on the server and on the data of the remote event as well as set a quota so that if it’s activated too quickly (by an exploiter attempting to crash the server or something like that) you can kick or ban them simply because, unless it’s bad code then a normal player wouldn’t be able to do that.
If you do decide to use RemoteEvents, I recommend implementing some sort of floodchecking solution, with ofc checks on the server. I’d encourage doing sprinting and other movement systems on the client, and if you do, one idea you could look into is a confirmation system, where whenever your movement script applies a change, it notifies the server with it’s exact parameters, so the server is able to distinguish what’s done by your system and what’s not.
(pinging so i don’t have to reply to each person individually)
@MysteryX2076 @aDemoness
yeah honestly i don’t really know what to do at this point
using remote events will crash the stock market of players with worse internet, and will make sprinting have delay since client->server communication
not using remote events will not crash the stock market of players with worse internet, but will make the code very easily exploitable
but then again, if someone really is speed cheating, there’s always a votekick function, even though most of roblox is not competent enough to know what a votekick is, it should get rid of obvious speedcheaters
there’s a lot of factors that play a role in this
the bigger problem arrives when there are movement speed buffs and debuffs, some are from certain passive buffs that come with your perk, some come from stims (or consumables in general) and some come from rng along with combat
If you want to stop or heavily limit it, then just check if the player is moving too fast or for too long while they are supposed to be spriting on the server. Be generous of course to account for potential latency issues. And teleport them back to where they were earlier if they exceed it. You could dynamically handle this based on their buffs (+ tolerance), or just set it to the maximum by default to only affect the obvious cheaters. You won’t need remote events for this since you would be directly using player positions.
(This could if course depending on your game get too complex to be practical, but at that point you don’t really have many options other than what you’ve already stated)
i looked at the code @SaintImmor gave me, i didn’t yoink it, i just got inspired from it
the code uses attributes to do walkspeed and sprintspeed, those attributes get changed by the server from stims and perks only, the client can STILL modify those attributes locally
(horrible code incoming)
i’ll need remote events to tell the server the client wants to sprint no?
unless you’re talking about some different method
Yes, though you could also potentially infer it from speed changes if you wanted. The event is easier and won’t be a problem since you are just telling the server the clients intent to help you get more fine grained control over what you are measuring. You shouldn’t trust it blindly though.
Remote events don’t have that big of an impact on network performance.
(I have extensive documentation)
but it still takes time for that remote event to travel to the server (if that makes sense)
While this is true, note it will take roughly the same amount of time it takes for your players updated position to reach the server.
You could also consider the leaky bucket limit for speed as a way to put limits and tolerance as @tlr22 said.
Stamina is similar to regening mana as it is done continuosly or in bursts hence the tolerance metaphorically described as the bucket.
Ideally the standard is chickyoid with server sided movement but tbh its complicated and may not be compatible with your game but worth a look (Im limited in this area).
why can’t we just tell exploiters to not exploit 
a friend of mine dropped this suggestion:
this will still kill people that have long ping spikes but tbh at that point it’s just kind of their fault
irrelevant edit:
WHAT is THIS GUY TYPING
he’s been typing for like 15 MINUTES 
for more complex or larger games you will have a finite state machine, which may or may not require a ‘sprinting’ state.
the server and the client state machines synchronize their states, and with this you make any sprint logic for the server and client.
Speed change, animations and visuals should always be done in the client for immediate feedback.
Even the Roblox templates don’t use remote events for sprinting neither dashing, double jump, high jump or any fancy velocity/speed usages. The newest template “Platformer” doesn’t and the upcoming ones never will. They care mostly for parameter sanity checks which could clog the server if not treated properly.
The front-page games which have a running feature lack server delay, hinting that their run/sprint system is also client-side.
The client has nearly absolute ownership over physics. Anti exploits or sanity checks for walk speed doesn’t seem worth it. And would only increase complexity if you have stack based buffs that affect walk speed.
Make use of state machines for whatever logic needed on the server.
For this type of situation the remote event should be an unreliable remote event that only take the responsibility of replicating sound and visual effects and perhaps other custom logic that vary depending on the game.
Sorry for taking long to reply. I want to make sure the information I provide can guide you and other readers.
Terrible idea, don’t do this unless you want your players to get constantly mad at you
Everything that can be modified by the client should be done on the client (cheaters can change their walk speed, why bothering making the sprint script on the server)
