Every IRC network is different. Some have different flood tolerances than others. But I've often found it's a good idea to find this limit out early on, and I think that allowing up to 2 or 3 PRIVMSGs per second is probably a good start in certain situations where a lot of output is being pushed into the queue. This might help in situations such as a battle where we have a LOT going on, and not enough output to keep the feed in real "enough" time. I think there could be a certain level where we trip a condition and cause a "Burst" to flush the queue into IRC quickly.
Of course this varies from network to network. For example networks like Freenode are strict; you may want to turn this kind of bursting off there. Snoonet is less strict in that respect, and smaller, more community centric networks often are.
If this is an upstream thing for Kurea, let me know, I'll retry there...but I hope this can be looked into.
Every IRC network is different. Some have different flood tolerances than others. But I've often found it's a good idea to find this limit out early on, and I think that allowing up to 2 or 3 PRIVMSGs per second is probably a good start in certain situations where a lot of output is being pushed into the queue. This might help in situations such as a battle where we have a LOT going on, and not enough output to keep the feed in real "enough" time. I think there could be a certain level where we trip a condition and cause a "Burst" to flush the queue into IRC quickly.
Of course this varies from network to network. For example networks like Freenode are strict; you may want to turn this kind of bursting off there. Snoonet is less strict in that respect, and smaller, more community centric networks often are.
If this is an upstream thing for Kurea, let me know, I'll retry there...but I hope this can be looked into.