C# Bot

[DecA]

It seems to me, by the looks of it, more and more C# bot developers are popping up. Anyways, the point of this thread is, I would like to here about everyons C# bot. The features,  and the connection method you used. So yeah...
I have written a C# Chat bot(LQBOT), using BNLS/EASN support, I am alos currently working on a C# Operator bot,  wich also uses BNLS support, I have alot of commands already finished for it, if you would like you can PM me, if you would like to see some of  them.

Ok, your guys turn..

[K]

I have a C# bot which connects only as Warcraft3/TFT using my C# version of iago's java code.  It doesn't really do anything except have a really robust plugin system.  I ported all the plugins from my old chat bot.  The really cool plugins let you play zork over battle.net, talk to my Alice AI plugin, or write simple text "scripts".  The more mundane ones implement a GUI for chatting, etc.

Hoozah.

[MyndFyre]

It seems to me, by the looks of it, more and more C# bot developers are popping up.

That's cuz everyone wants to copy me. 

(In reality, it's because C# is easily accessible and easily understood, providing a good gateway language for new programmers, and a familiar language for Java veterans).

Anyway, mine currently supports a BNLS-hashed connection to Battle.net, although I will soon be adding on the RCRS and support for local hashing.  The main assembly that drives the connection mechanism, ArmaBot.Connections.dll, is an interface-based, event-driven set of code.  The implementation of each connection interface is done within the assembly (although this will be changing at a later iteration), and the implementation of each settings interface is done elsewhere.

Part of the perks of using interfaces was that I was able to use a single class (ArmaBot.Profiles.ProfileEx as I recall) to store all settings data, including information for the connection process (ArmaBot.IConnectionSettings), Security (ArmaBot.Commands.ISecuritySettings), and others.

The bot is not actually dependent on the GUI for control; in fact, at some point, I want to make a Windows Service out of it.  I *may* even be able to use .NET Remoting to remote-control a bot running as a service from anywhere (that would be very, very sexy, and something I need to look into).  The way that the DLL works is that the client passes in a request:

Code Select Expand


IConnectionManager connection = Connections.GetConnectionManager(mySettings as IConnectionSettings);


Then, there are 48 or so (more since I last posted the API) events that you can register callbacks for.  These events won't always hit if you're on the wrong type of connection, but it won't give you an error, either.  For instance, say you have the following callback function:

Code Select Expand


private void GeneralErrorResponse(string message)
{
  this.rtbChat.AppendText(message);
}

You can register this callback with a call to your connection's EventHost:

Code Select Expand


connection.EventHost.RegisterEvent(EventType.ChannelFull,
  new InfoEventHandler(GeneralErrorResponse) );

The method signature for the RegisterEvent and UnregisterEvent methods are the same:

Code Select Expand


bool RegisterEvent(EventType type, MulticastDelegate handler);
bool UnregisterEvent(EventType type, MulticastDelegate handler);

The function returns true if the event is supported in the connection context.  The EventHost with which you are registering the event throws an ArgumentException if you try to use an invalid type of delegate given the event for which you are registering.