First of all, this is not a script, but an idea.
Kinda not sure in what category to post that in, so I decided to post here.
Create a datastore named RemoteEventHandler (or any other name)
In the datastore, store 4 values: the Player who fired the event, delay time(can be gotten by os.time(), delay time that's needed for the RemoteEvent, and RemoteEvent's name.
Create another datastore that saves the specific RemoteEvent’s name and its’ purpose.
Second, every single-firing(one-time use) RemoteEvent should be created by the server using Instance.new() function. That RemoteEvent should have a random name, see this webpage for an example function.
Third, for a multiple-time use, change the RemoteEvent’s name using the random string generator above.
I’ll explain the RemoteEventHandler's datastore’s purpose(see 2nd item above):
It stores the player who fired the event in order to kick him if he fired it a plenty of times.
It stores the delay time(in example, 1 second), and if an event is getting fired every half a second, it kicks the player.
Pretty much self-explanatory, see above.
We would have to store the RemoteEvent’s name in order to access it, and manipulate it however we want.
I know it’s hard to secure all of your events(assuming you have >20), but if you don’t want “professional” exploiters ruining your game, feel free to try the idea.
If you have any thoughts, list them below. Thanks!
The best way to use remotes securely is to simply do server-side checks whenever an event is fired.
Firstly, you should have a player unique debounce to avoid remote spamming, this reduces the amount of calculations needed to be done each attempted fire.
Secondly, the checks don’t need to be anything special. You just have to make the checks specifically for whatever purpose that remote has. (Example: Check to make sure the player actually has enough money to buy something and don’t let the player control the output with the input.)
Also, you should not be using DataStores for this. DataStores are for long-term data storage. There’s also both a data limit and request limit that can easily be reached if handled improperly.
If you still wish to use a more complicated system, you should be using tables instead.
I assume that the table is stored in a server script, not in a localscript.
Wouldn’t it be too much of information in a single table, or, too much tables in a single script?
By too much I mean that there’s gonna be a server lag when firing an event(for example you wait 10 seconds to buy an item)
Firing a remote wouldn’t create lag in of itself. The lag would be caused by how complex of an operation you give the server to do each time the remote is fired. Adding a debounce would allow you to control the request rate.
The table would of course be handled by the same script handling remotes. There is no such thing as too big of a table, however if you don’t make it easy for a script to navigate, it can take time to iterate through.
Instead of this system, I would recommend adding a rate limit and a simple server-check as explained prior.