Progress, Warden, Debugging

And finally, another post, and more progress. In the last few weeks I have mainly been busy with refactoring my code base so it is easier to plug into the Warden protection I have. That basically requires that all memory changes (hooks and overwritten variables so far) are kept track of so they can be removed when Warden starts a scan and later restored again when the scan finished. I took that opportunity to refactor most of my code which has been mostly consisting of hacks and such to include newly gained knowledge from reverse engineering and such.

Additionally I did some more Warden REing to get a better idea of how it works and especially how and what it scans. So far I can at least see what memory addresses it reads, which is pretty interesting in itself, but not nearly all of what it scans. However since reverse engineering takes a bunch of time and I would like to get back to writing the bot itself again, I left it with that and am going to continue it whenever the need or time arises. I intend to set up a page here to list all addresses it currently scans and their frequency since I like statistics :)

Since the refactoring also made everything much easier I also made some progress on the flying harvesting state machine. This mostly includes a bunch of fixes to movement and combat related portions. Things that are usually obvious to a human (or should be) are not to the AI and need to be specially handled, and since a lot of these cases only happen in certain circumstances and are difficult to reproduce. For example, in this video you can see that the bot at some points attacks a mob that doesn’t even attack the player. This happened because the targeting module prioritizes targets on certain factors like health, aggressiveness, distance, etc. and valued that mob higher than the one currently attacking the player because of wrong weights on these factors.
Additionally it shouldn’t even attack mobs that aren’t specifically attacking the player (or in more accurate terms: targeting the player). But since it sometimes takes a few seconds for the combat status to drop off the player it immediately takes the target on top of the targets list and attacks that.

This is of course one of the easier problems and easily fixed, but sometimes there are problems that are difficult to make out or diagnose, at which points it becomes very difficult to reproduce them. That’s one of the big problems with writing “hacks” for closed source games, debugging them is a nightmare.

In any case, so far the harvesting state is working very well, a more up to date video can be seen here. What’s still missing is a way to recover from death, which will probably be the next part on the TODO list, since that’s a feature required by all sorts of states anyway.

Leave a Reply

Your email address will not be published. Required fields are marked *