If it is impossible for other (non-wolf) roles to have killed at night,
we do not deduct from the traitor count. This logic isn't perfect yet,
but should cover the majority of cases.
Don't start a new timer every time someone calls !latency, and make it
work even if automatic pinging is disabled. Also, moved the command to
handler.py per @Vgr255's suggestion.
In some cases, disconnection from the server can be unclean and won't be
noticed until the bot tries to send a message, which may never happen if
it did not disconnect during the game. To solve this problem, it will
now ping the server every 2 minutes by default, which will result in
a broken pipe error if the connection is dead. This won't be able to
detect netsplits where the server the bot is on stays online, because
those are impossible to correctly detect in every case.
This commit also adds a !latency command so that users can verify if the
bot is lagging.
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.
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.
Since we have the UUID now, we can delete them at any time if needed,
they don't have to expire automatically, which can be annoying when
trying to look up an old error (although it's also in errors.log).
* RULES is now not defined in settings.py, only in botconfig.py.
* If there are no rules specified, a default message is shown
instructing users to configure it.
* The "#CHANNEL channel rules: " prefix is now automatically prepended
(skipped if the string already contains that,
for backwards-compatibility).
* The prefix and the no-rules message can be customized
as they are in messages.py now.
The old link was outdated anyway, and other networks may not use the same rules as freenode, so it should be just configured in botconfig.py like it always could.
We don't use it, as the only places where we'd need to, it's only one channel, and the surrounding code needs to add the user to the channel and vice-versa, so that's pretty pointless.
In join phase, var.PLAYERS is empty, so var.ALL_PLAYERS needs to be
checked instead.
(While I'm at it, changed it to <= 9 rather than < 10, just for
consistency with the rest of the code.)
Fixes#263.
Also adjust revealing totem so that it always fires after mayor, in case
someone has both. Before it would depend on the order the files were
imported, which could lead to oddities down the road.
This fixes#256
This also does some more bits of rudimentary user handling, but most of it still remains to be done.
Note: This adds DEV_PREFIX to botconfig and LOG_PREFIX to settings (var), make sure to properly update your bot!
If the channel is being deleted, we don't need to care about the state. Furthermore, if the channel is being deleted as Python is shutting down, _States will have been deleted (or set to None), so we can't access it. Rather than trying to work around the garbage collection, we just set it to None and call it a day.
Now, local variables from the innermost frame (i.e. where the error was raised) are printed with the traceback, and the latter includes all of the call stack (instead of just up to the innermost error handler).
