Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rate Limit Effect #7543

Open
1 task done
Nico6231 opened this issue Jan 27, 2025 · 1 comment
Open
1 task done

Rate Limit Effect #7543

Nico6231 opened this issue Jan 27, 2025 · 1 comment
Labels
feature Pull request adding a new feature.

Comments

@Nico6231
Copy link

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.

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.

Image

Image

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.
@Moderocky
Copy link
Member

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.

@sovdeeth sovdeeth added the feature Pull request adding a new feature. label Feb 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Pull request adding a new feature.
Projects
None yet
Development

No branches or pull requests

3 participants