Spectators Deafening about silence-among-us

[douglasmonsky]

Okay, so a few further thoughts on this after using the bot tonight (beyond the current fix). I see you fixed that it only mutes instead of deafens which is a step in the right direction. However, forgive me if I'm misreading but, it appears the bot is checking to mute spectators on the phase switch to both the working phase and meeting phase. At least I'm assuming that via what I see here

setForWorking() and setForMeeting()

This problem I ran into with this is that if the bot needs to send this signal it is wasting x (x=number of unmuted spectators) of the 10 command bandwidth available on handling spectators. This was resulting in individuals being unmuted/undeafened late at the start of a meeting (especially if a moderator was unmuting spectators during the dead talk).

Potential Solutions:

1. Only check for spectators at the start and end of the game instead of on every phase shift.
2. Ensure commands involving spectators are the lowest priority to be muted/unmuted.
   3.Allow configuration of how the bot interacts with the spectators (It sounded like you already agree with this, just adding it here for completeness).

I hope that I'm being helpful rather than annoying, please let me know if it is the later at all!

[douglasmonsky]

Ideally, this would be configurable with options be do nothing to spectators, and muting at the start of round/unmuting end of the round. As in a responsible group, it's nice to let spectators talk to the dead chat.

[jftanner]

Them being deafened is definitely a bug. I'll fix that.

Be useful to be configurable too. That should be easy enough to change now that I've made the architecture for other things.

[Tanndev-CI]

This issue is resolved in version 2.6.2

[jftanner]

The editGuildMember function is idempotent. If the user already has the correct settings, then it won't make an API call at all. So, spectators shouldn't consume any calls during the game.

However, that won't be true if they've been manually unmuted. (Since the bot will re-mute them.)

I think what I'm going to do is two-fold:

• Make it configurable. (I'm thinking mute, ignore dead for settings, with a warning that the last option will impact performance.)
• Add a voice announcement when meetings start, specifically to interrupt any game-related conversations between spectators.