JinxBot Development Blog

On the JinxBot Wiki I have posted a how-to guide for getting the latest source code as a read-only user.  But, that doesn’t get us to be able to contribute to and from the repository.

Here I’m going to use the Angels of Armageddon web site repository as an example, located at http://angelsofarmageddon.googlecode.com/.

First, make sure that you’re logged into Google Code.  Then go to the Source tab of the project.  You should see something like this:

See that part that says “When prompted, enter your generated googlecode.com password?  Go ahead and click on that link.  You’ll see this page, except instead of the bright red box you’ll see your password.  Go ahead and select it and copy it; you’ll need it.

Now, switch to Explorer.  You’ll need to create a new empty folder.  Once you’ve done so, right-click in the folder, and choose SVN Checkout:

In the dialog that pops up, you want to enter https://angelsofarmageddon.googlecode.com/svn/ with the optional trunk folder after that.

The next dialog will pop up asking for your credentials.  Enter your Google account name and the password you copied from the GoogleCode.com account information page a couple screens ago.  I’d suggest saving it so that you don’t need to hunt it down in the future.

That’s all there is to it!

I had some time this weekend to work on JinxBot[Web], the web-facing service designed to support streaming web-based channel display on top of ASP.NET.  After getting the behavior to work as expected, I decided to go back and reengineer the core architecture of the web application, making things a bit easier to maintain on the thin client as well as making it more robust.  Here’s a quick recap of what happened this weekend:

• I changed the UI layout management from Y!UI to a jQuery plugin.  All use of Y!UI JavaScript will now be dropped in favor of jQuery.  The Yahoo! library was really cool in theory, but in practice it was just too difficult to get it to do exactly what I wanted.
• I changed the database architecture substantially.  We now have entities reflecting the four major Battle.net gateways as well as an “Other” gateway.  This is reflected in the new UI; instead of the previous channel list at the top, channels are now organized in a drop-down menu by gateway.  Instances of JinxBot that have multiple channel feeds (I don’t know why this would be the case, but it’s important to handle this kind of thing when you don’t control the client), will appear listed by client name.  So as an example:
• US East –> Op [vL]
• US West –> Op x86 –> Newby[x86], US West –> Op x86 –> MyndFyre[x86]
• This channel access structure will be reflected by the URL rewriting system as well.  There are high potentials for collisions when using the existing URL rewriting system though; consider the situation in which we log in at first and don’t change:
• http://www.jinxbot.net/web/channel.aspx/Diablo_II_USA-1 (doesn’t work).
• This channel isn’t tied to a specific gateway.  However, if two clients were in Diablo II USA-1, they could differentiate themselves with a more fully-qualified URL:
• http://www.jinxbot.net/web/channel.aspx/USEast/Diablo_II_USA-1 (doesn’t work).
• In the event that two clients are in the same channel on the same gateway, to access the correct channel feed requires the qualification of the client name.  This is the name of the client as registered with JinxBot[Web], not the name of the user logged into Battle.net:
• http://www.jinxbot.net/web/channel.aspx/USEast/Diablo_II_USA-1/WebChannel (doesn’t work)
• I enabled the saving of channel state.  This wasn’t as easy to do as you might think – it required implementing some business logic on the web server.  I think I might change it up so that whenever the channel state changes it’ll update the web server with the complete channel state from the client.

More is definitely on the way and there will be a working prototype soon with the first beta release of JinxBot.  Keep watching!

I mentioned here that I’ll be presenting to the Phoenix .NET Users Group a library designed for bringing Facebook development to the .NET development world.  So until then, I’ll pretty much be eating, sleeping, and breathing Facebook.

Don’t worry, JinxBot isn’t gone forever!  It’ll be soon.

Part of the difficulty that I’ve been running into with JinxBot’s development is trying to come up with a way to create effective plugins.  Because JinxBot is a multi-profile client for Battle.net, I tend to think that it might be interesting to enable a single plugin object to handle multiple profiles.  For instance, consider a Warcraft III clan scenario: a single client could sustain up to six total channel operators.  By hosting all of those operators on a single machine, synchronized through a single plugin object, the plugin is able to dispatch /ban commands through all connected profiles, running a far lesser risk of missing a user and of flooding itself off.

The problem is then how to handle loading, instantiating, and tracking the plugins and the profiles that are using them.  Even more of a problem is keeping these plugins segregated from other types within the system.  And then it begs the question of how different interfaces should be supported; for instance, if a multi-client plugin also supports command handling, is there ever a need for one to take priority over the other?

I’ve written a minor writeup about how I intend to develop the JinxBot plugin API.  I look forward to comments and feedback about the planned plugin support.

Welcome to the JinxBot Development Blog. I’m Rob - or if you’ve run across me on Battle.net or Xbox Live I go by MyndFyre. This blog is going to chronicle the development of JinxBot, JinxBot[Web], and BN#.