- event.addressed - msg started with 'bot: '
- event.original_msg - the pub/privmsg
- event.addressed_msg - pub/privmsg minus 'bot: '
- event.sender_nick - nick of event.source
- event.sent_location - channel or nick of event.source
- event.in_privmsg - if the event was in a privmsg or not
closesbss/dr.botzo#32
same logic as replacing [subcommand] with the output of subcommand, but
on the outbound side, via {subcommand}. this lets you do something like,
say:
!echo {!facts buh}
and that won't get interpreted until '{!facts buh}' is on its way out of
the bot. thus, you could also put '{!facts buh}' into the output of some
other command, like a countdown reminder
every second (!?) a new thread checks the database for reminder
countdown items that haven't been reminded about yet. when the at time
is reached, the thread sends the reminder and notes that a reminder was
sent
bss/dr.botzo#11
extending countdown items in order to have them also store reminders,
which are the same idea (an event at a time) but these are watched by
the irc bot and sent to the specified destination when the time is
reached
this adds support for configuring this, code in support of it is coming
in later commits
bss/dr.botzo#11
reply() used to require an event, but all it used it for was to
determine the destination and to identify recursion. basically, strictly
only -replies-. we can make this a more robust privmsg, too, by adding
explicit_target and inferring recursion as False. this will let
basically any code currently using privmsg to use reply instead, and
benefit from multi-line and line splitting
bss/dr.botzo#21
this throttles multi-line messages in a way that probably doesn't affect
the normal cases much, and scales fairly well to far longer text. for
some reason long ascii art still triggers the flood detection, but with
this code at least it happens later in the process. so, success, for
now? i can fix the ascii art at some future point if i ever hit it
practically
closesbss/dr.botzo#23
