Status Update

It's been a short while since my last update. Things have been pretty hectic around here, I have to say. Rise of Kunark really screwed us over in terms of Evercraft's compatibility with the game, though the changes that were made seem to be for the greater good. In particular the auto-configuring hotbar on the tradeskill window is especially helpful to us (as well as to all the non-macro crafters out there), which can only be a good thing.

In response to RoK's release, we've made several changes to Evercraft that amount to essentially a band-aid on the gunshot wound... We removed the Hotkey Setup step, taking full use of the new hotbar. We also did the Vista users a favor and changed the Coordinate Setup system such that it is *much* faster - near instant on Vista and XP machines alike. As a consequence of this change, Coordinate Setup is also easier to use - you don't need to mouse-over the white box anymore, and because we perform Coordinate Setup at the beginning of each job, the tradeskill window itself can be moved around - no more frustration! =)

The harvest bot beta was also disrupted by the RoK release, in particular the fact that the memory data collected was no longer correct, and with SOE's habit of patching on a daily basis for two weeks after a major release it made little sense to try and collect that data again until the game was more stable. I only recently got the bot running again, just in time to release the next version yesterday. As far as the hunter bot goes, I'm not sure what Faldo's progress on that is - which is a shame since I'm really anxious to see it working.

Work on the new pathing system is pretty much at a standstill while Evercraft is being worked on. All my proofs of concept still function and are relevant, but I just haven't had the time to devote to it. As such, I think I'm going to go against the majority of my beta testers (who have expressed the desire that I delay the release of the harvest bot in order to get the new pather working) and release the bot (once finished) with the walkpath pather instead.

One thing I am devoting some time to, however, is the next version of Autocrat, which will be built on top of the .NET Framework 3.5. Autocrat35 will be a massive improvement over the current version, but mostly in terms of developer productivity - that is to say, it'll take *much* less time to get something out the door with this version.

So that's been my life lately. =P Sorry for not updating sooner - just hasn't been on my mind until recently.

EverHarvest Test Run

Couple updates on EverHarvest progress. First, I've gotten all of Faldo's data integrated into Autocrat in the EQ2 Core Interface system. This data specifically includes instructions for my Memory Reader that tell it where and how to find the data we use in the Harvest Bot - particularly the details about your character (position, heading) and the things around you (nodes, mobs, players). Using this data I wrote a class that returns all this data.

Also, I was able to set up a system for moving the character around the zone. I've done this before - creating a pathing bot. Initially it looks rather choppy, almost bot-like (which would obviously be a deal-breaker) - but when viewed from another EQ2 client running on another computer, it looks perfectly normal - as if it really were a player running around - which is exactly what we wanted!

My first test run also confirms that my simple State Machine design works. A State Machine is a design pattern that allows you to design and program a system by way of the states it can be in. For example, our Harvest Bot has 5 states - Inactive, WalkingToWaypoint, WalkingToNode, Harvesting, and Final. Each state has its own code to run that performs the function of that state, and when it's done (for one reason or another) it switches (or transits) to the next state. The Harvest Bot state machine is the first I've ever written, and I'm happy to say that it's a success!

So - I NEED BETA TESTERS! Get over to the forums and sign up!

EverLotto

For those who haven't already heard, EverLotto was released a couple weeks ago. EverLotto is a simple program designed to automate playing of the goblin lotto game in EQ2. It allows you to specify how many tickets you want to buy, then it tracks your wins and losses as it plays for you. It doesn't, of course, change your chances of winning, but it is a nice little tool for those of you who are trying to catch the big prize (the odds of that happening, by the way, are 1 in 1,402,410,240 - that's 1.4 billion).

Dev-wise, it was an interesting project. Because the macro-end itself was so simple (literally, one click in the same place over and over again), I was able to devote more focus on making the internals work well, as well as using the project as a testbed for some of the Autocrat Framework changes I've made. The log file reader, for example, used to be an asynchronous event-based system, but I found over the course of working with it that the approach was simply too cumbersome to be viable. I reworked the reader for a synchronous model - queuing up the log lines as they come in and processing them when necessary - and the programming on the client end has been simplified just with that change alone.

Also changed were some of my graphic functions - in particular, I made them more Vista compatible. For example, the Calibration system (where the framework looks for a white square that denotes the presence of the Lotto window) has gotten a nearly complete overhaul. Whereas in Evercraft it takes between 5 and 10 minutes to calibrate (if Aero is turned on), EverLotto only takes a second or so - so fast, in fact, that I just have it calibrate with each run, rather than store calibration data in between runs.

Finally, EverLotto's distribution model is different than our previous software. Our previous projects all have auto-updaters to allow us to keep the released codebase up to date without requiring users to download and install new software themselves. This model works, but it has its flaws - the biggest, in my opinion, is the somewhat convoluted Uninstall process our users must undergo should they wish to stop using the software and get back to normal. EverLotto has no auto-updater - I released the executable as a standalone file. I had to use some pretty nifty tricks to get it to work, though - because EverLotto modifies your UI, it has to install some files in the UI folder to display the changes. To achieve this, I imbedded the files directly into the executable, and used assembly stream manipulation to draw the data out of the exe and into the right folders. Fun stuff... =P For a more complex project, one that would require the use of an auto-updater, I wouldn't recommend this approach - but for such a simple task as automating the lotto, it's just fine.

It hasn't been a huge seller, but then I'm not surprised. I knew it wouldn't be the runaway hit Evercraft was - it just doesn't have the same appeal, really. But that's why I priced it so low - $10, with no subscription fee - it's free forever. EverLotto was written not so I could make a bundle and retire in Tahiti... It was primarilly written as a testbed application for some of my ideas and changes to Autocrat. A tech preview, of sorts.