Okay. =)

Well, 3 people commented in a month - which is enough for me, I guess. =P Plus who knows - more content means more search engine fodder, so more people might stumble across me.

So what have I been working on? Well I released the harvest bot (EverHarvest) and we've gone through several minor revisions, plus constant update when EQ2 patches and breaks the system. Some work has gone into two additional projects - AutoGrind (a hunter bot for EQ2, similar to Faldo's recently-abandoned EverHunt), and a project I'm calling 'GCB' - Group Control Bot, which will basically be an EQ2-smart multi-box helper.

AutoGrind is being implemented as an extension to EverHarvest; that is, the two programs will be contained in the same package, but still requiring separate licenses to activate. The reason I'm going this route is that the two programs are *incredibly* similar (walk around, target stuff, act on the targeted stuff) so they can share a great deal of code. Additionally, the two tasks can work in tandem - while you're harvesting, if you're attacked, it can attack back; or while you're hunting, if it targets a node, it can harvest it.

Group Control Bot (that's a working title) is, very simply, a program that allows you to control multiple instances of EQ2 (running on one or more *separate* computers) from one Master computer by sending commands from the Master computer to the slave computer(s). Unlike most generic programs which perform similar tasks, this one is EQ2 specific, such that it will understand commands like 'Target Me' or 'Move Behind My Target'.

Both projects are currently in their extreme infancy - GCB is mostly disorganized notes, while AutoGrind is a branch of EverHarvest code with a few modifications - nothing functional yet, or ready for beta testing.

Something I'm revisiting with the EH + AG project is the idea of smart pathfinding replacing the waypoint system. I did some early tests with this last year, with very limited success - I didn't understand how to build a Quadtree node connectivity graph (basically, for each square, finding that square's neighboring squares). I was using a *very* slow geometry-based method of comparing all the square's bounding boxes to eachother, returning a collection of all the squares that were touching.

As I said, I'm revisiting it - I rewrote my Quadtree implementation to remove most of the recursion from the methods operating on the structure, and did some additional research on the subject of node neighbor finding, such that I was able to construct a non-geometric solution to the problem that uses node traversal to find neighbors. This method is *far* faster, especially for large numbers of nodes.

I haven't yet written my A* implementation yet - doing some more research into this as my last attempt, while workable, was highly inefficient, as was my path smoothing algorithm (required for more human-looking path-walking).

So - that's what's been on my mind recently. =)