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.
|
|
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. |
|
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. |
|
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. |
|
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. |