General Discussion

Due to the apparent retirement of Vhabot, and the unsuccessful attepmts to get a hold of Verm over the last few months, I have decided to share my updates to Vhabot for anyone to test. There are dozens of changes made to the core and many more to the plugins. However, I will list only the major changes. I will list more info in future messages, I had a long post that timed out a bit ago. lol
Download: https://bitbucket.org/Kilmanagh/vhabot-kilmanagh/downloads/VhaBot%200.8.0%20CE%20RC6.zip

Any Feedback or questions, please email me at: Kilmanagh@live.com
Verm please get a hold of me bro..

Core Changes:
Visual Basic Plugins now complie correctly
sendirc Function and Events that allows plugins to send a message directly to irc
Contributors to plugins can now be listed in the plugin while the originial author is retained.
XML now fixed to allow !server to work again
Users can be displayed with first "nick" last names if wanted
other Misc changes

Plugin Changes:
Note: Most updated plugins will not work with the current .79 engine because they are using some of the new functions that are in the unoffical .80 release. However, the .80 engine is backwards compatable to any previous plugins.
There are two good new Visual Basic plugins that are included as an example.

irc_Core.cs                    Added Handler and code to new IrcMessageEvent
ll_DynaCamps.cs   Windowed Output, minor bug fixes
ll_Friends.cs   Output Group by online status, PM feature to online friends
ll_NPCs.cs                    Minor Bug Changes
vh_City.cs                    Raising/Lowering Cloak History DB, Irc Output option
vh_ItemBuffs.cs   Added to default plugins
vh_KOS.cs                    Added to default plugins
vh_Levels.cs   Max AI/LE Adopted new xml
vh_Neutnet.cs   Added to default plugins
vh_Notify.cs   Added Irc Option, First "Nick" Last Name output option
vh_Online.cs   Added PM option, other misc
vh_PrivateGroup.cs   First "Nick" Last Name output option
vh_Stats.cs   Added to default plugins
vh_Towers.cs   Irc output Option, fix: Unable to Archive when org contains a '
vh_Whereis.cs   Minor Bug fixes, Windowed Output
vh_uMob.cs   Minor Bug fixes, Windowed Output
vh_XmlServices.cs   !server fixed, misc fixes
kil_OrgMemberTracker.vb   Tracks and archives all Org Joins, Leaves, Kicks.
kil_Topic.vb   !topic function

I am not sure where the future of Vhabot is at. I do believe that the system that Vhab has created as is has not been used to its fullest potential. There have been many awesome functions that have not been used in plugins that authors may not have been aware of.

I am planning on building an experimental fork to see if I can accomplish some new things. However, I will continue to offer support and suggestions with the current system.

This will be done as a prototype and I will work with any developers that want to work on the current legacy system.
One of the things I would like to do is modernize the entire library so that new and exciting technologies can be used in Vhabot.

Additonally, to make plugin development easier by providing documentation and easier methods for any plugin writers to create and publish their work. Also, allow the use of other programming languages to be used.

Also, the third major function that I am proposing is to restructure the plugins so they can work universally with webpages, internal and external requests the same way.

Changes will still work with current plugins

Lastly, take advantage and enhance the abilities of the plugins to communicate with each other.

I'm excited to see where this goes.
Keep up the excellent work

I am out here .. sorta .. !

.. so busy but I have been watching Kil's BitBucket RSS feed with great interest, and have bounced some comments to/from Llie who's RSS feed I also watch

Glad to say I'm very impressed with what's going on, and would love to pull everything that's going on together to make the preliminary release a 'beta' asap!

I might just throw up a new bug/issue/roadmap thingy like redmine/trac up on this hosting, and we'll plan what to do next!

I need to figure out how to pull all the changes into my repo, so need a Hg crash course!

I need to figure out how to pull all the changes into my repo, so need a Hg crash course!

I had mentioned this difficulty to Kilmanagh when we discussed about incorporating my plug-ins into his fork.

First off, I really have to commend Vhab for turning me onto Mercurial.  I must say that this is probably the best revision control software I've ever used.  I've even set it up at work because it's such a pleasure to work with.  That said, HG isn't without it's warts.  The downside to the ease of branching and forking is when you want to propagate changes across forks.  It's not so bad if you leave files where they are.  You can read how to compare two forks and create pull requests here: http://confluence.atlassian.com/display/BITBUCKET/Fork+a+Repo,+Compare+Code,+and+Create+a+Pull+Request

But if you move files from one directory to another, then that file can't be compared across forks, and things get complicated.  I think the only way to deal with that would be to clone both forks into separate directories and manually merge changes using a visual diff tool.

For my plug-ins, I would recommend that other devs not rename and move them into the Plugins.Default directory because I don't plan to.  I cleaned up my tree, as I had two copies of a couple of plug-ins as a result of this.  This will simplify merging, but complicate bot installation.  My plug-ins are mostly not suitable for general and org bot use.  They'd probably be better served as a public helpbot/guidebot type thing, but that's not this discussion.

For Mit, I would suggest that you push everything you've done back up to BitBucket so the rest of us can merge your changes.  That may go a long way to saving you a lot of work merging the the other way.  There are a huge number of improvements and fixes to various plug-ins that you've made that I would like to incorporate into my fork.

I don't touch core or any other parts of the repo, so Kilmanagh's changes should merge with my fork fairly easily, with the exception of when my plug-ins were moved.  Not surprisingly, he identified the same weakness (not putting long results into windows) in many of my plug-ins which was just laziness on my part, but unfortunately, we fixed them differently.  I had some confusion trying to merge his changes to my plug-ins because of the difference.

There is some activity now, and we should pick a fork that will be going forward as our community release version and work toward keeping that fork clean.  Right now it seems Kilmanagh is the most active dev at the moment, so if Mit isn't insulted, I'd suggest that his fork get's that honor, but he needs to decide how he want's to incorporate the changes Mit and I make otherwise he's going to have a ton of extra work merging changes and fixes we make in our forks.  Otherwise we're just diluting our efforts.

Edit: I started to merge Kilmanagh's changes into my fork and then I realized that I can't really compile and test on linux box.  I guess this will have to be Mit or Kilmanagh's responsibility to keep my plug-in's merged into their forks. =(

Response to Llie,

In the fork that I have, I placed the user made ones in the default because there seemed to be no standard way of creating plugin projects. Sometimes they were seperated by function or group, sometimes by author. Some of the author ones were simply empty. Some plugins by some authors where placed into the default. This was confusing and looked like there was a disjointed standardization. This not unsual with multiple developers working on the same project.

With this in mind, I did not want to make my plugins "seperate" or stand out from the rest. Since this is a collaborated effort, i felt that once plugins are published and peer reviewed as essential, they can be treated as a "default" plugin that implies everyone is equal. So my fork illustrated a collabrated effort between many talented individuals. Being in the default should be seen as an honor, not a cutdown. All plugins are prefixed with the authors initials and easy to sort.

The fork illustrates team effort vs individual efforts. Plugins are still divided by function but also divided by language used (C#. VB, etc). This is essential to the protype rewrite I have in mind. I will explain part of it in the next message.

Vhabot has a lot of capabilities that plugin developers do not even know exists. For this reason, I am documenting all code and making a dummies guide. The guide will allow a person with little programming knowledge to create a plugin and feel part of the process. As I document the classes, I am learning more and more myself. This will take time to document.

Most plugins are totally isolated from each other, which makes them rather difficult to communicate with each other. In my prototype plan I am suggesting that all plugins should have the following abilities:

The plugins should be able to communicate in an generic fashion to the following sources without making modifications for each case:
1. Other plugins within the bot instance
2. Plugins within other bot instances (same core)
3. IRC
4. Web/IIS
5. Outside/3rd party applications
6. Non VHABots.

Currently, almost of the plugins capsulate themselves by using the Ireader method and pushing AOXML as the output. This is an awesome method however limited. My idea is to change each plugin so that it returns an object that can be handled by the requester and displayed as it chooses. In this example, the data will become an object. The object will render the aoxml, and the functionality will be the same. However, if this object and the method to this object is visible to other plugins, they will have the ability to "ask" another plugin for that data. Not only can plugins ask for the information, but other sources as well.

There are already communication methods available between bots and plugins. With a few modifications, the plugins should be able to ask and get returns from any installed plugin in a generic fashion. Making this bot a even more of an amazing system than it already is.

The unoffical release I put out was put out was an offering to the hard working VHABOT developers.
When the bot was shown to be retired again, I couldnt accept the fact that development was anywhere near done.
When I was convinced that FC intends to put effort into keeping AO alive (and maybe reworked), I decided that I would share the changes I made 2 years ago and fit them into the .79 release. I made a lot of the changes when the bot was left for dead a few years ago on the 76 version I think. However, I lost my source code due to three (yes three) servers dying in the same week. So I had to rewrite the changes from memory, which was fine because the .79 baseline that verm and others done was very exciting.
Sorry for the broken up messages, I am constantly traveling around the country and in meetings.

Going to jump on this to prevent terminology confusion

AOXML

Do you mean AOML? AOML is a term coined many years back to describe the HTML variation AO uses.
VhaBot has been using AOML exclusively.

AOXML is an XML compatible language used to describe AO-supported formatting designed and implemented for Bot# fixing some very inconvenient quirks in AOML.
Note there's a difference, AOXML and AOML are not compatible but rather use parsers and converters in between.

Yes AOML, I wrote those messages while trying to configure <cough cough...> a new ClearCase VOB on a new project. I loved being forced to leave a perfectly working Visual Source Safe repository into such a messy environment.
Anyways, I had XML on the brain there since the project was using VoiceXML. Boy I typed that over and over again didnt I?

Ghehe
Poke me if you're looking for a runtime intermediate format for AOML.
One of Vha.Chat's library has a full DOM model for AOML.

Consider yourself poked sir.. LOL.
That would be awesome to see...

https://bitbucket.org/Vhab/vha.aoml/overview
Try to catch me on IRC if you need the guided tour