it was futzing up some /admin/ login stuff, and I hadn't actually used
the three views using it in years, so probably better to just yeet it
(technical term) into the sun.
Signed-off-by: Brian S. Stephan <bss@incorporeal.org>
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>
markov targets are queried and autogenerated based on chatter, but had a
legacy name which is no longer in use for this, preferring the foreign
keys to channel and consequently server. the name is really just
informative these days, but was still being used to find targets, and
thus was breaking when two servers had the same channel name in them.
this fixes that
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 necessary for supporting multiple irc servers in one bot config.
this also has the side effect of requiring some code in ircbot and
markov which autocreates channels to also include the server (retrieved
via the connection). this will again help keep channels coherent for
multi-server arrangements
the twitter bot change here is untested but seems like the right idea (I
haven't used the twitter package in forever)
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
the porting is complete, everything i care about has been moved to the
django-based codebase, and this old junk can finally go
IT IS A NEW ERA, one of maintainability and flexible changes. after
years of procrastinating, i have finally done this. the future is now
