So as to not clutter DecA's topic, I have created my own:

[quote author=K link=topic=9640.msg89747#msg89747 date=1101162363]
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.
[/quote]

Mind explaining how your robust plugin system works?  I have been thinking about a plugin system for sometime and have yet to find a system I like.  Any others are welcome to input their systems as well.

Well, it's all about .NET.

The previous version worked like this:

one Assembly specifies an interface to a Host class and a Plugin class that is known by both the main program and the plugin.  The plugin implements the specified Plugin interface, which contains events that are called by the main program when events occur.  The Host interface provides services to the plugin like WritingText, enumerating other plugins, as well as full access to the W3Bot object and the Chat Queue.  It also provides helper functions like RegisterRemoteCommand() and RegisterLocalCommand() which take a command and a callback to be called when the events occur.

In the new version,
I got tired of seeing all these empty functions being called, when plugins didn't use all events, so instead of forcing the plugin to implement all the functions for every event, I simply allow each function to register the callbacks it wants to receive via the .NET delegate system.

In addition, if a plugins specifies the ITickable interface, it receives a Tick() event when the main program loop is idle.

In my Extensibility API (which has been updated since that was posted), I used a base class that was to be inherited by plugins.

The advantage of using a base class is that you can specify internal methods on the base class (and in C# 2.0, internal property set methods) that can set the plugin up for certain operations.  For instance, on my new (beta 1) plugin system, the plugin has unrestricted access to the command list, database, and configuration.  Mine also uses events (rather than direct access to the main bot UI) for information display to the user, messages sent to Battle.net, and others.  Looking at the PluginBase class, I also notice the UserChat event -- that might have been for enabling chat encryption.  I'm not really sure what I had in mind at that time.