zigdon
Support "someone kicked ____" factoids
In addition to the currently supported $nick kicked $user and $nick kicked someone triggers, users on my instance have proposed use cases for someone kicked $user and someone kicked someone.
As an extension to the existing "kicked" triggers, the resolution hierarchy would go from most to least specific in this order:
$nick kicked $user(most specific)$nick kicked someonesomeone kicked $usersomeone kicked someone(least specific)
Doing it this way essentially adds the new functionality in such a way that the existing kick factoid types are preferred over the new types.
Per @zigdon below, the implementation must also look up the new kick triggers only if a related config flag is enabled.
We used to have support for that, and decided it was too spammy (especially that last one). If we going to restore it, it should be guarded in a config flag.
On Sun, Mar 19, 2017, 20:44 dgw [email protected] wrote:
In addition to the currently supported $nick kicked $user and $nick kicked someone triggers, users on my instance have proposed use cases for someone kicked $nick and someone kicked someone.
As an extension to the existing "kicked" triggers, the resolution hierarchy would go from most to least specific in this order:
- $nick kicked $nick (most specific)
- $nick kicked someone
- someone kicked $nick
- someone kicked someone (least specific)
Doing it this way essentially adds the new functionality in such a way that the existing kick factoid types are preferred over the new types.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/zigdon/xkcd-Bucket/issues/98, or mute the thread https://github.com/notifications/unsubscribe-auth/AACtVHUBrW4xEe18lzq6L3SD0ohbHWahks5rnfYRgaJpZM4MiATu .
@zigdon Would you prefer the default to be on or off? I'd lean toward making the default the current behavior, but only because I wouldn't want to suddenly switch it on for existing instances. Ideally I'd like the default to be enabled for new installs, and disabled for existing…not sure if that's possible with Bucket's current config (IIRC it has no awareness of whether it's been upgraded or created fresh).
I'd say if it's a plugin, we can have it off by default, and have it added to the sample config, so that new installs will have it on.
This just came up in one of my Bucket-serviced channels, so… I guess it's time to put it officially on my plate.