Details: the IRT "answering service"

Dyno end of AF, not with real text yet The fundamental idea was to auto-reply to anything sent to the public IRT "hallway desk" channel.  I looked at Dyno's "autoresponder" function and that didn't really do the right thing, and the corollary problem was to allow the IRT folks to enable or disable the auto-response themselves at will without having to screw around with external bot control panels.  Once again I looked to YAGPDB's regex-based moderation function, and rather than dump auto-replies back into the channel decided to use its "warn" function to direct-message the user with the response.  So basically, anything not matching the specific enable/disable commands would elicit the auto-response if the auto-answer was in effect.

I didn't have the exact reply text as first, so I put a placeholder into the "warn" message.  It wasn't really a warning in this case, that's just what the moderation function calls it.

working Dyno CC pieces The cute part came here: Dynobot was the piece that actually picked up the enable/disable commands to act on them.  And the magic bit?  Dyno could actually set roles for YAGPDB, to either see or not see that one particular channel in the first place.  I added a new role to gate Yag's access to the desk channel, so when Dyno came along and removed it, Yag would be blind to channel traffic and not spam people with autoresponses -- that was the "desk is open and staffed" state, when humans would answer questions instead.

Here are all the custom commands I'd defined in Dyno by the end of the weekend, including the "portcullis" hack-API handler.  As a semi joke I also had a "suicide" command, with which someone could effectively kick themselves out of the con.  They would have needed to issue that in a channel that Dyno was actively watching, however, and that scope was so limited that there really was no practical way that an ordinary attendee could use it.

  As I worked through this I realized that the "answering machine" switch didn't need to be in-band in the public channel in question.  Rather, it was better to confine that to the *private* IRT and Safety coordination channel, and dump the results and effect back into the public channel.  That way, the public would not see the command invocation at all and be tempted to try it themselves.  Again, a bit of stealth or "authorization" applied to the whole thing, as only Safety/IRT folks had access to their coordination channel in the first place.

Note that once the command source channel got moved, the regular-expression parse on the Yag side was semi-redundant because it no longer had to negative-filter any command invocation.  But I left that as it was, since it was still a valid trigger for anything else sent in.

Grand possibilities open up when one bot is able to affect what another bot does, but we'll see that there are certain limits when describing the "pet quotes" rathole.

describing AF toggle for Safety I reported the final setup back to Safety/IRT, and pinned these instructions into their channel.  Later, I moved the actual Dyno output message to the public channel, so the final setup was -- come to the private channel, use the "open" or "closed" command, and people would see the change in the public one.  It was rather elegant, even if the command syntax was a little klunky only because the Dyno prefix had to match the original "portcullis" setup.  A little obscurity here wasn't a bad thing.

viv gives IRT-AF verbiage update, and it barely fits Later in the con, Vivian gave me some alternate text for the auto-response, but it was just a *little* too long to fit in the automoderator text field!  Some creative shortening let it fit with maybe two characters left over, and it was still acceptable.

_H*   210129