Show Posts
1
UOAI Corner / About UOAI
« on: September 20, 2009, 03:35:21 AM »
Summary
UOAI is a library exposing UO 2D client functionality in an object oriented way. It allows you to perform things like reading information from running UO Clients and perform actions on them. All information comes in object oriented form: clients are client objects, items are item objects, gumps are gump objects, etc. The library is not written as a simple dynamic link library, but instead comes in two flavors: as an ActiveX component library and a .NET library. The choice for a COM/ActiveX library results in easy usage from multiple languages on a windows platform, including java, lua, visual basic, java, javascript, vbscript, etc .
It's important to realize that UOAI is still actively being developped, though I'm hoping to reach stable versions of both the COM and .NET libraries soon.
History
On the runuo forums i was was asked several times why UOAI involves "AI" in it's name, while it does not actually involve any Artificial Intelligence in it's current form. The correct answer to this question requires looking back to UOAIs history, and I thought it might be interesting to post this history over here too.
Though my feeling with the easyuo community has changed now, UOAI does date back to that community, more specifically to a pathfinder project i started writing over there. My posts on this messy project seem to be still there on the euo forums: http://www.easyuo.com/forum/viewtopic.php?t=15777!
The idea, back then, was to write a more powerfull minerbot by using a pathfinder algorithm. I wanted to add the following 2 capabilities to my minerbot:
At that time this seemed rather hard to accomplish goals within easyuo, so i decided to write an external program with which i could communicate from within my easyuoscript. The program implemented a A* pathfinding algorithm on top of the UO map-files that could also do things like finding mineable tiles, etc.
The first idea towards UOAI was grown out of the limitations of this pathfinder application. The main problem with the pathfinder was that calculated paths could not take into account items or multis that might block the road while walking the path. Even though i could recalculate paths to find a path around items, that was harder for multis, since easyuo didn't provide any info on the size of multis, so there was no way of knowing which tiles the multi blocked.
To obtain that info, I decided to start a new project (never published online though as it was never finished), which watched the packetstream (it acted as a proxy between the client and the server) and therefore was able to obtain all info on locations and sizes of items, mobiles and multis itself without interacting with easyuo. The idea was to implement a set of AI functions on top of this information: the pathfinder described above, now with correct recalculation of paths around multis; but also other AI things like a decission maker, which would heuristically choose the next action to take in a fight in UO (mainly targetting an automated dexxer, though the same algorithm could be used for an automated mage too)... so real AI things... which is why I named this project: UOAI. The project never got to he point of actual functional AI, for one because it's design was flawed at some points, but also simply cause I still lacked some required experience to write it.
Years later I started reading the announcements on the OpenEUO project, which however seemed to take forever to be actually implemented. It is at that time, being facinated by the OpenEUO idea, that I ventured into restarting my old UOAI project, since I felt I was more experienced now and could do a better job than before (it's up to you to be the judge of that
). I decided to rewrite it from scratch and redesign it: I would no longer depend on a completely packet-based approach, but would leave already implemented functionality in the client to the client; and I would expose everything as COM/ActiveX interfaces, since I had learned from other projects that this was a much more powerfull, yet easy to use, method to expose functionality than simple dll based APIs. The idea was still to eventually implement the kind of AI functionality I described in the previous paragraph on top of this library, so the name UOAI remained suitable!
Current Status
Even though usable and relatively stable, UOAI is still in development and therefore has a set of issues that might be considered serious depending on the application you have in mind. Since UOAI also provides hooks of the client's packet stream most issues can be worked around in packet based approach, however since the idea is to provide a simple interface to the client, I intend to provide easier alternatives for anything you can do packet based.
UOAI currently comes in two flavors: the COM library and the .NET library wrapping up the COM libraries' functionality.
It turns out however that most users prefer using UOAI from .NET languages; and it's also a fact that .NET code is easier to manage than a COM library written in C, and therefore I recently decided to split both project: the .NET library will be turned into a seperate project, no longer wrapping the COM library.
UOAI is intended to be open-source, but managing an open-source project is a lot of work, and I haven't found the time yet to provide and manage all the communication channels required to get multiple developers involved. This will change once the next UOAI.NET library has arrived, the first step: providing code through an SVN repository, has recently been taken.
UOAI currently lacks acceptable documentation. After the next .NET library is finished, I will work on this though.
Future
The near future of UOAI lies in it's next .NET libary: this will be a library completely decoupled from the COM library and will have several advantages over previous versions:
As the this .NET version of UOAI currently being designed will be more stable and useable from the start, further development will be slow and consist mainly of additions of non-essential functionality and maintaince of client-support.
Client-support will be maintained by me: I am moving all callibration-code into a seperate tool; both the COM and .NET library will obtain version-dependent info from an xml configuration file generated by this callibration tool in the future. My work will mainly consist of maintaining and updating this callibration tool.
Extra functionality in the .NET library can be contributed by anyone (which will still include me at first, but i'll move on to other projects later on).
The far future of UOAI, for my part, will therefore mainly involve the COM library:
UOAI is a library exposing UO 2D client functionality in an object oriented way. It allows you to perform things like reading information from running UO Clients and perform actions on them. All information comes in object oriented form: clients are client objects, items are item objects, gumps are gump objects, etc. The library is not written as a simple dynamic link library, but instead comes in two flavors: as an ActiveX component library and a .NET library. The choice for a COM/ActiveX library results in easy usage from multiple languages on a windows platform, including java, lua, visual basic, java, javascript, vbscript, etc .
It's important to realize that UOAI is still actively being developped, though I'm hoping to reach stable versions of both the COM and .NET libraries soon.
History
On the runuo forums i was was asked several times why UOAI involves "AI" in it's name, while it does not actually involve any Artificial Intelligence in it's current form. The correct answer to this question requires looking back to UOAIs history, and I thought it might be interesting to post this history over here too.
Though my feeling with the easyuo community has changed now, UOAI does date back to that community, more specifically to a pathfinder project i started writing over there. My posts on this messy project seem to be still there on the euo forums: http://www.easyuo.com/forum/viewtopic.php?t=15777!
The idea, back then, was to write a more powerfull minerbot by using a pathfinder algorithm. I wanted to add the following 2 capabilities to my minerbot:
- Being able to automatically find it's way in between different locations (bank/house, mine, forge, ...) without the need of pre-configured or recorded routes.
- Being able to automatically find the next 8x8 block of mineable tiles (chopable trees for a lumberjack would be equivalent) that hasn't been depleted yet. (with some timeout to readd blocks once they are respawned).
At that time this seemed rather hard to accomplish goals within easyuo, so i decided to write an external program with which i could communicate from within my easyuoscript. The program implemented a A* pathfinding algorithm on top of the UO map-files that could also do things like finding mineable tiles, etc.
The first idea towards UOAI was grown out of the limitations of this pathfinder application. The main problem with the pathfinder was that calculated paths could not take into account items or multis that might block the road while walking the path. Even though i could recalculate paths to find a path around items, that was harder for multis, since easyuo didn't provide any info on the size of multis, so there was no way of knowing which tiles the multi blocked.
To obtain that info, I decided to start a new project (never published online though as it was never finished), which watched the packetstream (it acted as a proxy between the client and the server) and therefore was able to obtain all info on locations and sizes of items, mobiles and multis itself without interacting with easyuo. The idea was to implement a set of AI functions on top of this information: the pathfinder described above, now with correct recalculation of paths around multis; but also other AI things like a decission maker, which would heuristically choose the next action to take in a fight in UO (mainly targetting an automated dexxer, though the same algorithm could be used for an automated mage too)... so real AI things... which is why I named this project: UOAI. The project never got to he point of actual functional AI, for one because it's design was flawed at some points, but also simply cause I still lacked some required experience to write it.
Years later I started reading the announcements on the OpenEUO project, which however seemed to take forever to be actually implemented. It is at that time, being facinated by the OpenEUO idea, that I ventured into restarting my old UOAI project, since I felt I was more experienced now and could do a better job than before (it's up to you to be the judge of that
). I decided to rewrite it from scratch and redesign it: I would no longer depend on a completely packet-based approach, but would leave already implemented functionality in the client to the client; and I would expose everything as COM/ActiveX interfaces, since I had learned from other projects that this was a much more powerfull, yet easy to use, method to expose functionality than simple dll based APIs. The idea was still to eventually implement the kind of AI functionality I described in the previous paragraph on top of this library, so the name UOAI remained suitable!Current Status
Even though usable and relatively stable, UOAI is still in development and therefore has a set of issues that might be considered serious depending on the application you have in mind. Since UOAI also provides hooks of the client's packet stream most issues can be worked around in packet based approach, however since the idea is to provide a simple interface to the client, I intend to provide easier alternatives for anything you can do packet based.
UOAI currently comes in two flavors: the COM library and the .NET library wrapping up the COM libraries' functionality.
It turns out however that most users prefer using UOAI from .NET languages; and it's also a fact that .NET code is easier to manage than a COM library written in C, and therefore I recently decided to split both project: the .NET library will be turned into a seperate project, no longer wrapping the COM library.
UOAI is intended to be open-source, but managing an open-source project is a lot of work, and I haven't found the time yet to provide and manage all the communication channels required to get multiple developers involved. This will change once the next UOAI.NET library has arrived, the first step: providing code through an SVN repository, has recently been taken.
UOAI currently lacks acceptable documentation. After the next .NET library is finished, I will work on this though.
Future
The near future of UOAI lies in it's next .NET libary: this will be a library completely decoupled from the COM library and will have several advantages over previous versions:
- Easier to manage: I will focus a great deal on providing all details on both using this next version for applications and on documenting it's internals! Written in C# the code itself should already be more manageable and as all code will now be managed through an SVN repository: any C# developer could potentially contribute.
- More stable and efficient: That might sound like big words, but my insight in most issues with the current UOAI versions has grown, and the next library version will solve all of these issues: faster searching of items, easier usage of gumps, seperately managed and more stable callibration-routines that are fundamental to stability, decoupling of the COM-library which has been the source of many problems due to the complexity of low-level COM-code, etc...
- Well documented: once the first stable version is finished (a matter of (a) week(s)), i will focus on writing several applications on top of it and providing extensive documentation.
- Extra functionality: special classes to ease the use of handling specific gump types; options to create/show/hide custom items and gumps on the client, classes to wrap up packethandling: parsing or building of known packets will be done for you!; some AI functionality such as pathfinding; access to the client's mul-files; ...
As the this .NET version of UOAI currently being designed will be more stable and useable from the start, further development will be slow and consist mainly of additions of non-essential functionality and maintaince of client-support.
Client-support will be maintained by me: I am moving all callibration-code into a seperate tool; both the COM and .NET library will obtain version-dependent info from an xml configuration file generated by this callibration tool in the future. My work will mainly consist of maintaining and updating this callibration tool.
Extra functionality in the .NET library can be contributed by anyone (which will still include me at first, but i'll move on to other projects later on).
The far future of UOAI, for my part, will therefore mainly involve the COM library:
- It will be rewritten from scratch to provide the same stability and to solve the same issues as i am currently solving in the .NET library.
- It will be rewritten to allow for web-usage: it is currently not a real 'activex' library in the sense that you can not load it on websites. The final COM library will be provided as a signed activex control which can be used directly from websites (if installed) : this will f.e. allow the site of a free shard to provide a webform that automatically launches your UO Client and connects it to this free shard when submitted. The idea is to open up a lot of extra potential applications for UOAI.