SO-ChatBot
SO-ChatBot copied to clipboard
Zirak
die should be room specific
people seem to want to kill the bot in their rooms instead of just moving her out. Make !!die room specific, or only available in the host room (the room she is currently in if that is possible)
I think the only easy way would be to have her leave the room? But that sounds like a decent solution. Then the host room would essentially become the control point, because you couldn't call !!live (pretty sure you can't anyway) in the other room anymore.
Still, there isn't a !!leave is there? And is !!die even necessary if there was?
On Dec 6, 2013, at 7:18 PM, Robert Lemon [email protected] wrote:
people seem to want to kill the bot in their rooms instead of just moving her out. Make !!die room specific, or only available in the host room (the room she is currently in if that is possible)
— Reply to this email directly or view it on GitHub.
I propose that !!die is restricted only to the host room. Then other room can use !!unsommon.
Which is the same functionality this would create.
On Dec 6, 2013, at 7:24 PM, Shmiddty [email protected] wrote:
!!unsummon
— Reply to this email directly or view it on GitHub.
I am concerned this might be limited technically with how the bot is currently implemented. I'm not sure how the websocket shit works... but that is just my fear.
It could work. The data is right there, even if it required a little more work. It's at least feasible haha.
On Dec 6, 2013, at 7:29 PM, Robert Lemon [email protected] wrote:
I am concerned this might be limited technically with how the bot is currently implemented. I'm not sure how the websocket shit works... but that is just my fear.
— Reply to this email directly or view it on GitHub.
with !!unsummon, they'd need to come back to the JS room when they wanted to bring her back, adding clutter.
Or sandbox On Dec 7, 2013 12:00 PM, "Randall Koutnik" [email protected] wrote:
with !!unsummon, they'd need to come back to the JS room when they wanted to bring her back, adding clutter.
— Reply to this email directly or view it on GitHubhttps://github.com/Zirak/SO-ChatBot/issues/146#issuecomment-30059243 .
+1 Die by room is not only useful, it's one of those things we should just have for the sake of completeness.
!!die by room just encourages the bot lurking. I mean there no problem with it, but if she's not active why should she be in the room at all?
On Dec 7, 2013, at 2:13 PM, Shea Sollars [email protected] wrote:
+1 Die by room is not only useful, it's one of those things we should just have for the sake of completeness.
— Reply to this email directly or view it on GitHub.
There's always been a problem with /die in that it requires a unique command: /live. It's a bit paradoxical - if it's dead, how can it listen to a command which brings it back to life?
As it's currently implemented, once you kill the bot, what the bot does is to actually process your input, and just not display output, so it becomes mute rather than both mute and deaf. The end-result is that if you call /live, the reviving logic is done, and it goes back to life. There's also the nasty side-effect of actually running any logic - if you execute a command which changes state (like /todo or /ban or something), it's actually executed, and you just don't see the output.
Fixing that is not too trivial. After all, in addition to bot commands/listeners, we have things which listen to any kind of input, for instance the STOP - HAMMERTIME plugin. Obviously, when the bot's killed, those should be stopped as well (and we can see an edge-case where someone who was banned from the bot can still trigger these).
So, there is the technical problem. I'm going to work on it today - checking the input/output in several places may alleviate the problem.
@rlemon erm, maybe? I don't remember what Zirak from 2013 wanted to do. If I were to do it today, I would actually special case /live, so something like:
function executeBotCommand(cmd) {
if (bot.dead[cmd.roomid] && cmd.name !== 'live') {
return;
}
cmd.execute();
}
Minimal changes, minimal breakage, but "raw" commands (like hammertime) are handled in other code paths, so they'll need to check for death individually.