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.
