This might me a little confusing, because it calculates the number of players that won (similar to !playerstats) instead of the number of times a team won (like !gamestats). This way it gives the proper winrate of a player playing that role, but gives an inflated number of total victories and games in cases where there are multiples of a role in the same game. Maybe it would be better to hide the actual numbers and show only the winrates in order to avoid confusion.
In !wait, the delay is how long it takes (in seconds) to add one token,
whereas in oyoyo the delay was the opposite (lower = longer refill).
IMO the !wait one makes more sense, so change oyoyo to match.
Changes the "player_joined" message in messages/en.json to a list of 10 unique messages and adds the appropriate code to wolfgame.py so a random message is chosen each time a player joins.
- Split turncoat
- Add `new_role` and `swap_role_state` events, convert some `exchange_roles` listeners to them (handles both exchange as well as roleswaps such as clone->X or traitor->wolf)
- Refactor change_role(). Calling that is all that is needed for a roleswap now (no boilerplate)
- Always give player list to new wolf roles. This does mean they'll get double lists in some cases, dealwithit.jpg
- Make exchange totem no-op due to technical issues until we get role classes set up (exchanging role state across two new_role listeners doesn't work very well when the listeners get rid of old state)
- Majority vote will still select that mode unconditionally
- When there is no majority vote, the game mode is decided in a two-step process:
1. The bot will first try to select a game mode among those voted vs a random gamemode (for the purpose of this, all players who did not vote are considered to have voted for a random gamemode). For example, in an 8 player game if there are 2 votes for foolish, 2 votes for aleatoire, and 1 vote for default, one of `{foolish, foolish, aleatoire, aleatoire, default, random gamemode, random gamemode, random gamemode}` will be chosen (25% foolish, 25% alea, 12.5% default, 37.5% random gamemode)
2. If random gamemode is selected, a random mode is selected according to the base likelihoods. Votes do not modify this anymore
Votes which are for majority-only modes or modes with incorrect player counts are not counted (and treated as votes for a random gamemode instead)
There are now 5 general brackets of game likelihoods:
- default gets 40 because it's default
- game modes which have proven to be popular and which don't modify core gameplay get 10
- game modes which modify core gameplay a small amount or do not modify it but aren't as popular get 5
- game modes which modify core gameplay a lot or should only rarely appear in rotation get 1
- game modes which are not balanced get 0 (joke/fun modes)
Default likelihoods add up to 95, so the likelihood is approximately also the % chance of it showing up without any votes.
Don't error if someone tries to move after having gotten out of a
nightmare. Also use clear instead of del because I thought that it may
have been an issue but it turned out to have been fine but I'm too lazy
to revert it and it doesn't change anything.
- Turns out we use OR elsewhere in expression context (even though it's technically an undocumented behavior), so use it here as well for consistency
- Change indents to match other SQL statement indentation
- Change join condition ordering to put the joined table first (personal nit I enjoy picking)
Also changes prophet from being able to pray twice to only being able to pray once, but they get the third of the player list (instead of half and then one).
