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.

x86] link=topic=5531.msg64678#msg64678 date=1144800244]

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]

x86] link=topic=5531.msg64885#msg64885 date=1144896682]

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]

x86] link=topic=5531.msg64885#msg64885 date=1144896682]
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.