Now - Let me preface this with I’m not that in touch with mSL or mirc in general. I’ve always used custom solutions. However - Maybe a change in your logic will help your cause. mSL is a internal scripting language if I’m not mistaken but has access to low level things like sockets and a like.
I’ve dealt with things like this in the past and there are several solutions, some ‘heavier’ than others.
You could have something like this (how to implement it is on you, but I’m just trying to give you ways of THINKING of a solution).
I’ll throw down a few ways to do this just off the top of my head.
Option 1
- Create a global timer that resets a count of activated commands during the last 30 seconds.
- Provide yourself a buffer to administrative system commands every 30 seconds (arguments sake 20 triggers)
- Once the global count reaches the limit, in this case 80, it does one of two things.
1 - it logs the commands trigger and waits for the global timer to elapse and processes them within the next iteration (probably not wise and would just create a bigger problem because of backlogged commands)
2 - It swallows the command. I.e doesn’t execute it. Effectively ignoring the user. You can prompt them with one of your administrative commands should you wish to.
Option 2
-
While still using the buffered global timer tracking in the above option, you can attach a timer to each individual user that limits their interaction with the bot completely. While this timer is active, no commands can be issued or triggered by the affected user.
-
Same implementation as above, either swallow or process commands at a later time.
Option 3
This is basically a more advanced version of the above two
Contact the api with mirc sockets and get the amount of chatters you have in your chat. Do some math and figure out how many commands can be executed by each of them, per 30 seconds before you hit the gate.
Still using individual timers and counters, assign each user with a limit count of command that can be executed over the timespan and track them. Limiting their exposure to the bot if they go over, keeping track of the ‘global count’ and limiting ALL interaction if that’s the case.
The final option is probably closer to the one you have however by my understand of how you wrote it, probably slightly different.
It’s a combination of all the above, minus the limitation based on timespan.
Option 4
- Global timer tracking all triggers
- Attach individual timers to the COMMANDS not the user and not re invoking the global timer
- Get the command to collect the usernames of the people that requested the command
- Store that information until the timer attached to the command elapses
- Then process the command for everybody that called it in one trigger. Then just building the string that gets returned to the chat with each iteration. (recursive or loop, both would work - not sure if mirc has looping functions though, but if it has goto labels you can work around it and create your own)
- If the global count hits its breakpoint, swallow the rest of the commands until the next iteration.
That way you can only commit one trigger but cover x amount of people.
The last option is a bit more complicated to implement I guess, however I’m not sure how it’ll work in msl but I’m sure it’s possible. mSL has sockets, file i/o and probably some custom libraries on the net for xml/json stuff like that. But as long as you have sockets and i/o. You’re set. I know it has timers and it has aliases ie. methods so you can do these things.
Now all you need to do is figure out how to implement it programmatically with you language.
Research each stage online - google is your friend.
Go over the mirc reference library - also you friend albeit a bit confusing at times.
Test and iterate until you find something that works.
Just remember as long as you have timers, methods and file i/o (or variables that can be appended somehow) this can be done. All options can be done, as to how to achieve them. I’m unsure don’t use merc, but I’m just more trying to show you how to iteratively think about problems and usually the simplest answer is always the best and honestly, i find the last option to be relatively simple to implement.
However I will say this - On some research about mirc, if your channel even gets to a midrange level - 500+ concurrents or chatters, then it seems the mirc has issues with performance and as such so will your bot. Perhaps diving into something that looks more daunting but you will thank yourself in the end. C# or java are both good starting options for programmers and once you get your head around it, your bot will be a LOT better off for it. Plus you won’t be limited by anything but your imagination.
Wall of text over.
Hope this helps. Bed time