I’m working on a Twitch chat bot using mIRC and I have this command setup:
on *:text:!balance:#:{
msg # $nick currently has $readini(UserData.ini,$+(#,.,$nick),Balance) coins available.
}
The problem is when multiple viewers use the command at once, it creates spam in the chat. I want to implement a cooldown system that collects all requests within a 10 second window, then sends one combined message showing everyone’s balances who requested it during that period.
What’s the best approach to batch these requests together instead of responding to each one individually? I’m thinking about using a timer but not sure how to store multiple usernames and combine the output properly.
honestly the simplest way ive found is just using a text file to queue the requests. when someone uses !balance, append their nick to a file like pending.txt instead of responding right away. then have a timer check every 10 secs if the file exists and has content. if it does, read all the nicks, build your combined msg, send it, then delete the file. way less complex than hash tables and variables imo
What I ended up doing was implementing a dual-timer system that solved both the batching and potential memory issues. I use one repeating timer that runs every 10 seconds to process any queued requests, and a separate single-shot timer that gets reset each time a new request comes in. The trick is storing the data in INI format alongside your existing UserData.ini file - create a temporary section called ‘PendingBalance’ and write each nick as a key when they request their balance. When the processing timer fires, it reads the entire PendingBalance section, builds the combined message by looking up each stored nick’s actual balance, sends the result, then deletes that whole section from the INI. This approach gave me the reliability of file-based storage without needing separate text files, and since you’re already using INI files for user data, it integrates cleanly with your existing code structure.
I’ve dealt with similar flooding issues in my own bot setup. The key is to use a global variable to store pending requests and a timer to process them in batches. When someone triggers the balance command, instead of responding immediately, add their nick to a variable like %balance_queue and start a 10-second timer if it’s not already running. When the timer fires, loop through all the stored nicks, grab their balances, format everything into one message, then clear the queue. Something like set %balance_queue $addtok(%balance_queue,$nick,32) to build your user list, then use $gettok in a while loop to process each nick when the timer executes. Make sure to unset the variable after sending the combined message to avoid memory buildup.
Another approach that worked well for me is using hash tables instead of global variables since they’re more efficient for this type of data handling. Create a hash table when the first request comes in, then use hadd to store each requesting nick with their timestamp. Set up your timer to trigger every 10 seconds and check if there are any pending requests in the hash table. When processing, you can iterate through the hash table entries using $hget to build your combined response message. The advantage here is that hash tables automatically handle duplicate nicks if someone spams the command, and you get better memory management. Don’t forget to use hfree to clear the hash table after sending the batched response, otherwise you’ll have memory leaks over time. This method scales better when you have hundreds of viewers using commands simultaneously.
I ran into this exact issue about two years ago and ended up going with a different route than what’s been suggested. Instead of collecting usernames in variables or files, I used the timer name itself to track state and stored everything in the timer’s data parameter. When the first !balance hits, I start a timer called ‘balance_batch’ and store the requesting nick in a custom identifier. Each subsequent request within that 10 second window just appends to the same identifier. The beauty of this approach is that mIRC automatically handles the timing mechanism, and you don’t need separate cleanup routines since the timer data gets cleared when it fires. I also added a simple check to prevent the same nick from being added multiple times during the window, which cuts down on redundant output. Performance wise this method handled peak usage during raids without any noticeable lag, and the code stays relatively compact compared to managing external files or hash tables.