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
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)
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
this puts additional pressure on the sentence generator, retrying many
times to get something that's long but not too long. only testing on a
small context so far, so this is certainly not yet ready to go live, but
the results are pretty good so far
this tunes things a bit in the sentence generator, trying to favor
complete sentences over the min/max word counts, which are still kinda
heeded but not as militantly. this *should* create more interesting
chains, especially with topics, without really breaking things, but this
certainly needs some testing before we can see if it's actually right
bot was overzealous in logging the approval reset message when seeing
pushes. this commit should keep it from logging the message if a push
happened but there weren't actually any approvals yet (so there's
nothing to reset)
still waiting on testing, but this seems like a decent fix to me
bss/dr.botzo#4
Brian S. Stephan