Last update: 22/07/2012 (3. Speed of current movement code)
Current content:
I believe it's not necessarily the bot's fault that something is going wrong. It's not necessarily the profile's fault either.
The fundamental issue is multiple things.
1. Quality of user-written code
At the moment - the quality of the written code (outside of Honorbuddy [eg. botbases, plugins, ...]) isn't always what it should be.
A lot of people have written some code, others have tried to write code but have written rubbish, etc. Because of this, sometimes even the entire structure and logic in the code is incomplete or incorrectly formulated. This always and yes always results in something bad. For example;
2. Limitation of current code structure and API
I don't expect everyone to have noticed this. This is mainly for software engineers such as myself.
The current Honorbuddy's structure is as follows:
Issue #1
By this logic, it is completely illogical to code a complete botbase that does not only perform a certain task (eg. farming [GatherBuddy2]), but that might be able to perform a second task as well (eg. Archaeology [ArchBuddy]). And lets add that it can level both from 1 to 525. By the current logic, you'd have to write 2 different botbases: 1 for farming, 1 for Archaeology. And you'd write profiles for each botbase.
However, tell me this:
If you would write it using the current structure, how would you make a bot that is able to switch between characters, that can switch between what professions it's farming (to seem more humanlike), maybe even switch between accounts and switch to a dungeon queue when it feels like it?
How would you let 1 botbase control several botbases' functionality together with each individual botbase being able to switch between profiles whenever it feels like it?
Quick answer: by screwing a bit with the current logic, and by using "hackish" methods and using the botbase not as a botbase but as a loader for botbases. However, Honorbuddy itself is already a loader for botbases. So writing a loader for a loader is kind of counterproductive.
I've worked with other bots before and have helped to develop bots and scripts for bots (mainly for other games than WoW), and some of them implemented just what they called *scripts*. Instead of parsing the botbase, then the profiles, then the plugins, etc... they only parsed the scripts. The scripts are pretty much an "all-in-one". Some scripts also used "profiles". But they didn't have to write their own parser for them. The bot developers didn't develop a "Load Profile" button, but they developed a .loadProfile(Profile p) API function that scripts could call to open a dialog to select the correct profile. This entirely removes duplicate code and makes the bot a lot faster. The user also only has to load the bot, not the profile. This also helps the developers of Honorbuddy: you don't have to think about *everything* anymore. Scripts allow developers to develop their ideas. And with that come all the details such as profile loading, etc.
Issue #2
Together with what I've written in "Issue #1", I can't seem to find any well-documented API website/wiki/... There doesn't seem to be any real point of reference for more experienced software engineers to scroll through the API and write decent code (and yes, I have searched around). Right now, all we can do is take a look at what others have attempted and try to fix their code if needed. But that's not what coders are for. Sure, we can help as well. But some of us are here to write our own code, to develop new ideas. That's what - I believe - makes a community and the bot greater.
Aside from fixing things, the lack of a documented API (documented as in: by programmers, for programmers. Not a wiki that explains every single thing about programming; but a list of API functions, their return values, functionality, etc) also limits the bot's functionality. If we're not getting crucial information, we can't develop that supermegaepic botbase that makes everyone want to buy your bot. If we're not getting crucial information, we can't optimize our current code. This means you'll be stuck with a slower bot, only because we don't know how to possibly optimize it. Because we can't know.
I believe a fully documented API would help a lot. It might even encourage new people to learn how to develop scripts.
3. Speed of current movement code
At the moment, the speed of the movement code seems a bit "off". I know what the possibilities are in a bot and I have experience writing basic WoW bots (including movement) in C++ (I've created a few things for educational purposes). But I've noticed that Honorbuddy sometimes has a hard time going to the next point. There seems to be a delay.
In general, when on a regular mount, you won't notice the delay and it'll be very smooth. However, when you're at maximum speed + epic flying + crusader aura + any kind of movement modifier, your speed is too fast for the bot. It will actually get to it's destination point, wait for 300 milliseconds (approximately, this can go up to 800ms) then finally click the next point. It's not downloading meshes, it doesn't have to calculate so much. It only has to click the next point, but it's not fast enough.
This actually results in click > stop > click. Even if the stop isn't very long, it is obvious bot behaviour and should - in my opinion - be fixed.
I'm not sure as to what the Honorbuddy devs think about all this but if the Honorbuddy team could comment on this, it would be very much appreciated.
Current content:
1. Quality of user-written code
2. Limitation of current code structure & API
2.1. Issue #1: Separated bot logic & API usage
2.2. Issue #2: API documentation
3. Speed of current movement code
2. Limitation of current code structure & API
2.1. Issue #1: Separated bot logic & API usage
2.2. Issue #2: API documentation
3. Speed of current movement code
If I notice this thread becomes active and useful, I might add more things on here in the future and use it as a central reference for possible important updates or fixes.
I believe it's not necessarily the bot's fault that something is going wrong. It's not necessarily the profile's fault either.
The fundamental issue is multiple things.
Before you continue, I would like to note I'm not trying to flame. Even though I will point out some negative things, I do not mean it personally and even if someone has done something terribly wrong, that person might still have tried. I'm trying to be constructive, not negative. Should there be any questions or need of clarification, feel free to ask, I'm more than willing to clarify.
1. Quality of user-written code
At the moment - the quality of the written code (outside of Honorbuddy [eg. botbases, plugins, ...]) isn't always what it should be.
A lot of people have written some code, others have tried to write code but have written rubbish, etc. Because of this, sometimes even the entire structure and logic in the code is incomplete or incorrectly formulated. This always and yes always results in something bad. For example;
- Sometimes the bot has to calculate too many things because the code logic isn't right. This slows down the bot in general (be it during movement, combat, ...).
- Bad behaviour can occur when code logic isn't correct. The bot can get stuck, it can continue flying in circles because it's stuck between "flying away" and "in combat", etc. This is always because somewhere in the code's logic, the code isn't checking for the possibility of a certain event. It doesn't know this event, so it'll get stuck between 2 events it does know and it'll try to execute the first one it knows. When doing this (eg. fly away), the bot will get at a moment where it will re-evaluate the code and decide what to do next. But because the bot has already moved, it will now decide it might be better to fight the monster it's in combat with. So it'll try to fly back to the monster. But once it gets closer, it re-evaluates and says "omg a monster is attacking, but I'm flying so I can just go away", and it'll try to leave again. This is when the bot is stuck until the character dies and it gets into a new state (eg. running back to the body). This error actually currently exists in the current CustomClass for Druids called HazzDruid Elit3.
- etc.
2. Limitation of current code structure and API
I don't expect everyone to have noticed this. This is mainly for software engineers such as myself.
The current Honorbuddy's structure is as follows:
- Botbase
- Plugin
- Profile
- CustomClass
Issue #1
By this logic, it is completely illogical to code a complete botbase that does not only perform a certain task (eg. farming [GatherBuddy2]), but that might be able to perform a second task as well (eg. Archaeology [ArchBuddy]). And lets add that it can level both from 1 to 525. By the current logic, you'd have to write 2 different botbases: 1 for farming, 1 for Archaeology. And you'd write profiles for each botbase.
However, tell me this:
If you would write it using the current structure, how would you make a bot that is able to switch between characters, that can switch between what professions it's farming (to seem more humanlike), maybe even switch between accounts and switch to a dungeon queue when it feels like it?
How would you let 1 botbase control several botbases' functionality together with each individual botbase being able to switch between profiles whenever it feels like it?
Quick answer: by screwing a bit with the current logic, and by using "hackish" methods and using the botbase not as a botbase but as a loader for botbases. However, Honorbuddy itself is already a loader for botbases. So writing a loader for a loader is kind of counterproductive.
I've worked with other bots before and have helped to develop bots and scripts for bots (mainly for other games than WoW), and some of them implemented just what they called *scripts*. Instead of parsing the botbase, then the profiles, then the plugins, etc... they only parsed the scripts. The scripts are pretty much an "all-in-one". Some scripts also used "profiles". But they didn't have to write their own parser for them. The bot developers didn't develop a "Load Profile" button, but they developed a .loadProfile(Profile p) API function that scripts could call to open a dialog to select the correct profile. This entirely removes duplicate code and makes the bot a lot faster. The user also only has to load the bot, not the profile. This also helps the developers of Honorbuddy: you don't have to think about *everything* anymore. Scripts allow developers to develop their ideas. And with that come all the details such as profile loading, etc.
Issue #2
Together with what I've written in "Issue #1", I can't seem to find any well-documented API website/wiki/... There doesn't seem to be any real point of reference for more experienced software engineers to scroll through the API and write decent code (and yes, I have searched around). Right now, all we can do is take a look at what others have attempted and try to fix their code if needed. But that's not what coders are for. Sure, we can help as well. But some of us are here to write our own code, to develop new ideas. That's what - I believe - makes a community and the bot greater.
Aside from fixing things, the lack of a documented API (documented as in: by programmers, for programmers. Not a wiki that explains every single thing about programming; but a list of API functions, their return values, functionality, etc) also limits the bot's functionality. If we're not getting crucial information, we can't develop that supermegaepic botbase that makes everyone want to buy your bot. If we're not getting crucial information, we can't optimize our current code. This means you'll be stuck with a slower bot, only because we don't know how to possibly optimize it. Because we can't know.
I believe a fully documented API would help a lot. It might even encourage new people to learn how to develop scripts.
3. Speed of current movement code
At the moment, the speed of the movement code seems a bit "off". I know what the possibilities are in a bot and I have experience writing basic WoW bots (including movement) in C++ (I've created a few things for educational purposes). But I've noticed that Honorbuddy sometimes has a hard time going to the next point. There seems to be a delay.
In general, when on a regular mount, you won't notice the delay and it'll be very smooth. However, when you're at maximum speed + epic flying + crusader aura + any kind of movement modifier, your speed is too fast for the bot. It will actually get to it's destination point, wait for 300 milliseconds (approximately, this can go up to 800ms) then finally click the next point. It's not downloading meshes, it doesn't have to calculate so much. It only has to click the next point, but it's not fast enough.
This actually results in click > stop > click. Even if the stop isn't very long, it is obvious bot behaviour and should - in my opinion - be fixed.
I'm not sure as to what the Honorbuddy devs think about all this but if the Honorbuddy team could comment on this, it would be very much appreciated.
Last edited:
we believe in you HBteam