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)
