Joined: 03 May 2006 Posts: 2292 Location: Colorado
Posted: Wed May 10, 2006 5:08 am Post subject: Cerebrus aka Andromeda
Hey,
So I'm working on finalizing the new and Improved Andromeda bot. The new name will be Cerebrus, the 3 headed dog that guarded hell! Hey it sounds cool and I like it.
I wanted to take a quick survey and see if there are any features people keep wishing that bot frameworks had, but that arn't there. This template/framework/whatever is currently built to handle pretty much anything I can throw at it, so now I want to see what you guys can come up with and see what I'm missing. This is a multi-protocol bot so it focuses only on those things that can be done on all protocols, but it also allows access to the underlying protocol object so that advanced stuff can be done on a per protocol basis.
The easiest way i could think to show you Cerebrus' might is to show you the config file. I'm going to break it appart and explain the peices.
Code:
<config>
<Bots>
<Bot Name = "AimBot"
User = "darwin256"
Password = "********"
Protocol = "AIM"
/>
<Bot Name = "MsnBot"
User = "darwin256"
Password = "********"
Protocol = "MSN"
/>
</Bots>
Hopefully this is obvious. It's an XML format and allows you to install as many bots as you want on as many protocols. Protocol wrappers are used to provide a consistent interface to them all, each wrapper also provides access to the underlying objects.
This is where the fun begins. Everything on these bots is a filter. Each filter is processed in order. The Name determines what Module is loaded to do the filtering and then the other options are passed to that module. There is also a $session object that holds a users information, and a $context object that holds this specific messagse information. Each $context object has an array of input and an array of output. So each filter works to modify the input or output, or remove stuff from the input array and put the correct response in the output array.
This specific list of filters starts by using the count filter, tells it to process the input, and accumulate the count in the IncomingWords stat.
Second filter checks if its in a chat room, if so it grabs only those messages that start with darwin|dar|d, So in a chat room you would have to say "darwin, !help" to talk to darwin.
Third filter, removes all messages from people on the @ignore list.
These filters remove HTML (for AIM), remove curse words, and then log the final output to the screen.
Code:
<Filter Name="If" If="_welcome" Is=""
Say="Welcome to Darwin. I'm currently just running test code. Check back often to see my progress!"
Set="1" InChat="0"
/>
This one is fun, it checks the users session fo a _welcome variable, if its not set then it welcomes the user and sets the variable, but only if we arn't in a chat room.
These are the commands. The same filter is used twice, onces to load commands that only admins are allowed to run.
The second loads commands for everyone. You'll notice that it also lets you set the prefix right here. Anyone could of course right there own command filter and replace this one with it. The bot/template/framework couldn't care less.
Some final filters split the message into multiple messages if we are IRC (IRC prefers it that way), logs the final output, and then counts the words we've said to people.
The system is designed to let you build flexible filters, and then configure them here. This lets you reuse one filter for many jobs, you can see that the grep,log,count and commands filters where all reused a couple times. Each filter gets enough information that it can control anything about the bot so that you get the ultimate extensible system.
Please ask any questions, make any suggestions for improvment etc. I would like to see some response before I release it so that I can make updates before its out there. Once stuff is out in the wild its incredibly hard to make massive changes too So if you see some fatal flaw please, please, please point it out.
Hope this has you salivating for more, Darwin256 is on AIM right now if you want to see it in action! _________________ Eric256
Proud previous owner and current admin of Bot-depot.com
So is this bot going to be (mostly) XML, with just some Perl to handle the lower-level protocol stuff?
I've used XML as a bot config system (using XML::Simple) and had some issues with it, where perfectly-syntaxed XML code would load in wrong and strict would complain about odd variable types. So, wouldn't wanna see you run into similar problems once it's out there too.
What does this bot have in terms of brains? It looks like from the XML you posted that you'd hardcode some responses into the XML. Is this how all the responses would be? It seems kind of... unflexible... and very syntax-strict. XML newbies might run into common problems, much like HTML newbies do when they write webpages themselves.
So, since you weren't any clearer on how brains would work, I'll go ahead and suggest this: add an API for adding custom brains. i.e. something along the lines of this:
Code:
# brain loading subroutine
use Chatbot::Eliza;
sub mybrain_load {
# create brain object...
my $eliza = new Chatbot::Eliza();
return $eliza;
}
# brain replying subroutines
sub mybrain_reply {
# get necessary info
my ($eliza, $username, $message) = @_;
# reply
return $eliza->transform ($message);
}
# return this info to the main bot program
{
Name => 'Eliza',
Description => 'The classic Eliza therapist bot',
LoadingSub => \&mybrain_load,
ReplyingSub => \&mybrain_reply,
};
And a code like this would be dropped into maybe a "brains" folder as "eliza.pl" and these would be loaded in at startup or something. I'm sure you'd figure out an efficient, extensible system for this.
Joined: 03 May 2006 Posts: 2292 Location: Colorado
Posted: Wed May 10, 2006 3:40 pm Post subject:
Sorry from my perspective that was obvious and I probably should have been more specific.
Filters can do anything. So some filters will be brains. So realy it can handle any type of brain that you can build a filter for.
For instance here is a simple filter to wrap the Blabber module that Mojave released a while back. The same type filter could be built for any "brains" out there. In fact your bot could have multiple brains that it used for different allow lists, or different modes, or just used them in order (as long as the brain doesn't make a default guess).
Code:
package Filters::Blab;
use Blab;
sub new {
my $proto = shift;
my $self = {
Blabber => new Blab()
};
bless $self, $proto;
return $self;
}
sub filter {
my $self = shift;
my $context = shift;
Looks nice - I like the idea of filters. Will *all* commands be filters, or can commands be loaded in seperate files - as with other bots? I'm just thinking that something along the lines of
Code:
<Filter Name="If" If="_welcome" Is=""
Say="Welcome to Darwin. I'm currently just running test code. Check back often to see my progress!"
Set="1" InChat="0"
/>
for a command such as Hangman is going to get complex. Or is it no longer a command bot and more a chat bot?
Also, if your commands are now filters, will there be any functionality for backwards compatibility? It's going to discourage new botmasters from using your template if there are no commands available for it .
I like the intuitiveness of the filters, but wonder how successful they will actually be. _________________ ~ Josh
[ Need bot hosting on a dedicated server? PM me. ]
Joined: 03 May 2006 Posts: 2292 Location: Colorado
Posted: Wed May 10, 2006 5:49 pm Post subject:
I'm starting to see that i didn't describe this well.
You build filters to do anything you want. ANYTHING! lol
So a filter might be a command in the actualy XML ilke that one.
But the 'commands' that I already built (and included in the above example) loads commands from seperate files. You coud then add a second filter and make it load the commands from a database.
The point here is that the template doesn't know or do anything except filters. It takes your message, loads it into a context object, and then passes that $context object on to each filter in order.
The filters can then do anything. They can check the message, see if its a command, if it is then run the command and get the reply. They can simply remove/modify parts of the messages based on some internal roll, or they can record the message to a database. Regardless of what they do each filter can leave the $context object alone (like the log, not need to change anythign) or change it. So my command filter checks the incoming message. If its not a command then the filter leaves the context object alone and its passed on to the next filter. Otherwise it removes the message that is a command from the input list, processes it, runs the needed command, and then adds the output to the context objects output list.
So once this is out, it could be easily modded to support any and every command system out there all in one bot Any and all brains all in one bot, anything at all I even had a filter that corrected a users spelling on there for a while. So if you typed !tme if might be able to say "did you mean !time?"
The examples given above are just that. Examples. I have several more filters already built that i excluded for simplicity.
Example: I have a spam filter. I put it early in the filter list and it checks to see fi a user is repeating themselves alot or speaking too fast. If they are then it adds that user to the ignore list, it might even monitor them for a while and keep a score and only ignore them after X repeats. Since the filter has access to the users session it can store long term information about a user simply by setting values in a hash.
Example: I have a slang filter. I place ti just before the end. It takes the context's output list and applies some slang translation to it to make the bot sound hip! lol. So if a previous filter (brain/command/etc) put "How are you?" the slang filter would change that to "How r u?".
Other Example Filters:I also have an echo filter that repeats what the user says, a curse filter that removes curses, a Type filter that applies typos to the bots output, a normalize filter that removes duplicate spaces that a user typed, and a BotWork filter that takes a users messages and sees if any botwork bots can answer them.
Hehe. I have this vision, but obviously its not 100% clear to anyone but me and thats my fault for not communicating it well. Just remember that filters are simple perl modules that can control what the bot things it heard (modifying the input) and what its going to say (context output list). Each filter can access the others info if it wants but normaly they work completly independently.
The XML file is just to tell the bot what filters to use in what order, and supply custom options for those filters.
Let me know if thats still not clear.
BTW It is fairly easy to update old andromeda commands to the new command system, or someone could just rip the old command system out and use it as a filter in this bot then it would just do the right thing _________________ Eric256
Proud previous owner and current admin of Bot-depot.com
I was under the impression the filters were the only things evaluated - not that they're linked to perl modules. Makes more sense now ;D.
Seems like it'll be a really good bot . Know any idea about the release date? _________________ ~ Josh
[ Need bot hosting on a dedicated server? PM me. ]
User Control Panel
Hey it sounds cool and I like it.
.