FelBot!

[iago]

StealthBot tries to do everything and thus fails.  Pick chat or pick moderation.  You can't have both.

Sure you can, if it's strongly plugin-oriented.

[Joe]

Okay, I pick chatbot then. But you can't say that it'll fail at being a useful chatbot if I include remote commands.

[rabbit]

Sure, but if you include trivia I'll have to kill you.

[Joe]

Agreed. But, when I lay the plugin foundation down (it's on the todo list, under "eventually"), if someone writes a trivia plugin (or I get bored and do it myself), I'll have no problem linking to it. It won't be a core feature, though.

[rabbit]

What I would do for any bot I make in the future (currently planned: none) would be to build in anti-trivia protections so that even plugins could not provide trivia functionality.

[Camel]

StealthBot tries to do everything and thus fails.  Pick chat or pick moderation.  You can't have both.

Disagree. My bot's great at both. The GUI is a plugin, so you can shut it off for a moderation deamon. Flood protection is optional, so it doesn't bother you if you're chatting.

[rabbit]

There's a difference between a moderation bot with a GUI and a Chat/mod combo.

[iago]

There's a difference between a moderation bot with a GUI and a Chat/mod combo.

That's not what you said:

StealthBot tries to do everything and thus fails.  Pick chat or pick moderation.  You can't have both.

You just admitted that you could have both.

[Warrior]

I think it'd be possible with a rich plugin environment. Perhaps the ability to swap queue systems tiered more towards chat/moderation and such.

Even then, it's perfectly possible to have a somewhat decent moderation and a chat client if you're not concerned with top of the line efficiency. Not that it's much of a problem anymore though.

[rabbit]

There's a difference between a moderation bot with a GUI and a Chat/mod combo.

That's not what you said:

StealthBot tries to do everything and thus fails.  Pick chat or pick moderation.  You can't have both.

You just admitted that you could have both.

How so?

[Joe]

Thanks many thanks to everyone. This is coming along nicely, and with the rest of this here, it's decently "usable". Again, thanks for checking it out. Go ahead and test this, and treat it's current features like a "release candidate", except the queue. Enjoy.

Also, if anyone knows of a currently, rather close yet safe anti-flood algorithm, let me know.

1.01 "Public Beta"

Bug Fixes:
- You can no longer talk before the bot is in the chat environment.
- Now, the SID_CHATCOMMAND for joining the home channel is sent after the server responds to SID_CHATCOMMAND, not right after the client sends it.
- Added "PX2D" as a valid client in the pre-connection sanity check.
- If you try to disconnect before connecting, you'll no longer get an exception, due to checking if the socket is a null pointer before closing it's object. Thanks, Warrior!

Additions:
- Added code to support clients with two CD keys, thus Diablo II: Lord of Destruction is now supported
- On the configuration form, client has become a drop-down box with "user-friendly" names
- Handling of EID_BROADCAST, EID_CHANNELFULL, and EID_CHANNELRESTRICTED messages
- Added a primitive queue. Note that I have only layed down the foundation and made it so that the messages will be sent 500ms after the previous one. This isn't meant to provide protection from flooding off, and don't expect it to work for that at this point.
- Added a foundation for commands. These are only accessable to the "bot owner". In the future, an access database will be added.

EDIT -
Known issue, the channel list won't clear when you join a new channel. Fixed for 1.02.

[Camel]

I think it'd be possible with a rich plugin environment. Perhaps the ability to swap queue systems tiered more towards chat/moderation and such.

Even then, it's perfectly possible to have a somewhat decent moderation and a chat client if you're not concerned with top of the line efficiency. Not that it's much of a problem anymore though.

Top of the line efficiency? We're talking about a program that watches a socket for data indicating that people are joining/leaving/chatting in a channel. How much processing power do you really think that takes? My bot's written in java, and I've never seen a stable build spike above 2% CPU usage.

Joe: Check out my queue system. It's set very, very conservatively, so you can probably decrease the time constants.
http://bnubot.googlecode.com/svn/trunk/BNUBot/src/net/bnubot/core/ChatQueue.java

[edit] You'll also need to look at my Connection class to figure out how canSendChat() works:
http://bnubot.googlecode.com/svn/trunk/BNUBot/src/net/bnubot/core/Connection.java

[Warrior]

I think it'd be possible with a rich plugin environment. Perhaps the ability to swap queue systems tiered more towards chat/moderation and such.

Even then, it's perfectly possible to have a somewhat decent moderation and a chat client if you're not concerned with top of the line efficiency. Not that it's much of a problem anymore though.

Top of the line efficiency? We're talking about a program that watches a socket for data indicating that people are joining/leaving/chatting in a channel. How much processing power do you really think that takes? My bot's written in java, and I've never seen a stable build spike above 2% CPU usage.

Joe: Check out my queue system. It's set very, very conservatively, so you can probably decrease the time constants.
http://bnubot.googlecode.com/svn/trunk/BNUBot/src/net/bnubot/core/ChatQueue.java

[edit] You'll also need to look at my Connection class to figure out how canSendChat() works:
http://bnubot.googlecode.com/svn/trunk/BNUBot/src/net/bnubot/core/Connection.java

By efficiency I was more leaning towards a unified Queue system.

[Camel]

Click my link to ChatQueue.java - it's a unified queue.

[MyndFyre]

- Added a foundation for commands. These are only accessable to the "bot owner". In the future, an access database will be added.

It's sad, but now that I've used MSSQL, I don't want to go back to Access.... ever.... again.