One of our users has managed to get EQ2, EverHarvest, and EverCraft working in a VMWare Virtual Machine, and has shared the instructions on how to get it working with me!
Why is this such a great birthday present? Virtual Machines are like full computers running inside your physical computer - which means it gets its own (virtual) keyboard and its own (virtual) mouse. While EverHarvest and EverCraft still require EQ2 to be the topmost window on the computer, this can be true inside the Virtual Machine instance while NOT being true on your physical computer!
This means that you can DO OTHER THINGS on your computer while you run our software! Finally! =P
I'm working on getting the instructions in a more user-friendly form before posting them - which should come in the next day or so. Just wanted to post this to get the pot stirring, so to speak... =)
Showing posts with label eq2. Show all posts
Showing posts with label eq2. Show all posts
Wednesday, September 2, 2009
Thursday, August 20, 2009
Progress thus far
Truth be told, at this point, progress is slow going. I've been doing a lot of work for my friend Brian, and as it pays more immediately than Macrocrafter work I have to focus on that. It's been calming down of late (unfortunately) so that should afford me more time to work on this stuff.
I've been slowly organizing the work I need to do on this system. So far I've divided it up into several main components that I'll need to build before I can start stitching them together.
Also I've decided to skip the intermediate step and just make a damned hunter bot out of this, so I'll also need to integrate targeting and walking into the system.
Anyway - one of those systems includes a VB.NET compiler, as I mentioned before. All I need to do with this is to take my proof of concept code and make a proper system out of it - something reusable. I'm going to add it to Autocrat. I'll also need a timer that can produce timing events in 150ms intervals - that's the interval at which I'm going to have the system pull down updated EQ2 data. Any of the .NET timers should be capable of doing this so I'm not too worried here. I'm also going to need a state machine engine that can be configured via XML - this will be responsible for persisting the user-editable 'scripts' that will make up the brains of the bot itself. I've got a schema all figured up; all that remains is actually putting the work into it - and then I get to build a UI on top of it, because the last thing I want to require is for people (or myself) to have to hand-edit XML to get it to work.
Coupled with the timer is going to be a system for describing stateful property changes. Here's the problem: my bot engine is going to be evaluating event trigger expressions every 150ms. The expressions are boolean, so they'll be testing data based on the content of the current tick's EQ2 properties. If an expression looks similar to: "Return EQ2.GroupMember(2).Health < 50" - then when group member 2's health drops below 50%, it will trigger the event. This is desired - BUT it will ALSO trigger once every 150ms tick until group member 2's health rises to or above 50. This is NOT desired, so I need a way to expose the concept of state changes: for example, I'd like to rewrite the same expression as: "Return EQ2.GroupMember(2).Health.DroppedBelow(50)". That would return True if, and only if, the previous tick's Health was at or above 50 AND the current tick's Health is below 50.
So I'll need to figure out an efficient system of encapsulating old state and exposing it via these state descriptors. I'm sure I'll figure it out.
But you can see why I've been making slow progress here. =) In between kids, contract work, looking for full-time work, EQ2 updates, and other life, I don't have much time for experimentation, which is a shame.
I've been slowly organizing the work I need to do on this system. So far I've divided it up into several main components that I'll need to build before I can start stitching them together.
Also I've decided to skip the intermediate step and just make a damned hunter bot out of this, so I'll also need to integrate targeting and walking into the system.
Anyway - one of those systems includes a VB.NET compiler, as I mentioned before. All I need to do with this is to take my proof of concept code and make a proper system out of it - something reusable. I'm going to add it to Autocrat. I'll also need a timer that can produce timing events in 150ms intervals - that's the interval at which I'm going to have the system pull down updated EQ2 data. Any of the .NET timers should be capable of doing this so I'm not too worried here. I'm also going to need a state machine engine that can be configured via XML - this will be responsible for persisting the user-editable 'scripts' that will make up the brains of the bot itself. I've got a schema all figured up; all that remains is actually putting the work into it - and then I get to build a UI on top of it, because the last thing I want to require is for people (or myself) to have to hand-edit XML to get it to work.
Coupled with the timer is going to be a system for describing stateful property changes. Here's the problem: my bot engine is going to be evaluating event trigger expressions every 150ms. The expressions are boolean, so they'll be testing data based on the content of the current tick's EQ2 properties. If an expression looks similar to: "Return EQ2.GroupMember(2).Health < 50" - then when group member 2's health drops below 50%, it will trigger the event. This is desired - BUT it will ALSO trigger once every 150ms tick until group member 2's health rises to or above 50. This is NOT desired, so I need a way to expose the concept of state changes: for example, I'd like to rewrite the same expression as: "Return EQ2.GroupMember(2).Health.DroppedBelow(50)". That would return True if, and only if, the previous tick's Health was at or above 50 AND the current tick's Health is below 50.
So I'll need to figure out an efficient system of encapsulating old state and exposing it via these state descriptors. I'm sure I'll figure it out.
But you can see why I've been making slow progress here. =) In between kids, contract work, looking for full-time work, EQ2 updates, and other life, I don't have much time for experimentation, which is a shame.
Saturday, July 18, 2009
So far, so good.
Early proofs of concept indicate this might be a viable option. Here are some of the hurdles ahead of me:
Trigger condition evaluation: I'm planning on using VB.NET as the language for trigger condition expressions. I've built a simple test that takes an arbitrary boolean expression, compiles it via CodeDOM into an in-memory assembly, and returns a delegate to invoke it with all the necessary information that will be required of the bot. This works well so far, but of course it remains to be seen how well it'll work in practice. I may change this to having the expression compiled into a System.Linq.Expression, which I could then compile into a delegate - I think that would be faster than the CodeDOM method I'm using now. Profiling will tell.
Dynamic state machines: Part of the system will be handling different states. I'm using states as a logical grouping of events for a common scenario. For example, a Fighter bot could have many states that it could be in at any one time; an out of combat state, an in-combat state, a dead state, and so on. Each of these states can have their own grouping of events, possibly having actions that force the machine to transition between states. I have some experience with state machines so this shouldn't be too much of a challenge.
Ability mapping and timing: Another vital part of the system is my Ability Mapping concept. Instead of having each user modify their scripts to include their character's own personal spells and combat arts, scripts will instead reference ability mappings. These mappings are then configured by the user to refer to one or more in-game abilities, each of which has its own cast, reuse, and duration timers. When a script action invokes the mapping, the system will use the first ability it's able to, according to its position in the mapping (top to bottom) and the status of its timers. This way, said Fighter bot can have a mapping called 'attack' that its user could have configured with all his character's single-target combat arts, so that every time that 'attack' mapping is invoked, one of those combat arts is used. I'm still conceptualizing this particular feature so any more detail would be speculation / brainstorming, which I will save for another post.
Configuration and UI: Of course, all of this complexity needs to be presented as simply as possible. I do not intend for people to manually edit XML in order to change these scripts, so I'll be building a script editing UI for that purpose. In addition, the UI will need to include a mapping editor, as well as a place for entering script-declared variables. All of these things will need to be data-aware, and some of them dynamically created. I've been debating with myself whether I want to use XAML and WPF for the UI, and while this sounds like it might be a good use of WPF, I still haven't taken the time to crest the learning wall, and with my current job situation I don't know if I want to take that time now.
There's more, but this is getting long already - I'll post again either tomorrow or the next day with more.
Trigger condition evaluation: I'm planning on using VB.NET as the language for trigger condition expressions. I've built a simple test that takes an arbitrary boolean expression, compiles it via CodeDOM into an in-memory assembly, and returns a delegate to invoke it with all the necessary information that will be required of the bot. This works well so far, but of course it remains to be seen how well it'll work in practice. I may change this to having the expression compiled into a System.Linq.Expression, which I could then compile into a delegate - I think that would be faster than the CodeDOM method I'm using now. Profiling will tell.
Dynamic state machines: Part of the system will be handling different states. I'm using states as a logical grouping of events for a common scenario. For example, a Fighter bot could have many states that it could be in at any one time; an out of combat state, an in-combat state, a dead state, and so on. Each of these states can have their own grouping of events, possibly having actions that force the machine to transition between states. I have some experience with state machines so this shouldn't be too much of a challenge.
Ability mapping and timing: Another vital part of the system is my Ability Mapping concept. Instead of having each user modify their scripts to include their character's own personal spells and combat arts, scripts will instead reference ability mappings. These mappings are then configured by the user to refer to one or more in-game abilities, each of which has its own cast, reuse, and duration timers. When a script action invokes the mapping, the system will use the first ability it's able to, according to its position in the mapping (top to bottom) and the status of its timers. This way, said Fighter bot can have a mapping called 'attack' that its user could have configured with all his character's single-target combat arts, so that every time that 'attack' mapping is invoked, one of those combat arts is used. I'm still conceptualizing this particular feature so any more detail would be speculation / brainstorming, which I will save for another post.
Configuration and UI: Of course, all of this complexity needs to be presented as simply as possible. I do not intend for people to manually edit XML in order to change these scripts, so I'll be building a script editing UI for that purpose. In addition, the UI will need to include a mapping editor, as well as a place for entering script-declared variables. All of these things will need to be data-aware, and some of them dynamically created. I've been debating with myself whether I want to use XAML and WPF for the UI, and while this sounds like it might be a good use of WPF, I still haven't taken the time to crest the learning wall, and with my current job situation I don't know if I want to take that time now.
There's more, but this is getting long already - I'll post again either tomorrow or the next day with more.
Tuesday, July 14, 2009
Big plans.
So I hinted, last time, about some big plans I have for a new EQ2 project. I think I may have gone off the deep end a bit with this one, but I'm thinking I might have a winner.
People have been begging for a hunter bot for a while now, and while I could make one, I don't think I could do it justice. EQ2 is a very complex beast, with combat being especially complex. Despite what many think, it's *not* as simple as walking around, targeting stuff, and mashing buttons until you're done. When you play EQ2, and you fight things, you create little strategies out of the abilities you're given, and considering that there are 24 classes and umpteen billion ways of customizing (AA, etc), there are far too many of these strategies to bake in to the software.
So, in order to appeal to everyone, I'm going to stop working on the hunter bot, and start working on my new project, a group assistant (or you could call it a two-box helper).
This will, however, be like no ordinary two-box helper. My system will be completely customizable, down to every last detail, thanks to a custom rules engine I plan to build. I'm scrapping my DSL idea for this - it works, but I don't want to trust it for a production build, not yet - and going with an XML rules system with a visual designer on top of it.
This will not be a general purpose scripting application. The rules engine will support the project's only goal - to make two-boxing (or three, four, five, twenty, etc) a hands-off endeavor.
But I have ulterior motives as well... This application will facilitate a rules-based system upon which the final hunter-bot can be built. Once the rules engine is in place, and all the wiring is complete, it'll be go time.
More details to come later. =)
People have been begging for a hunter bot for a while now, and while I could make one, I don't think I could do it justice. EQ2 is a very complex beast, with combat being especially complex. Despite what many think, it's *not* as simple as walking around, targeting stuff, and mashing buttons until you're done. When you play EQ2, and you fight things, you create little strategies out of the abilities you're given, and considering that there are 24 classes and umpteen billion ways of customizing (AA, etc), there are far too many of these strategies to bake in to the software.
So, in order to appeal to everyone, I'm going to stop working on the hunter bot, and start working on my new project, a group assistant (or you could call it a two-box helper).
This will, however, be like no ordinary two-box helper. My system will be completely customizable, down to every last detail, thanks to a custom rules engine I plan to build. I'm scrapping my DSL idea for this - it works, but I don't want to trust it for a production build, not yet - and going with an XML rules system with a visual designer on top of it.
This will not be a general purpose scripting application. The rules engine will support the project's only goal - to make two-boxing (or three, four, five, twenty, etc) a hands-off endeavor.
But I have ulterior motives as well... This application will facilitate a rules-based system upon which the final hunter-bot can be built. Once the rules engine is in place, and all the wiring is complete, it'll be go time.
More details to come later. =)
Subscribe to:
Posts (Atom)
Posts
