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
similar to a hybrid of the random facts (but defined more simply) and
the dice rolling (but not picking from dice), this allows for definition
of "choice sets" (only in the admin for the moment) and then getting a
random pull from that set (only in the web interface for the moment)
Markov tweaks: new sentence generator, new import
This changes the way that sentences are generated, to ideally be a bit faster than usual, and also adds another import method that just adds text, rather than assuming IRC logs.
See merge request !9
when assigning a new user for review/acceptance, use their real name in
the message, not their username (the reassign will include their
username a split second later anyway)
the theory here is that counting the number of sentences generated is
kind of silly, if we're already specifying min/max word counts, we
probably just want to fall into that range, and not really care how many
sentences we get
meanwhile, we were overloading max_sentences to also calculate how long
any one sentence must be, which is kind of a weird thing to derive, so
we're going to drop the max_sentences language and call this more what
it is, a bias towards the number of sentences that might be seen
This reverts commit 464727cc74.
it turns out that without the min_words_per_sentence adjustment, the
default min_words (15) is way too demanding on a lot of chains, so we're
going to go back to this for the moment
