Use "Cap, " as invocation instead of "!!" for more natural interaction

[Regenhardt]

Since we sometimes talk to cap like she was a real boy anyway, wouldn't it be nice to actually get an answer? In the C# chatroom somebody had the great idea to make the invocation trigger "Cap, " (mind the space after the comma) instead of "!!", so we could ask her things more naturally. Credit goes to NerdInTraining here or (Edit: formerly) on the C# Starboard.

[allquixotic]

I love this idea, but would request to make it a build-time or settings file tunable (either/or) -- without having to edit the source .js or master.js to change it. Other incarnations of the SO-ChatBot that are not Caprica Six should not be addressed in other chatrooms as "Cap," but perhaps as something like (for example the Root Access bot) "Cavil, ".

[Kamilczak020]

I see a little of a problem with this.

Firstly, "!!" is already widely recognized, and changing to something else will surely cause a stir among Cap's users. A possible solution to that would be adding the New invocation on top of, not instead of the old one.

Secondly, while this does look nicer, it is a bitch to type. Remember, people often use chat from mobile. Also, that would cause lots of typos followed by "Omg not again". Simply, annoyance that is uncalled for.

Lastly, how would you plan to solve the case of special command invocation? I mean, I assume these would become: !!s/a/b/ -> Cap, s/a/b !!> code -> Cap, > code

While the second one does look "meh", at least to me.

Tl;dr: I say meh.

[oliversalzburg]

The name problem could easily be solved by making the trigger "Robot slave, ".

[allquixotic]

Eh, I'd want it to be a more generic thing. Read in a JSON array from a file with a list of prefixes that the bot recognizes and let the user/administrator of the bot configure them. The default (and what would happen if you load bookmark.js) would just be to have the array be ['!!'].

For Root Access it'd probably be ['!!', 'Cavil,', 'Bot,'].

Also, feature request: case insensitivity as an option flag.

It'd be unlikely to accidentally trigger with users with names like that because people refer to users with an @, so the message text string would begin with @Bot or @Cavil if they're talking to a person or replying to a message, e.g. from a user named literally "Cavil".

However, I'm also an advocate of (after stripping off the reply ID, if present), if someone starts a message by @'ing the bot's literal name, having it respond. Tab completion of the bot's name is easy on mobile and desktop; @Cha in Root Access brings up @ChatBot John Cavil as an autocomplete option.

Folks who don't know the magic string !! or Bot, could just @ the bot to invoke it. I'm rather surprised that isn't a thing already, but it's getting a little far afield of the original purpose of this issue.

[NoobInTraining]

I think having both !! and Cap, would be great.

Maybe one could implement something like

!!learnAlternitiveCommand REGEX EXPR e.g. !!learnAlternitiveCommand [Cc][Aa][Pp],?\s?

This would enable modification of the command for other botnames aswell.

[rlemon]

fwiw the invocation pattern is already a runtime variable.

adding in functionality to respond to users who @ her has been proposed as well https://github.com/Zirak/SO-ChatBot/issues/65

I just don't see much work needing to be done here unless you want a listener that tries to parse messages with Cap in them.

[Regenhardt]

So if it already is a runtime var - what does it take to change it, and can it be changed for each room individually?

[FreezePhoenix]

@Regenhardt all you must do is run this as javascript in the window the bot is running in: bot.config.pattern = "desiredPattern"

[Regenhardt]

Unfortunately, I'm not the one running Cap. I was told that is rlemon. Any chance you can make both patterns invoke her, @rlemon ? When after some time we realize it's really annoying or something, you can still change it back.

[rlemon]

I don't see any benefit from this, only annoyance. Users need to send the bot well formatted commands or she spits back a generic I don't understand message. The majority of people who ping cap do so with a message thinking she is a user. https://chat.stackoverflow.com/search?q=%40CapricaSix&room=17

for her to respond with "Sorry I don't understand that" to each of those instances would be incredibly annoying to anyone else in the room. silently ignoring pings seems to be the best solution.

If we did roll out an invocation pattern that could be easily triggered by mistake the bot spam would increase and the tolerance for the bot would decrease. I just don't see it working out.

[Regenhardt]

I'm not talking about a ping though, but literally "Cap, ", in the beginning of a message, without an @ in front, including the single whitespace after. That was completely deliberate, as I do know how many people ping her for giggles, I'm one of them. Or do you mean it's not actually possible to filter out the pings? I just tried, and @!! doesn't invoke her either.

[rlemon]

I see, well I guess we could try it, but I still don't see a point. where will we benefit from this?

I still don't get the need. but I'll leave it to Zirak to decide.

On Wed, Mar 28, 2018 at 10:13 AM, Marlon Regenhardt < notifications@github.com> wrote:

I'm not talking about a ping though, but literally "Cap, ", in the beginning of a message, without an @ in front, including the single whitespace after. That was completely deliberate, as I do know how many people ping her for giggles, I'm one of them. Or do you mean it's not actually possible to filter out the pings? I just tried, and @!! doesn't invoke her either.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Zirak/SO-ChatBot/issues/293#issuecomment-376901634, or mute the thread https://github.com/notifications/unsubscribe-auth/ABDo87OvfYnH-hQRgZ7DUCCpwh1_mgnGks5ti5p1gaJpZM4P4CTS .

[Regenhardt]

I think we'll benefit from this by having a more natural invocation. I know it's not a technical improvement, but it sure feels nice to be able to go "Cap, tell Rudi sandbox" and actually have her react. Brings us further in the direction of "talking to your computer".

[FreezePhoenix]

@Regenhardt it would be irrational to move every command to this syntax. What (I think) could be done is to have 2 sets of commands, one being searched if the message starts with "!!", and the other being searched if the message starts with "Cap, ". This would only require 2 dictionaries, and 2 listeners, instead of the 1 dictionary, and 1 command listener.

[rlemon]

The issue isn't moving commands over (not sure what you're even talking about there). It would be trivial to make the bots invocation pattern take multiple listeners. The point is that I think it'll create more problems than it is worth.

We already have people invoking the bot by mistake with the !! invocation pattern. if we made it @Cap or Cap or any variation of that I can only see it adding to that noise.

I enjoy the prospect of a more natural chat, but Cap doesn't have any NLP so it would eventually just lead to more confusion and bot responses telling people they are talking gibberish. So that is why I'm against it.

[FreezePhoenix]

What I think is a bigger issue is the fact that Cap based bots do not work on SE. Would that be a simple URL change?

[Zirak]

@Regenhardt Thanks for the suggestion. I don't really see how any of the current bot commands are "natural language" to be honest, except maybe "give me a firefly" or "choose". Note that ! or / is usually how a bot is triggered (see irc, slack, ...), and naming the bot is usually reserved for some very special behavior (like xkcd's Bucket or weasel), or, more often than not, nothing at all.

If there's ever any NLP-based shenanigans I'll be all board. Note that if you want to have multiple invocation patterns (as they're called) on your own instance it's not a too-difficult patch.

If the c# room widely uses the bot, it'll be great to hear more on what they think can be improved. I've only heard them by proxy from @kendfrey.

@TheOneWhoMade That's a different issue, and also a solved one, as SE sites pretty much Just Work.

[FreezePhoenix]

@Zirak explain this:

Uncaught TypeError: Cannot read property 'href' of null
    at Object.getCurrentSite (master.js:811)
    at Object.init (master.js:797)
    at Object.7../Command (master.js:1549)
    at s (master.js:1)
    at e (master.js:1)
    at master.js:1

[Zirak]

@TheOneWhoMade Again, if you have a separate issue, then open a separate issue. Also note that, like in SO chat, nobody owes you a modicum of anything, so showing effort and courtesy goes a long way.