when the bot has received a message through the discord bridge that
it'll end up reacting to (by creating a countdown item, for instance),
the nick in the event should, for all intents and purposes, be the
sender's nick on the discord side, not the discord bridge itself
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
this is probably from python 2 days; we inherited from
SimpleXMLRPCRequestHandler to change the logging, but the method
overrode no longer exists so this did nothing
thinko on my part, this was making the regex for matching all nicks to
'|nick' when the field is '', because of split producing ['']. in
particular this was making markov trigger on every line
^C^B isn't allowed through Discord's API, and I'm sure some other stuff
like colors that I don't use. this makes it a server option to replace
them with Markdown, though I think this would only ever be interesting
for BitlBee + Discord
this is the first step in trying to get the bot to support multiple
servers with different channels, countdown triggers, and so on
this also ends up affecting some configuration around:
* dispatch
* markov
* admin privmsg form
- 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
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
