Last update: 22/07/2012 (3. Speed of current movement code) 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 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. I can go on and on about the results of bad code, but that's not what I'm trying to do. I think everyone gets the point: bad code is bad. Documentation and (maybe) experienced coders writing code can help others develop programming skills. 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 These are the top 3 things that are currently loaded that are often custom-coded. Botbase for the bot's functionality, Plugin for extra features, Profile for the botbase's routine and CustomClass for combat. 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.
""//I believe a fully documented API would help a lot. It might even encourage new people to learn how to develop scripts.//"" /signed
In terms of API you can load HB.exe as Reference in VisualStudio and most of the API can be seen with comments about what it does via IntellISense then.
True, but that only serves a few of the points I talked about. It doesn't really help new people, I can't access it from a remote location (eg. phone or tablet), etc. But yes, it does resolve the issue of not having any point of reference. I still love the idea of a real online API though, for reference.
We know that the system of 1 botbase per task which has often some kind of its own profilestructure creates some kind of limitations , especially for gathering professions . AutoAngler and ProfessionBuddy were done by a thirdparty developer though and integrated later to be shipped, therefore they of course arent tied to the Gatherbot and act diffrent. Archbuddy also hasn't been there from the beginning of the bot and isnt nearly as old as Gatherbuddy2 . Diffrent Botbases from diffrent people and developed at a diffrent time. There are people that think it should only be the profile that tells the bot what todo and not need you to switch a botbase. I on the other hand adjusted to that, and you can chain diffrent profiles with hbrelog/arelog and professionbuddy together. First Herbs&Ores, then Fishing for a while, then something else. If i farm myself, i do not combine archaeology fishing and herbing together too, so i wouldnt call it non-human to focus on one specific thing. Documentation In my opinion this currently is more like scotland yard, if you need something that isnt in intellisense, especially when it comes down to writing profiles one has to look really hard. the very very outdated wiki, the questbehaviour cs-files themselfes (if you can read the code), other peoples profiles. You have to ask your fellow community members if they had a similiar issue and solved it and if so, how. Since i dedicated a lot of time into that, i know how to get most infos i need, but for new people, this is a huge roadblocker, which i can understand. The problem with documentation in my eyes is multilayered, - The people who know the stuff and could describe it, do not need it, since they already know - It's difficult to structure a complex topic like this in a comprehensive way - If we do a wiki, this wikisoftware sucks, editing and formating articles is a pain. - and for me: motivation, it's a very long and boring task, there are more fun ways to spend time or also a more productive, as in fix mesh issues and help people with bugs. What should an hb wiki describe? Any other wikisoftware ideas that are more userfriendly than mediawiki? The speed issue, is this only related to releases after 5883 ? did it happen before the invisible wall sets of fixes? does it still happen with 5965?
Just want to put my thought in, as I agree with OP 100% I was just looking to start writing my own custom class for my warlock, as there isn't one that does not stutter or perform combat logic properly. I went to around to see if I can find any guides that will help me get started. The only one that I could find is an outdated guide by CnG from 2010, and just by going through the thread I found there are a few function and API are not used anymore in the current HB. I am not some expert developer, I only have been coding in AutoIt for a bit, but they have a really good source where I can learn about what each functions does. There just isn't anything like this on here, and I feel that this "roadblock" as OP puts it, extremely huge. As a temporary solutions, if there is a mIRC channel where new people such as myself can ask questions and get some instant feedback would be great. And is it just me or has the development for HB stopped ever since DB came out?
Ah, that is correct. However, I meant that the script should be able to handle all these things, but that doesn't mean they would or should be used at the same time. The script I would love to write does not necessarily do *everything* at the same time. No one does that. But it would be able to do so. It would contain a list of all my accounts and would remember any data there is to remember about them once I log in on one (character names, levels, gold, items, AH, ...). After this, it would automatically generate a randomized farming pattern using all the data it has, so it avoids overflowing the AH with items, it keeps in mind private buyers for specific items, etc. Not only would it generate this pattern, it would be able to perfectly execute it with customized routes. Every profession + questing + dungeons, etc. (of course an optimized CustomClass will be written for this) True. Those who know their stuff already know all they need. That's why I mentioned "new people" or even "new programmers". The content of the wiki would be limited to: 1 page per API entry (datamembers, functions, ...) with their names, parameter types, return values. And also an explanation of what the function does, what every parameter is used for and what the return value actually is used for. Aside from this, people would also be able to write guides and such, but that's just extra. As for motivation, I'm sure there are at least a few regular members here on the forums that have some experience with programming, so they could help as well. A wiki is set up by a community, it's not the job of a single person. Even on the forums, there are already lots of guides. The main thing that would change, is that it would be posted on the wiki with a consistent style and quality (no more annoying/absurd colors or font sizes/types). The goal of this documentation wouldn't be to learn people how to write entire programs. It would be to teach them how to correctly use HB's "language" (API). I used to know an ideal software package for an API documentation wiki, but unfortunately I kind of forgot the name. It's a well-known one though.. It mainly occurred while using the druid's underwater form (+ the glyph to go even faster), or at least that's where I noticed the behaviour of stopping a few hundred milliseconds before going on to the next one. There are a few threads posted about this exact same thing. Seen only in Vashj'ir though, no matter what profile or CC I was using. Since then, it doesn't seem to happen anymore, however I've only recently seen it work without the "+ underwater speed boost" glyph for druids. So can't say how it behaves with it. I also found a new problem. When you get dced in-game while the bot is running (no matter what botbase, this has happened with ArchBuddy, GatherBuddy & BGBuddy so far) and you log back in without restarting the bot, it might so happen that the bot is actually logged out as well. So it shows the HB login frame again. When logging in again, HB will state it is not attached to a supported WoW version. However, it says "you're running version #XXXX but it's compatible with #XXXX" (my apologies, haven't had it happen now so can't copy/paste the actual log content), where #XXXX are both the exact same number. So it's the supported version. This "bug" goes away after restarting HB. From what I've noticed, I think some people are busy working on movement & meshes, can't say I'm sure though. But yes, DB does seem to have some kind of priority atm.
As a relatively new user, I would second the "save data" thing, but I also understand that it does this some already but only behind the scenes. Showing character config via the GUI would be good as often settings seem to get reverted if you DC and a profile tries to "push" a setting on you like Kick's leveling profiles. Also, lack of displayed information tends to cause confusion as to why settings change during a stop/start Some features I would find useful: Aquatic form and/or swimming mounts in the mount list, though I'm not sure how well the mesh "knows" where water is when calculating paths so this might be more complicated than just "use swimming mount if path requires so many yards swimming" Speaking of stop/starting, a Pause button would be fantastic. Often times, when something brings the need of stopping, we don't need to start the profile from line 1 so much as just pause to combine leather to heavy leather or manually kill a mob that requires moving out of damage on the ground etc. This could help with so many things. As for mesh work, I spoke with Kick about it too, but movement logic and unstuck mechanisms seem to disappear when harvest/ninjaskinning takes over.
Ah, that is very interesting. If the community can help with something, definitely let me know. I'm definitely willing to help out should that be helpful for you guys. Something extra would be to implement fixed waypoint routes. No meshes, no calculating. The meshes are great, but they calculate an optimized route. Every HB instance will do this, and if you're in a battleground for example, almost every HB bot will use the exact same route. Very non-humanlike and the #1 reason to get you reported. The calculations can be optimized, but I think it'd be useful to allow people to use fixed waypoints instead as well? This way, we can create perfect profiles even for zones where meshes don't work as well and we can create custom humanlike profiles (eg. run in the middle of the bridge in AV, since that's where everyone is fighting instead of always walking on the side and falling off / getting pushed off by shamans). Another suggestion that would go perfectly together with the previous one would be to create a profile recorder (similar to the plugin that exists now called ZapRecorder if I remember correctly) but optimized; it would record your route but with each waypoint, it would calculate an allowed x and y offset (allowed meaning it'd avoid walls and such). So when the bot runs the profile, it randomizes every waypoint using the allowed offset every time.
<Troll> all the points you made are things that are going to change in coming years. //Corrected for you </Troll> I do REALLY hope that you seriously consider a CustomClass recompile option! This would make coding and applying settings (in some CCs) A LOT easier! cheers Weischbier
no i literally meant MONTHS, if i meant years i would of put YEARS. with MoP coming out hb is going to need to be updated and overhauled to work on MoP. there's a lot of stuff going on that id like to talk about but a lot is still in the air right now. but if we were to make major changes to the core, during the MoP update would be the time. as far as the community goes, it will bounce back when MoP comes out, no one wants to spend time making stuff thats going to be made useless in less then 2 months.
