So basically I’ve been testing with a few methods for a long time but long story short I want to use persay a Skill or any Input of the sort check with the server if it’s allowed (Cooldown and Values such as not Stunned etc…) then if it is come back play the animation do effects etc, The thing is the delay for this can usually be around 0.3 seconds or more depending on server lag and I need a animation to play instantly and effects to almost be instant without doing them on the server or without checking all my action values like “stunned, running, attacking, flying” etc… on both the client and server, does anyone know the most efficient way to do this without letting exploiters have free roam?
Note: Remote functions are not viable for this since they first of all are still delayed and second of all you have to pass something such as the Skill you wish to check or something of the sort wich can be altered via MetaMethods.
I want to check my cooldowns and action attribute values once on the server but also fire a animation if those value checks are passed but instantly not client to server to client
Yes but using BIndable Events for each and every client for every single effect is I would say even worse than just going Client to Server to Client, making me think double checking with 2 cooldowns and 2 status checks is the only way?
For my systems i had cooldown in both client and server , if the client cooldown is passed I play animation(the client stuffs) and fire to server which has another cooldown , if the player passes that cooldown too it does the server stuffs.
That’s not how hacking works. They don’t use metamethods. No method of communication is hacker proof, everything is vulnerable when it is on the client.
You can’t communicate between clients without RemoteEvents and RemoteFunctions, so you will need to work around the minimal latency. It should appear just about instant for everyone. 250ms isn’t very long to delay for an animation to trigger, after all. They wouldn’t even know they got hit until that point anyways, it just can’t be fixed without some sort of expensive prediction system.
So it has to be double checked wich I’ve come to realize is the best method since 250 ms delay is absoluely unnaceptable to add on to already laggy players, also I may have said it wrong but yes hackers can intercept the parameters of any RemoteEvent,RemoteFunctions etc before they are even fired to the server meaning using names to check and using that value returned is easily exploitable.
You can try creating a local Animator under the humanoid and replicating animations manually on the server. After that’s implemented, you can try a workflow like this:
Run all the animations/effects locally.
Fire a remote function to the server. If the server returns a “failure” value, revert all the animations/stat changes, and you’re fine otherwise.
On the server, you can replicate animations/effects with remote events if the request succeeds, and otherwise do nothing.
It’s basically rollback for fighting games. Using an event/signal pattern should simplify this approach somewhat.
Right, but my point is that they can intercept anything, not just remotes.
I think Shoop has the best answer. It doesn’t really prevent latency because that’s not possible, but it will save server resources and it’s a fine example of the industry standard client server model.
I’ve been thinking about it and honestly in the end I believe just double checking and firing back for effects is going to be less work and stress on the server and me than something like you were saying, what do you think? How much is it really going to hurt to check all my status values and twice and have a longer fake client cooldown that allows for delay between client and server?>
As long as the client doesn’t have direct control over status effects (that everyone sees) and isn’t lying, then it sounds good.
I would personally work harder for rollback, but I also think it could be easy to get wrong. If you just double check values, I would think it would be worse… I’m imagining both would be implemented the same, except you just ignore the case where the client could be wrong, which would be bad because the client would be lying!