search

WritheM / GS-Broadcast-Bot

Create or takeover a broadcast with this bot, then enjoy what the bot can offer!
MIT License
4 stars 4 forks source link

output the last contest winner again... just in case #10

Open pironic opened 10 years ago

pironic commented 10 years ago

If the bot talks too much then it gets flood blocked. If the contest winner announcement gets blocked... revolt.

If we log the message to console, then the admin could theoretically find it again. or If no contest was running, we could say the winner of the last contest when an admin typed /ballot.

Reanmachine commented 10 years ago

Curious, could we not find out what the chat flood protection is and gate the outbound messages in queue to make sure the bot never floods?

pironic commented 10 years ago

The problem with this is that we have asynchronous commands and queries running. The bigger problem is that the real time server is what is blocking the command from being sent... Not the front end. Which makes me wonder about the possibility that is because we host so many broadcasts from the same external ip... The real time server sees multiple clients and blocks the most recent one. Even if we queue it perfectly, no gaurantee it gets through.

Further testing /confirmation from GS would be needed. Maybe I'll talk to Brian about it when I'm back from holidays. On 2 Oct 2014 12:37, "Reanmachine" notifications@github.com wrote:

Curious, could we not find out what the chat flood protection is and gate the outbound messages in queue to make sure the bot never floods?

— Reply to this email directly or view it on GitHub https://github.com/WritheM/GS-Broadcast-Bot/issues/10#issuecomment-57675133 .