Should a moderation bot have a GUI?

[Furious]

|12:41:13 PM| <******> warz, make a GUI for your moderation bot

That's what brought this topic up.  This bot in development is written in C++, but the person the quote is from won't stop talking about having a GUI and all this blah blah blah.  IMO a moderation bot should have no GUI at all, or as minimal as it can be to keep the bot functioning correctly.

Input go!

[MyndFyre]

It depends on what you want from your bot, of course.

The original JinxBot was intended to be a hardcore moderation bot for Battle.net.  It was an event-driven system running on three primary threads.  The GUI thread (the main thread) was "below normal" priority, as was the connection listener thread (it was also marked as a background thread).  The event dispatcher was "above normal" priority.  Because of the thread disparity, that ensured that the event dispatcher ran as long as there were events enqueued.  The event queue was also prioritized, so things like returned WC3 profiles were lower-priority than, say, channel joins, channel joins were always dispatched first.  (This wasn't preemptive; if a WC3 profile was being processed, then the event dispatcher waited for that to complete first).

The way that it worked was that there were obviously things the event dispatcher wanted written to the GUI.  But GUIfied things were always low-priority.  High-priority event listeners implemented in plugins, such as a moderation plugin, got all event notices before the GUI did.  And because Windows doesn't support modifying the GUI in any thread but the GUI thread, I had to marshal that data back to the main thread.  .NET has methods called Invoke() to do this and block or BeginInvoke() to do this asynchronously, and that's what I chose to do (the latter). 

As long as you have good design it's entirely possible for a moderation bot to have a GUI.  There's also the possibility of decoupling the GUI from the bot completely; you can implement a protocol like RSP (which is incomplete btw) to have a GUI communicate with your bot.

[Joe]

I personally think that a bot that's strictly for moderation shouldn't have a UI, beyond, "Connecting.." etc messages, much like Network's VanquishBot (I wrote a UI plugin for it, but whatever).

However, there's hardly any strictly moderation bots. JavaOp is clearly a moderation bot, as the name states, but it still has a UI (pretty nice, too). StealthBot is a hybrid, and has a UI.

I think that you should add an option to hide + destroy (in terms of objects involved =p) the UI if you're going for moderation, but still have one there.

[igimo1]

I personally think that a bot that's strictly for moderation shouldn't have a UI, beyond, "Connecting.." etc messages, much like Network's VanquishBot (I wrote a UI plugin for it, but whatever).

However, there's hardly any strictly moderation bots. JavaOp is clearly a moderation bot, as the name states, but it still has a UI (pretty nice, too). StealthBot is a hybrid, and has a UI.

I think that you should add an option to hide + destroy (in terms of objects involved =p) the UI if you're going for moderation, but still have one there.

Plugins, of course.

[wires]

No, I don't think they should.  A colorful, decorated, and over all pretty GUI would just cause more events and slow the bot down. :/

CookieBot has a basic GUI, used for information that the user may want to know, and debugging.  I don't even think you should be looking at the bot's GUI, or talking through it if it's being used for moderation.

This also brings up the say command, which I think a moderation bot shouldn't have since it's there to moderate not talk.

[Joe]

Say has more uses than saying. Giving ops to another user, squelcing someone, etc.

[MyndFyre]

Giving ops to another user,

!designate user

squelcing someone, etc.

!ignore user

IMO, say should never be permitted to say a command.  Placing this restriction allows you to avoid running some security checks on outgoing packets.  For example, I would assume the !designate command checks the flags of the user saying !designate.  But if you !say /designate, and you permit that, you'd need to make sure that the user saying !say also has the flag to !designate.

[wires]

Say has more uses than saying. Giving ops to another user, squelcing someone, etc.

That's what <trigger>[designate/squelch] <username> is for.

Giving ops to another user,

!designate user

squelcing someone, etc.

!ignore user

IMO, say should never be permitted to say a command.  Placing this restriction allows you to avoid running some security checks on outgoing packets.  For example, I would assume the !designate command checks the flags of the user saying !designate.  But if you !say /designate, and you permit that, you'd need to make sure that the user saying !say also has the flag to !designate.

That's my point exactly.  It can easily be abused.

[Newby]

IMO, nothing wrong with a UI (a GUI for that matter) if you prioritize it right.

If it gets in the way of processing events related to moderation, you fucked up somewhere.

[Eric]

There's no purpose for adding a UI on such a bot.  Channel moderating bots should always have some sort of logging feature.  This should be sufficient.

[Furious]

There's no purpose for adding a UI on such a bot.  Channel moderating bots should always have some sort of logging feature.  This should be sufficient.

My thoughts exactly.

[MyndFyre]

There's no purpose for adding a UI on such a bot.  Channel moderating bots should always have some sort of logging feature.  This should be sufficient.

Oh I don't know.... maybe USABILITY?  FLEXIBILITY?

Like Newby said, as long as it's coded correctly and the priorities are in the right order, adding a GUI doesn't hurt anything.

[Eric]

There's no purpose for adding a UI on such a bot.  Channel moderating bots should always have some sort of logging feature.  This should be sufficient.

Oh I don't know.... maybe USABILITY?  FLEXIBILITY?

Like Newby said, as long as it's coded correctly and the priorities are in the right order, adding a GUI doesn't hurt anything.

You should only be capable of accessing the bot through the medium in which it was designed to operate on—Battle.net.  Keeping this in mind, I don't understand what kind of flexibility or "usability" you'd need here.  Perhaps you wish to leave room for in-bot game and ladder listings?  Clarify, please.

[Newby]

Oh I don't know.... maybe USABILITY?  FLEXIBILITY?

Like Newby said, as long as it's coded correctly and the priorities are in the right order, adding a GUI doesn't hurt anything.

You should only be capable of accessing the bot through the medium in which it was designed to operate on—Battle.net.  Keeping this in mind, I don't understand what kind of flexibility or "usability" you'd need here.  Perhaps you wish to leave room for in-bot game and ladder listings?  Clarify, please.

What if the bot disconnects and it won't reconnect? Perhaps you'd like to have some sort of interface to manage it?

What if you need to access the bot locally and don't want to waste the time going through Battle.net servers to access it?

[MyndFyre]

What if the bot disconnects and it won't reconnect? Perhaps you'd like to have some sort of interface to manage it?

What if you need to access the bot locally and don't want to waste the time going through Battle.net servers to access it?

The mightly Lord[nK] already answered that Newby.  Duh.

You should only be capable of accessing the bot through the medium in which it was designed to operate on—Battle.net.

Obviously if the bot disconnects you're a fucktard who can't program.

[rabbit]

Or you got disconnected for a game patch?

[wires]

Or you got disconnected for a game patch?

You don't always get disconnected, hell I think sometimes you can use the older version for a while even after the new patch.

[Eric]

Oh I don't know.... maybe USABILITY?  FLEXIBILITY?

Like Newby said, as long as it's coded correctly and the priorities are in the right order, adding a GUI doesn't hurt anything.

You should only be capable of accessing the bot through the medium in which it was designed to operate on—Battle.net.  Keeping this in mind, I don't understand what kind of flexibility or "usability" you'd need here.  Perhaps you wish to leave room for in-bot game and ladder listings?  Clarify, please.

What if you need to access the bot locally and don't want to waste the time going through Battle.net servers to access it?

What if someone else using your computer decided to do the same?

What if the bot disconnects and it won't reconnect? Perhaps you'd like to have some sort of interface to manage it?

The logs would allow you to determine the cause of the problem and automatic reconnections should handle the rest.  I suppose that in some cases you may need to restart the bot, the same as you would restart a failing system service.  The goal is, as MyndFyre so elegantly put it, to not program like a "fucktard" and to prepare for the worst while hoping for the best.  That should be your goal for all programming projects, whether they have a UI/GUI or not.  The best bots are the ones that can function without significant user intervention.  That's why they are called "bots."

[Newby]

What if someone else using your computer decided to do the same?

Uhm, I don't let people use my computer when I'm not on it. It's called a screensaver with a password.

I could also have the interface require a password to re-draw itself after being minimized. Or something to that extent.

The logs would allow you to determine the cause of the problem and automatic reconnections should handle the rest.

A "logging" interface, as in the one similar to pf and pflog? (I've had to tcpdump on pflog0, it's pretty neat) Or do you mean opening up notepad after you realize your bot has been offline for a few hours to scroll to the bottom of a noisy log to find out what the problem is?

[iago]

You guys are crazy. 

A bot should have an optional GUI.  People who want to can use it, people who don't won't have to. 

Better yet, make the GUI completely decoupled from the program, to the point where you can use it over a network.  Because most people don't run moderation bots on their own machine but they would still like to see and configure it. 

So yeah, OPTIONAL.  You fools.  Let the user decide. 

[Furious]

What if someone else using your computer decided to do the same?

Uhm, I don't let people use my computer when I'm not on it. It's called a screensaver with a password.

I could also have the interface require a password to re-draw itself after being minimized. Or something to that extent.

The logs would allow you to determine the cause of the problem and automatic reconnections should handle the rest.

A "logging" interface, as in the one similar to pf and pflog? (I've had to tcpdump on pflog0, it's pretty neat) Or do you mean opening up notepad after you realize your bot has been offline for a few hours to scroll to the bottom of a noisy log to find out what the problem is?

The bot(s) I currently use log different situations in different files.  All login information is logged in one file, chat is logged in one file, and commands logged in another.