You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rate limiting is a good way to add built in cooldowns/limit pieces of code from being ran and to also prevent abuse with certain code, you can already sort of achieve this effect with variables but it is very tacky and not efficient, an example of this rate limit syntax is shown below:
ratelimit [action limit] [duration]
the action limit just means how many times the effect/piece of code can be fired before being rate limited, the duration is how long the rate limit is.
This example code below cancels the event when the player clicks something, then it plays a sound and sends them a message telling them they cannot click whatever they are clicking, the rate limit kicks in after the first effect fires and lasts for 1 second.
on inventory click:
cancel event
ratelimit [1] [1 second]
play sound "ui.button.click" to player
send "You cannot click this" to player
Here is also another version, where you can add additional code under the rate limit which would fire if the player is currently rate limited while they fire the event.
on inventory click:
cancel event
ratelimit [1] [1 second]
play sound "ui.button.click" to player
send "You cannot click this"
send "you are ratelimited!"
The first video is what it looks like normally without the rate limit feature, you can freely spam messages every click and gets pretty annoying, imagine sounds or even more complex code that can easily be messed with, having rate limits can also make the skript less bug-prone.
The second video shows what it would look like with a rate limit of 1 every 2.5 seconds, it looks clean and is more optimized for the server in most cases, of course this would have more use cases than just messages, but it's just an example. This "ratelimit" effect required multiple more lines and variable checking and modifying which eventually creates a lot of unnecessary and unoptimized code.
Why?
Of course, I'm not a programmer so there may be better ways to implement this effect but I think it would help in a lot of ways, seems to be a lot more simpler and faster than just crappy variable code, most of the reasons why I want this feature added is stated above.
Other
No, thanks for reading and I hope this gets added in the future.
Agreement
I have read the guidelines above and affirm I am following them with this suggestion.
The text was updated successfully, but these errors were encountered:
What you're asking for is a lot more complex and specific to your situation than a simple syntax suggests.
Is this cooldown supposed to be per-event, or per-trigger? Should the cooldown be unique to a player? What about an event that has more than one player involved?
Users might want any or all of these (or something else entirely) and it is difficult to make syntax that works well for any of these combinations because it is so dependent on the user's specific situation.
seems to be a lot more simpler and faster than just crappy variable code
Sadly, this is often not the case. We would be doing it essentially the same way under-the-hood and there wouldn't be a measurable efficiency difference.
Suggestion
Rate limiting is a good way to add built in cooldowns/limit pieces of code from being ran and to also prevent abuse with certain code, you can already sort of achieve this effect with variables but it is very tacky and not efficient, an example of this rate limit syntax is shown below:
ratelimit [action limit] [duration]
the action limit just means how many times the effect/piece of code can be fired before being rate limited, the duration is how long the rate limit is.
This example code below cancels the event when the player clicks something, then it plays a sound and sends them a message telling them they cannot click whatever they are clicking, the rate limit kicks in after the first effect fires and lasts for 1 second.
Here is also another version, where you can add additional code under the rate limit which would fire if the player is currently rate limited while they fire the event.
The first video is what it looks like normally without the rate limit feature, you can freely spam messages every click and gets pretty annoying, imagine sounds or even more complex code that can easily be messed with, having rate limits can also make the skript less bug-prone.
The second video shows what it would look like with a rate limit of 1 every 2.5 seconds, it looks clean and is more optimized for the server in most cases, of course this would have more use cases than just messages, but it's just an example. This "ratelimit" effect required multiple more lines and variable checking and modifying which eventually creates a lot of unnecessary and unoptimized code.
Why?
Of course, I'm not a programmer so there may be better ways to implement this effect but I think it would help in a lot of ways, seems to be a lot more simpler and faster than just crappy variable code, most of the reasons why I want this feature added is stated above.
Other
No, thanks for reading and I hope this gets added in the future.
Agreement
The text was updated successfully, but these errors were encountered: