Spectators do not mute during discussion

[douglasmonsky]

When playing with spectators in the lobby they do not get muted during the discussion, this causes them to have to be careful about saying anything about the game even during "Working Phase" as they can end up in the discussion on accident.

[jftanner]

Yes, this is a recent change. The bot now ignores spectators entirely. I did that because I was seeing pretty severe rate-limiting issues in full lobbies with spectators.

I plan to make this a configurable setting but, for now, spectators need to either be careful or keep themselves muted.

[douglasmonsky]

Ok thanks, sorry I did not realize this was intentional!

[jftanner]

No worries!

This is a good chance for user research actually.
Which behavior would you personally prefer:

• Spectators are ignored entirely
• Spectators are always muted.
• Spectators are muted after the game starts, and aren't unmuted until some time after it ends

[douglasmonsky]

So, of the options listed my personal order of preference would be the following:

1. Spectators are muted after the game starts, and aren't unmuted until some time after it ends.
2. Spectators are always muted.
3. Spectators are ignored entirely.

However, in an ideal world (if it wasn't an implementation issue because of rate-limiting) spectators would be treated the same as a dead member of the crew (muted during the discussion, but open mike during working and intermission phases).

I guess my follow-up would be is the rate limit tight to 10 or could it handle say, 2-5 extra people?

Why I ask is maybe you can have a few slots to register "participant spectators" that work as described (as permanent dead), and non-registered spectators go with option 1 or 2 (configurable to admin liking is ideal but, maybe not worth the effort?).

Obviously, just my suggestion, and I hope it doesn't come across as demanding a feature or anything. I'm very grateful for the high-quality work done here already! I'm sure there are logistics I don't have knowledge of that could make this not work.

I've been running the bot something like 5-6 hours a night over the last couple of days and would be more than happy to answer any other user experience questions you have/ give more feedback if it interests you, just let me know.

[jftanner]

The rate limit is dynamic and can vary. But it's at most 10 requests per couple seconds. And the more requests you make, the longer the reset time is. So we can fairly reliably handle a full lobby, but an 11th person means that someone doesn't get transitioned for several seconds. There's zero wiggle room for an extra. :(

Currently, the bot prioritizes preventing cross-talk between living and dead players. So when a meeting starts, all the dead people are muted first. Once those have been processed, all the living players are then undeafened/unmuted. So the problem with spectators-as-dead-people, then, is that it will always be a living player that hits the rate limit at the start of a meeting. This proved to be really unpleasant when the rate limit reset reached 5+ seconds, and is what prompted the code change. After a meeting isn't so bad, since it goes in reverse order and it's a dead/spectating player that is limited.

I know different players will have different preferences, so I definitely want to make it configurable. But I think I agree with your order-of-preference. I'll implement it that way in the next version.

I'm glad you're enjoying the bot so far! It's really gratifying to see so many people using it, and the feedback (both positive and negative) is really appreciated!

[jftanner]

The beta version now mutes spectators during the entire match, but not during intermission. Feel free to try that version if you like. (Link for the hosted version is in the README.)

I need to do a bit more linking about how to set up the configuration options, but that's a near-term goal.

[douglasmonsky]

Thanks, I will have to check that out! As for other feedback/suggestions, this is what comes to mind:

1. Unless I'm missing a command there is currently no way for someone else to link a user to their ingame name, they must do it themselves (essentially you can eject others but not add). For the most part, this is a non-issue but, when a new person joins mid-session that hasn't played before I've found it can slow the momentum of the session trying to get everyone to be quiet to explain what they need to do.

2. People should probably be auto ejected when they leave the voice channel (or maybe after being gone for say 5 mins). Even when telling people pretty much no one actually leaves to the session via the bot, they just leave.

3. I'm not sure how openly available the among us capture information is from a logistics perspective but, it would pretty cool when you do the !show-me command it was tracking things such as times imposter, times crew, crew wins, imposter wins, times ejected, time played, etc. Bonus points if you can ping other people to see their stats. Also, it would be nice if you could then create a discord leaderboard with this data. I know this is probably outside the scope of the project though, just thinking out loud.

4. If you change the prefix config the instructions on how to join the game still say "!sau join " even if this is no longer correct.

5. Over 50% of the people I've told to follow the join games instructions described in item 4, people ask if they need to leave the <> brackets. Perhaps just a note right below not to include those or something. I know this is incredibly standard, but it does not seem to translate well to a layman in my experience thus far at least.

[jftanner]

there is currently no way for someone else to link a user to their ingame name, they must do it themselves

This is correct at the moment. I'm considering ways of handling this, but there are some data privacy concerns. Essentially, that would require having one user add another user's data into the database. Maybe not a problem, but it's enough of a grey area that I want to be careful about it.

People should probably be auto ejected when they leave the voice channel

I don't auto-eject because players sometimes want to hop into another channel to talk to friends, or they get disconnected, etc. But I like the idea of a timeout. That's worth considering as well.

In any case, I definitely need to set it up so that they're removed if they leave the voice channel and disconnect from the game. (Obviously this only works for automated lobbies.)

I've opened an issue to think about this more.

[...] leaderboard [...]

This is absolutely something I want to do! I'm working with the AmongUsCapture guys to get the data needed to make that happen, but I'm pretty excited for the possibilities. No issue yet, but keep an eye on the release notes.

The instructions on how to join the game still say "!sau join "

Definitely a bug!

People ask if they need to leave the <> brackets.

I've found this as well. :(

[douglasmonsky]

I'm considering ways of handling this, but there are some data privacy concerns.

Totally understandable, I'm just gonna toss out some ideas that might help with this issue.

1. When a player is entered into the database by another user the data will be deleted at the end of the session and/or when they leave.

2. Bot sends the user a PM asking for permission to add to the database.

3. Bot adds them without asking first but sends the user a PM asking if they would like to be removed and/or giving them instructions on how with the forget-me command.

4. Only users with a special server role can add other users to the database.

5. Only users already in the database can be added to the game by other users. This obviously doesn't help with my original scenario, but could at least be nice for helping a struggling returning user.

6. Some combination of the 1-5.

I definitely need to set it up so that they're removed if they leave the voice channel and disconnect from the game.

This sounds like a really good idea! You may still want to couple this with a timeout (say 1 minute) for when someone's internet disconnects briefly. However, it might be enough of an edge case to say just have them rejoin if they DC.

I'm working with the AmongUsCapture guys to get the data needed to make that happen

Awesome, I love stuff like this and think there's a lot of potential here. Would be really awesome if there was an endpoint to call for people to present their server data in whatever way they would like, though I can see you considering that a data privacy issue.

A few closing thoughts:

1. I've seen rumors of max lobby size being expanded to 15, so you may want to at least start to mull over ways to get around the rate-limiting issue we talked about before if you plan to support full lobbies when/ if that feature drops. Understandable if nothing you can do just wanted to bring the possibility to your attention.

2. This is probably a better question for the guys over at AmongUsCapture (I'm assuming this is the component that stops your bot from working with the beta) but, do you know if there is a plan to support the beta client? I often find people wanting to try out the new features and sad to hear of the incompatibility as they love your bot!

[jftanner]

When a player is entered into the database by another user the data will be deleted at the end of the session and/or when they leave.

Ooooh, I like that.

Would be really awesome if there was an endpoint to call

Oh, absolutely! I'm an API-first developer. Primary authentication will be Discord OAuth, but data should be available in an easily-convertible format.

I've seen rumors of max lobby size being expanded to 15

Fffffffffu.... Thanks for the heads up.

do you know if there is a plan to support the beta client?

If you'd asked me yesterday, I'd have said "no, they are not planning to support the beta client."
But I think they might be changing their minds on that. It might be a supporter-only feature, though. I'll let you know if I get a definitive answer on that.

Update: Nope. No official plans. :'(

they love your bot!

<3