dgw/sopel-bombbot

Customized version of a custom version of a bomb module for Sopel

sopel-bombbot's Issues

Rewrite to use something better than tuples

Tired of messing with tuples everywhere when working on things like #6. Should just use dicts or something.

Refactor to use objects

Lots of things would look nicer as objects. Maybe even the whole bot could be an object like UnoBot is… but at least the players and bombs should be.

More intelligent kick privilege detection

Detecting whether the bot can kick or not by checking its channel access level is "good enough", but it doesn't cover all cases. Some networks have systems in place for granting access to KICK without granting access (e.g. Rizon's FLAGS access system). It would be great if the module could detect this, rather than simply refusing to kick if it doesn't have channel operator status.

As discussed in dgw/sopel-duel#44 there is an IRC numeric reply (482 ERR_CHANOPRIVSNEEDED) that could be caught to help with this detection, but implementing a trial-and-error system in which the bot tries to kick, and then falls back to not kicking if it's not allowed to, might be hard within the Sopel framework.

Display of rankings

Users in the main channels my bot is in are accustomed to a mIRC script that had a !rank bomb function to show the top 10 bomb defusers. There should be some way to implement that in this version of bomb as well.

Bot admins can bypass the timer

When switching from the built-in rate limiting (@rate(600) decorator) to the custom implementation, the exemption for admins was left in the code. It should be removed.

Move cool-down value to bot config

Current hard-coded value is annoying to customize because it makes updating the module harder (have to save old value, then edit the code again).

Make .bombcancel arg optional when appropriate

e.g. .bombcancel should not need an argument if the person calling it recently planted a bomb.

Move FUSE and TIMEOUT from code to config settings

I was recently reminded that it's high time the FUSE and TIMEOUT "constants" (Note: Python doesn't actually have constants) were converted to proper config settings. It's 2017—Sopel has had a decent config system for several releases now, and it should be used!

Kicking is on by default?

If no chanop explicitly sets the option, kicking will be on by default. This doesn't really make sense to me. Granted, the mIRC script I was replacing always tried to kick no matter what (it assumed it had the ability to do so, without checking), but this module does so much more than that.

Probably makes sense to change the default setting, so even if the bot is given op for unrelated reasons it won't kick users unexpectedly as a result of .bomb games.

Use trigger.time (if available) for rate-limiting

Added in sopel 6.2.1, so obviously depends on #8 (which is coming, now that my bot's running 6.x).

Using trigger.time means rate-limiting will use the value of server-time if available. No real change, but should make the rate limit more accurate (not that anyone ever complains about it being off by a second or two).

Review who can change module's per-channel settings

At least one channel owner requested that chanops be allowed to enable/disable bomb kicks. Some thought is required before making this change.

Admin+ was chosen as a minimum for .bombkickon/.bombkickoff to be consistent with who can enable/disable bombs in general via .bombson/.bombsoff. It's worth carefully considering the effects of changes to the minimum access level required to modify these settings, since a lot of the channels my own bot instance runs in give op (+o) status to anyone who's part of the group that runs the channel (rather than only granting op to a select few "moderators").

An alternative is to allow bot admins to change some or all of the settings, but that comes with its own risks. Ultimately the top channel leaders (+q and, to a lesser extent, +a) should have the absolute final say in what's enabled, and allowing bot admins to override their preferences feels almost as bad as letting bot admins use the bot's powers to kick people even if they themselves have no access on the channel in question (which Sopel's core adminchannel module explicitly disallows).

One solution is to allow chanops and/or bot admins to change the setting unless it was last modified by a channel admin+… but that gets complicated fast, and requires storing even more cruft in bot.db.

So yes: Definitely needs careful consideration.

Not sure if this should happen before, after, or as part of #14, but for now it's a separate issue because it was specifically requested.

Should probably block on #8 and #19.

Add compatibility with sopel-rep's karma commands

This is a small step beyond just validating nicks against the character set allowed. sopel-rep's karma commands use ++ and -- appended to a nickname. + is not valid in nicks. The issue is deciding whether to bomb nick-- or nick, probably by checking if nick-- is present and falling back to nick if not. (Which means .bomb nick--- would also work to downrep and bomb nick- at once.)

I've proved the idea of simply importing the sopel-rep module's verification function in tests using sopel-duel, so that's probably the way to go. (I might want to rewrite the rep module using proper encapsulation before doing this, though.)

Use willie.formatting.colors for possibilities

Depends on #1

Add method for bomber to cancel their bomb

Let bombers try to remove their bomb from their target's pants, with a chance to blow up the bomber instead, possibly contributing to bomb_wrongs or another stat entirely.

Add 6.x module compatibility

Module needs to import from "sopel" instead of "willie" for 6.x compatibility (the rename that didn't need to happen, happened anyway).

• Change imports from willie to import from sopel
• Try to import sopel packages first and fall back to willie if needed
• Rename repository

Screwing with the imports might be unnecessary if @embolalia pushes a shim to make both willie and sopel imports work with future versions, as is possibly planned. But it's good to have on the radar.

Module doesn't ignore the bot properly

Example:

<dgw> Kaede: literal ;cutwire red
<Kaede> ;cutwire red (=> !cutwire red) (#1138) <reply> <AlexLykos> it's never
        the red wire (#1272) <reply> <Steinr> it's always the red wire
<Kaede> KeyError: u'kaede' (file "/var/lib/willie/modules/bombbot.py",
        line 175, in cutwire)

Not an issue under normal circumstances, but it shouldn't be possible anyway.

Comes down to line 164 (in current master):

        if target.lower() != bot.nick.lower() and target.lower() not in BOMBS:

Intelligently avoid trying to kick anyone with higher privilege

Probably can't be perfect due to different channel modes, ChanServ settings, and so on that change whether certain usermodes can kick at all, can kick people of the same level, and such; but at least try to avoid trying to kick (and thus not saying "nick is dead!") if it's clear we can't kick that person.

Figure out how to block bombing people ignored by host

Splitting this out of #12 because it's not going to happen easily.

Bonus points: Handle bot.config.core.host_blocks also. There doesn't seem to be a way of getting the host of the target easily, only the calling user (via trigger.host), but this is a nice stretch goal.

.bomboff can be tricked out of checking time since last bomb

[23:27:46] <Haruhiro> ;bomboff Haruhiro 
[23:27:46] <Kaede> Marked Haruhiro as unbombable.
[23:27:46] <@dgw> Just ;bomboff
[23:27:50] <@dgw> No nick
[23:28:04] <Haruhiro> ;bombon
[23:28:04] <Kaede> Marked Haruhiro as bombable again.
[23:28:09] <Haruhiro> ;bomboff
[23:28:17] <@dgw> Yappari
[23:28:23] <Haruhiro> -Kaede- You recently planted a bomb, and must remain bombable for
                      351 more seconds.
[23:28:29] <+vil> lol
[23:28:33] <Haruhiro> xd

Convert to entry point plugin and publish on PyPI

Now that the module is updated for Sopel, and Sopel supports third-party modules installable via pip, this one should be published in the repository.

Decision: cookiecutter modules actually reside in the sopel_modules/modname/modname.py file within the git repository. It's probably possible to rewrite the module history to look like it's always been there—and therefore preserve git-blame-ability—but is that worth doing? Probably not. It could mess up Github's Contributions calendar, and would certainly mess up any commit hashes that are referenced in issue/PR histories.

Humanize cooldown time display

Can either steal this code from my AniTV plugin, or push this off a few more months until Sopel 7 is finished (I've been thinking about it for years, after all) and use the upcoming seconds_to_human() utility function. Either is fine, really. The new Sopel tool formats its output in a way that might not be quite what this plugin wants, if I think about it too much.

Shenanigans when bomb explodes while user is out of channel

Scenario

• User A plants a bomb on User B
• User B parts the channel or quits the network before the bomb goes off
• User B is still missing when the bomb explodes

Result

Bomb explosion exits early, before printing the "BOOM" message or (attempting to) kick User B. Future attempts to bomb User B will fail until the bot is restarted or the module is reloaded. (The bot thinks there is already a bomb on User B.)

Expectation

The bomb explodes anyway, and User B's bomb state is cleared.

Take a random subset of available wire colors for each bomb

Probably 3-5 of the possibilities in colors, for variety and guarding against auto-cutwires.

Add '.defuse' alias for .bombcancel

User suggestion from chat.

TypeError in .bomb under Python 3

<~Nala_Alan> .bomb Nezumikyun
<&Katou> TypeError: Population must be a sequence or set.
         For dicts, use list(d). (file "/usr/lib/python3.4/random.py",
         line 309, in sample)

This is happening in Python 3, obviously, so there's probably a cross compatibility issue—it works fine in Python 2.7.

Don't allow bombing another nick in the same DB group

This shouldn't be possible. Deadkuba is in Razkuba's nick group within the bot's DB.

<Deadkuba> ;bomb Razkuba 
<Kaede> Razkuba, I just saw someone put a bomb down your pants! There are 4 wires (Green,
        Blue, Purple and Pink), and I think it's a 2 minute fuse. Quick, tell me what
        wire to cut! (respond with ;cutwire color)
<Deadkuba> ;cutwire purple
<Kaede> You can't cut a wire until someone bombs you, Deadkuba.
<Razkuba> ;cutwire purple
<Kaede> You did it, Razkuba! I'll be honest, I thought you were dead. But nope, you did
        it. You picked the right one. Well done.
<Razkuba> lol

Timeout with "0 seconds" remaining shouldn't be possible

Due to how Python handles floating point numbers when interpolated into strings, the remaining seconds are truncated at the decimal point (not rounded). This can lead to the user being told to wait 0 more seconds before bombing again / performing .bomboff.

Timer code should round the value up to the next integer for display, so even if there's less than a second left it still appears as "1 second".

Track nick changes

Don't let people get the bomb out of their pants just by a simple /nick someone_else

Block bombing anyone who is ignored

The current code allows bombing someone whose attempts to defuse the bomb would be ignored.

Possible fix: Move checks for whether the target nick can be bombed into a function that can handle all the regular expression nonsense in bot.config.core.nick_blocks.

Bonus points: Handle bot.config.core.host_blocks also. There doesn't seem to be a way of getting the host of the target easily, only the calling user (via trigger.host), but this is a nice stretch goal. Punted to separate issue, #13.

Nicks containing | break .bombcancel

Discovered by accident, when I bombed the wrong nickname by mistake (timestamps to show the fuse hadn't expired):

[13:42:44] <dgw> ;bomb Senna|interview
[13:42:46] <Kaede> Senna|interview, I just saw someone put a bomb down your pants! There
                   are 4 wires (Red, White, Black and Orange), and I think it's a 2 minute
                   fuse. Quick, tell me what wire to cut! (respond with ;cutwire color)
[13:42:46] <dgw> fug
[13:42:49] <dgw> ;bombcancel Senna|interview
[13:42:50] <Kaede> dgw: There is no bomb on Senna|interview.

Confirmed the issue in testing:

[13:50:58] <dgw> ;bomb dgw|test
[13:50:58] <Kaede> dgw|test, I just saw someone put a bomb down your pants! There are
                   4 wires (Green, Yellow, White and Pink), and I think it's a 2 minute
                   fuse. Quick, tell me what wire to cut! (respond with ;cutwire color)
[13:51:02] <dgw> ;bombcancel dgw|test
[13:51:03] <Kaede> dgw: There is no bomb on dgw|test.
[13:51:06] <dgw> o rly

Probably something to do with a missing cast to Identifier or forgotten .lower().

Forward compatibility: Use trigger.account if available

Will need to test on an IRCv3-enabled network with the relevant capabilities, but using an account where available will always be easier to deal with than just matching nicks. Would lower dependence on sopel-dgwmergeutils.

;bombstats, probably other commands, do not strip leading/trailing spaces

Notice bomber when not kicking because target is marked unbombable

Bot will refuse to kick a user who is marked as unbombable, but doesn't say anything about it. This can lead to confusion for bot admins (the only people who can still bomb the unbombable right now).

Send a NOTICE to the bomber iff the target would have been kicked but wasn't.

Colorize wire in "You should've picked" output

When the bot says "(You should've picked the ____ wire.)", that wire color should be colorized as it was in the list of possibilities.

May require mucking about with tuples. I forget how this is set up.

Use LIGHT_GREEN and LIGHT_BLUE for readability

The normal BLUE and GREEN are really dark. Find an elegant (of course) way to use the LIGHT_ variants while still displaying "Blue" and "Green".

Automatically .bombon instead of error when unbombable

It's a really common pattern for users (myself included) who have previously done .bomboff to:

• .bomb nick
• get rebuffed by the bot: Try again when you're bombable yourself
• .bombon
• .bomb nick again

Instead of this dance, would it make sense to just automatically perform an internal .bombon if an unbombable user bombs someone else? It would certainly reduce the boilerplate spam in channels where this module is used…

The automatic .bombon can be silent, send a NOTICE to the bomber, or send a public channel message; I'm not really bothered which at the moment. It can also be combined with the NOTICE already sent containing the wire color.

Also thinking about automatically running .bomboff again after the timeout elapses, but that'll be a separate feature if it even happens at all. That might make it too easy to stay unbombable most of the time while still bombing other users at will.

Migrate from using bot.privileges to bot.channels (if available)

Lots of "if available" features these days.

Sopel 6.2.0 deprecated the bot.privileges dict. It was replaced by bot.channels, which contains more state information. Obviously this depends on #8 (but should not block it—see below).

As of 6.3.0 the bot.channels dict doesn't seem to be populated quite correctly, but when it's stabilized and can replace bot.privileges it should be used if available, as the deprecated API will probably disappear in 7.x (or by 8.x at the latest).

Refactor settings commands to take "on" and "off" arguments

Of particular importance are .bombkickon/.bombkickoff and .bombson/.bombsoff. Those are easily replaced by .bombkick [on|off] and .bombing [on|off].

May or may not want to refactor .bombon/.bomboff, as more people use them and the commands would definitely need to be renamed (otherwise .bomb would have to be overloaded and that's just messy).