In 5-player charming games, it is possible to get into a situation where
it's impossible for the village to win - if all players except for the
wolf are charmed, lynching the wolf results in the piper winning, and
lynching the piper results in the wolf winning.
This was originally done so that we wouldn't need to iterate through the (presumably large) set of users. However, when this raises, we have no idea which users actually match the criterias. By waiting until after, the traceback will actually print off the list of all potential users.
This takes a different code path because of slightly different conditions; in the first case, the ident and host are both known, and so the instance is hashable. Being hashable, it can be checked for set containment, and exactly one instance in that set will be equal (since the hash is based off of the ident and host, and the comparisons check for all non-None attributes, two instances cannot possibly be equal while having a different hash).
In the second case (the new one), however, at least the ident or the host is missing, and so the hash cannot be calculated. This means that two instances may compare equal and hash to different values (since only non-None attributes are compared), so we need to run through the entire set no matter what to make sure that one - and only one - instance in that set compares equal with the new one. We can't know in advance whether or not there is an instance that compares equal to the new one in that set, nor can we know if there are multiple instances that are going to compare equal.
The two code paths are separated so that the difference in functionality is obvious (and this commit description, as well as the comment in the code, should help with that), and that the distinction remains clear.
Causing way too many bugs, need to use a more sane method of breaking
the cmd API, and only do so when it's actually ready to go. My
personal preference is to make the new API use @command instead of @cmd.
This reverts commits c90d35e6c0 and 5f5966a8b4.
Whether or not GHOST is used now depends on if NICKSERV_RELEASE_COMMAND
or NICKSERV_REGAIN_COMMAND are empty. Also, we do not try to go into an
infinite loop should the command we use fail to work, and instead just
run with a "wrong" nick.
Not tested at all, so blame ilbelkyr when things inevitably don't work
with it (and while you're blaming him, get him to fix the ASM website).
It was listing the warnings on a bare "!fwarn" because re.split()
returned an array containing one element, the empty string. And it's not
really helpful to show just the syntax for the help subcommand in
"!fwarn help", because it already does that in the normal help message,
and also shows the available subcommands.
20:01:04 <+nyuszika7h> "beaky played Russian roulette, and lost"
20:01:10 <+nyuszika7h> I don't think there should be a comma there
20:01:58 <+nyuszika7h> idk though
20:02:04 <+nyuszika7h> it seems weird, though that's not a list of things
Since lykos is a separate project, removed note about ##werewolf-ops.
Obviously we will provide a way to disable changes not suitable
for ##werewolf. Also told users to PR to master and claried that newest
stable branch is also OK to report issues.
This wasn't working before, because the mode checking was wrong. Furthermore, there may have been some race conditions; this was mitigated by an earlier commit, which allowed delaying some channel handling operations.
Specifically, the mode handling and the end of list modes are delayed until the end of the WHO reply from the server. When the end of the WHO reply is received, all queued operations on the channel, if any, are triggered at once in the form of relevant events.
As part of this, adjust team and accurate stats to no longer hide any
information. For team stats in particular, it was very misleading to
list traitor as villager, because it gives the village the impression
they have more time than they actually do (i.e. 2 wolfteam 5 vilteam
actually means 3 wolfteam 4 vilteam but that is not obvious). As team
stats were changed, team reveal was also changed to disregard hidden
traitor, so that the two can't be correlated to pick out if traitor died
(if traitor was revealed as vilteam but stats decremented wolfteam, that
would guarantee that traitor died).
Also commit groundwork for the stats rewrite, hidden behind an
"experimental" stats type (so it is not on by default). It is still very
WIP, many things do not yet work with it.
