Some core/script issues

[hackersrage]

First, I would like to say to Kick - GREAT PROFILES ...

However, there are some issues which crop up and I am wondering if you can do anything to correct them --- or if HonorBuddy itself needs to correct these issues.

1. Some quests that the Gossip is a talk to, the character will just stand there, and eventually AFK/log.

2. Gossip dialogs for quests that are not completed (or if the objective item is no longer in inventory), opens and closes repeatedly. I would suggest a try 3 times, then abandon quest and move on.

3. Evading mobs. The bot does not seem to have any capability to detect this and move on after a couple of "swats" having "Evade" come up. Instead, it will get "stuck" attacking that mob for (insert long time frame here [ hours, days, weeks, ]).

4. Interactive game objects that yeild no loot or quest item (bugged loot quests), the bot will persistently keep trying --- again, forever.

5. When running the bot for a long time (or sometimes even 5 minutes or so), the user is forced to re-authenticate and initialize and start the script. Is there anyway you can improve the ping system so that the key need only be authenticated on launch, and never again while running.

6. Flight paths. With or without having "Use Flight Paths" checked, periodically (and randomly as it can occur at ANY flight path, so there is nothing specific), the bot will stand there (forever) with the flight path dialog open. This can occur after the bot has been running for hours, or after the bot has COMPLETELY initialized.

7. In pandaria (and other places), the bot refuses to get out of AoE's. When attempting to move the bot out of the AoE manually, it just runs right back in.

8. Avoiding creatures that are WELL beyond your capability of defeating --- the bot on numerous occassion has attempted to take on such creatures as rare-elite level 90's who do insane AoE damage such as the Sha rare boss, and so on. It would be nice if the bot adjusted it's path (similar to choosing a new rez location based on number of hostiles near-by) upon detection of such creatures. -- On this note, your 12-58 script still tries to zerg the item off the tree stump from near the sleeping Elite Hounds -- and thus wakes them all and toon gets pwnd : Every time.)

9. Collision detection. If running, flying, or swimming into the same object/tree/wall/cliff/etc multiple times, go back to the last set of valid co-ordinates and try a new route please.

10. Stop dropping COMPLETED quests when having to restart the bot. Reasons for restarting include (but are not limited to), game crash, bot crash, bot re-authentication, user stopped to correct issue with quest/objective/etc. Dropping the completed quests when starting the bot up again is super annoying, especially if one of the things you stopped the bot for was to complete a quest it could not handle.

11. The ability to "skip" quests/zones. I found the "classic" script can be painfully slow leveling due to the bot working on grey and green quests instead of moving to the next zone. As an example of what I would like to see, checkout Zygor's guides. When you reach a certain progression level, you turn in the current quests, then move to the next zone, dropping all incomplete quests.

12. More detailed Vendor options. For example, vendor greens, and blues that are soulbound, but are not trinkets or non-equipable items, and vendor grey, but do not vendor white unless it is gear, food (not mats), or potions (low level).

13. Improve PvP targeting. When attacked by another player, the bot will retaliate, but it will switch target to the opponents pet, and will not chase the player. It should ignore/cc the pet, then chase the player that started the attack until they are dead regardless of other people attacking. Of course, rotation would be healer class first, then dps, then tanker. -- Note: This is a recommendation for World PvP only. Additionally, when fighting druids, the bot should do everything it can to avoid fighting on a cliff as the druid can "blow" then off.

And finally, if ANY of the above problems occur, and there is no "fix", at the very least, play a sound and allow for manual control to get past the situation (in other words, try to do the quest or whatever, but if you detect something is going wrong during the process then pause the script, make a loud noise, and allow user control.

And as for log files --- I am 100% positive, that the above has been submitted (probably on separate occasion) for most of the issues presented here. The remainder issues are not specific to any particular quest/objective/etc and are in fact encountered during the general operation of the bot. Level a few toons from 1-90 and you will encounter EVERY SINGLE issue presented above. Given the amount of crashes, stops, starts, and running multiple, it is near impossible to identify which log files are for what. TBH, I just nuke em when the folder reaches over 100 log files (same with cache, and compiled junk since on every start, the bot wants to recompile EVERY addon, etc).

 

[chinajade]

Hi, Hackersrage,

1. Is frequently an issue with corrupted-caches. We need a log to make the determination for certain. But, there's nothing a profile writer can do about this. I'm not sure even Honorbuddy can, because the corrupted caches frequently belong to the WoWclient and not Honorbuddy

2. You just can't "move on". Most of these gossip quests are part of quest chains, and moving on would make later profile elements fail too. The best that could probably be done is "log out" rather than "move on".

3. Evading mobs are the responsibility of the Combat Routine (CR). If the Combat Routine is not handling this correctly, a bug report needs to be generated (with a log, of course) into the appropriate CR thread.

4. Again, a cache-corruption issue.

6. Again, a cache-corruption issue.

7. The Combat Routine would need to be 'smartened up' to do this. I'm sure its on the agenda of several. There are also existing Plugins that will do this. If you have a favorite CR you like, try making a [Feature Request].

10. This is a profile bug. Profiles should be written to be Honorbuddy stop/start friendly. You should give specific feedback to the profile writer in his thread. By specific, we mean provide information as to "which completed quests were lost", and "what caused you to stop/start Honorbuddy"--not "hey, Nagrand is broke--it drops all my quests". You will of course need to attach a log when reporting such errors.

11. Is a design decision by the profile writer. The other side of your request is "do all the quests, so I can get achivements--Loremaster, Zone exploration, zone completion." It is up to each profile writer to determine the design goals he chooses to pursue. If you don't like a particular profile writer's design decisions, go find one that you agree with.

12. I completely agree with you on this--the decision should have been left to the user and not the profile writer.
I talked with Natfoth about this today, and they are aware of the Community desire to change this. But, in the overall list of things that need to be repaired with Honorbuddy, this is waaaaay down at the bottom.

13. All your points here are specific to Combat Routines. Combat Routine authors also have to make design decisions. Some tune for survivability in PvE, some tune for max damage in PvE (which competes with survivability goals), some tune for PvP, etc. You will just need to locate a Combat Routine that fulfills your needs. Alternatively, you can provide feedback to an existing CR author in the hopes of getting it tuned more to your liking.

---

Overall, your points are very good. There are work-arounds to some of the issues. Sounds like you frequently bump into cache-corruption probems. To repair such corruption, you must clear all three caches as follows:

• Shut down WoW and Honorbuddy
• Delete the WoW/Cache/, WoW/Data/Cache/, and Honorbuddy/Cache/ directories
• Restart WoW and Honorbuddy

Caches can get corrupted a few of ways:

• You switch toons, or do a quick log out/in, without restarting Honorbuddy
• You simultaneously run multiple sessions of Honorbuddy from the same directory on disk
• There are other (user caused) triggers, but these are the most common.

Your issues cover a whole spectrum. Some bugs will need to be reported to Honorbuddy proper (Honorbuddy Bug Reports thread), some need to be reported to particular Combat Routine authors, and some to Profile writers. Getting things fixed requires identifying specific problems (and attaching the log) on a case-by-case basis. Reporting specific problems is tedious, but take solace that capturing and reporting a problem fixes that problem for all.

cheers,
chinajade

 

[Aroxan]

can I hear a hooplah for everything hackersrage said?

 

[chinajade]

can I hear a hooplah for everything hackersrage said?

Actually, no.

You both need to get busy reporting specific bugs to the appropriate places, and attaching logs.

Just complaining adds zero value, anywhere.

chinajade

 

[hackersrage]

@chinajade

Thank you for your response.

1 - Emptying cache does not resolve this issue. Admittedly, it does resolve some problems on some occassion where the cache is to blame for the problem, however this is a first step process for each time that this occurs --- I nuke cache, temp, etc etc to cleanup any corruption -- heck, even run a defrag, and nein.

2 - I disagree. The logic is currently setup to "FORCE" accept prior quests. I would like the option to disable this. Programmatically, detection can be implemented to see if an NPC has ##### Quest available, similar to the detection of completed quests. If the quest is not available, then skip, and move to the next quest objective. In Kick's scripts, most (if not all) quest objectives are wrapped inside a condition <if on quest then> do objective </if> [pseudocode]. So if the "FORCE" accept prior quests was an option, I am sure his script could manage the skipping portion.

3 - I will notify the CR (Singular) regarding this. Could you please answer this though, there are additional routines that come with Kick's as well as others that are not a "Routine" per se, however they appear to affect combat, or natural flow of encounters --- so are you sure this would be a Singular issue only, or would ALL CR's need to be notified of this. Additionally, Evading mobs are never in a "specific" location at all times, and thus the simple <if X mob exists at ABC,XYZ,Z>ignore</if> would not work, as this is not simply a game glitch, but is a mechanism which is used to detect and "trap" botters.

4 - If only it was a simple cache issue. This is usually from a game bug server side, and is suspect to another mechanism used to trap botters. Detection of such occurances should be in place and a "move on" mechanism should be allowed as per my OP, and #2 in this response.

5 - Remains unaddressed. I sincerely hope for a fix for this as it has been the cause of numerous deaths, quest failures, quest abandoning (if bot didn't auto-stop to "re-authenticate" it would not matter if the script itself could handle stop/start in that zone/quest chain)

6 - Also, seems not to be a cache issue. This will occur whether or not I have completed cleared the cache (and yes, I close all sessions of WoW and the bot prior to dumping the garbage)

7 - I agree, a CR issue. Please see #3 regarding if this is a general issue, or who exactly needs to be notified of such occurrences or how to determine who. Is it core Singular, or "Quest Behaviors" or other.

8 - Again, I suspect this is a combat issue, but it is mixed with pathing and auto-targetting of "near" mobs based on the last mob it just killed. For example, I can control the direction of my bot from another toon by killing mobs in a "path" which could cause the bot to stray considerably far from the quest objective(s) -- turning off loot mobs is not really a good idea as, well... then you won't get any loot ^.^ ---

9 - From what I understand, this is supposedly parsed from the meshes which (if similar or are the extracted map data from the MPQ's) determine the location of fixed GO's, elevation, and barriers, so if a scripters path leads to a wall, this should be automatically course-corrected by the core of honorbuddy using the data from the "meshes" ?

10 - Lucky day, just as I was writting this, started up a bot, and boom, all quests that were completed were dropped. See attached log. This is not the only location this occurs, and although rarely, it seems it can occur anywhere, on any quest chain. So I would be highly suspect this is an error in how the script is being parsed or perhaps an invalid response from the server regarding progression on a chain, or it could be the core can not continue certain chains mid-way due to the whole "FORCE" mechanism in place (which should be toggleable - ideally)

11 - I am not sure how one would go about setting automatic profile switching based on level, and then hand in ONLY the completed quests at that point, then move to the next zone. Kick's scripts work very well, and he does have conditions all over the place checking if a quest is grabbed, then grabbing if not, then checking if grabbed before doing the objective and before attempting to pickup the next quest. Unfortunately, the core ignores this request sometimes, and FORCE grabs the prior quest (even if not in profile, as i have DELETED problematic quests entirely before), instead of just trucking on to the next quests available.

12 - Definitely more detail here would be awesome. Currently, I have to edit every one of kick's scripts as the defaults he has chosen to sync in the SVN, end up vendoring cool stuff like trinkets that yield companions or do special things (non-combat), and white items (companions, cloth, etc) ... and then mails all greys XD .... I have made a request to change this twice now on his thread, but I do not forsee something happening soon (nor do I expect it).

13 - Singular, is an excellent routine, and fullfils my needs for the most part. It doesn't seem to focus on any of the above methods as I have often found myself surrounded by mobs and AoE'ing more, while other times, it runs from them. I know in LUA, you can use something like IsPlayer, and IsHostile together with IsPlayerPet, etc. I will take this up with Singular and see where it goes. The author is very active.

ps -- all "hooplahs" welcome. This isn't random ramblings of someone who has not gone through rigorous troubleshooting steps (including posting logs, reading similar issues from others, etc) and just blasting. This is well tested information which if there were a formal bug submission system, I would submit the tickets individually there. There is more than enough information supplied in each case to reproduce the issues I brought up.

View attachment 77480 -- 20 MB of logging which shows each of the above issues experienced, and events occurring prior (if any).

 

[Sphjunior]

Is there anyway to turn off vendoring? I don't want the bot to vendor anything at all.

 

[loliceman]

Sorry for being a tad rude now, but i don't know how else to put this..

It seems you'r setting really high hopes/goals for this bot.

in my world, a programwritten "bot" can do simple things for you in a game, play a BG, level a toon, vendor your stuff, farm some herbs etc... And with a bit of advanced features ofcourse (quests,Archbuddy,PB,AH bot etc.) And you should be happy about that.

Trying to achive a programwritten bot that costs like 20-25$ to "not run so close to a cliff, because a druid might blow you down" is just plain sillyness.. I rest my case

EDIT: About nr 3 on your list, I'v used both Dunatank CR, MAD CR, Singular CR, Superbad CR and lots of other, they all try to attack the evading mob for like 15-20 secs, then the log clearly says it blacklisted and it moves on without any problem.. I dont know why you have this issue.

Also, Kick and all the other profile writers have never stated that a "quest 85-90" profile was ever fully AFK. bugs come, bugs go, deal with it, Find workarounds

 

[chinajade]

Hi again, Hackersrage,

1. If cache-clearing doesn't repair the problem, then the problem is either an Honorbuddy bug, or a behavior (e.g., InteractWith) bug. I've also seen a few instances of misbehaving plugins interfering with proper operation. To diagnose the problem, a log would be needed each time the problem happens. Such bugs would need to be knocked down one-by-one as they are reported.

2. I believe you misunderstand how Honorbuddy works on this one.
The word "Force" is a misnomer used at one point in Honorbuddy's development cycle, and the method names have never been corrected. The point is, if the quest is complete, Honorbuddy is supposed to know this before even traveling to the quest giver. Thus, the quest should be skipped if it is complete--period.
The If wrappers around Objectives, will cause the objectives to be skipped if you don't have the quest in your log. The quest might be in your log because you've already completed it (a good thing), or because the giver didn't offer it because you failed to turn a pre-req (bad, and this is your point).

But skipping quests in this way could easily cause 30-40% of the quests in the zone to be skipped. Why?

• Because that quest was directly part of a chain
• Completion of the quest allows other quests to open up that will now be skipped
• Completion of that quest provided rep that is needed to open up other quests.
• Completion of that quest counted towards the experience expected out of the zone
  And, lack of sufficient experience prevents you from moving to the next zone because you don't meet level requirements
• etc.

We've already seen that user's that don't know what they're doing easily damage Honorbuddy. The latest example is several users updated their Weight Sets with a contribution that had bad XML in it. This prevented Honorbuddy from turning in quests, because it could not evaluate the rewards due to the damaged XML in the Weight Sets.

IMHO, we should be finding and fixing the root cause of the problem, rather than putting a bandaid on it by 'skipping' quests that are supposed to be available.

I do agree with you that corrective action should be taken after three or so failed attempts at NPC interaction--rather than opening and closing a dialog all night. The only viable corrective action I can think of at the moment is to "log out".

3. "Evading" mobs are always the responsibility of the Combat Routine.
An evading mob can only be detected once combat starts. The Combat Routine should be blacklisting, and de-targeting such mobs (and perhaps 'stepping away' from it, if in melee range). If the mob is blacklisted properly, Honorbuddy should ignore it, and move on. You will be in combat, so 'moving on' may be on foot, rather than mount.

4. I agree there should be an 'upper limit' on attempts to loot anything. This may require corrections to Honorbuddy, it may be a quest behavior bug, or it may be an interfering plugin. Again, the issue would need to be reported on a case-by-case basis to triage, and isolate the problem.

5. From looking through hundreds of issues in the Support forum with respect to this issue. It usually boils down to one of three things in this order:

• AntiVirus issues
  Yes, AntiVirus can cause intermittent problems with connectivity.
• People are doing stupid things, and effectively 'corrupting', their hosts file
  Yes, the damaged hosts file can cause these intermittent disconnect problems due to the fallback algorithms.
• WiFi issues
• ISP issues

Honorbuddy uses multiple, redundant paths to the authentication server. It has robust fallback mechanisms. When Honorbuddy reports an 'authentication' error, it has already done some rather amazing things to try to maintain/re-establish the connection. I've never seen a case of this, where the problem wasn't on the user's end.

The 'authentication' check is necessary. It is a heartbeat to tell the server 'yes, this session is still alive and in use'. Without it, the HBAuthServer would never notice when the HBclient has crashed, and release the authentication credentials for use in another session. It usually takes the HBAuthServer 2-3mins before it will 'call it', on a crashed session.

6. Can't speak to this. I've never encountered an issue (or in the Support forum) where this wasn't completely a corrupted cache issue. If you encounter this, and clearing caches doesn't work, I'd definitely say that you've found an Honorbuddy bug. You would need to wrap up your log, and the cache *.cqc files, and make a report to the Honorbuddy Bug Reports thread.

7. The behavior could be placed in a plugin, but the responsibility really belongs to the Combat Routine.
The decision of whether or not to get out of the AoE depends on a lot of things, such as:

• Your class (melee vs range)
• Role (tank vs non-tank)
• Environment (raid vs instance vs general world)
• Damage you're currently taking vs. the lost DPS while you move
• Whether the mob you are fighting is ranged, or melee
• Terrain features and doodads around

Its not an easy problem to solve competently, but the responsibility is really the Combat Routine's.

8. This responsibility belongs to Honorbuddy. And, as we all well know, the AvoidMobs profile element is laughably misnamed.
This also is not an easy problem to solve, as it involves:

• Analyzing the current POI in the context of both the terrain, and mob placement on the terrain
• Analyzing not only static, but patrolling mobs, in the previous context
• Your level versus the surrounding mobs (aggro range evaluation)
• If mobs must be engaged, deciding which pack(s) to dispatch would result in quickest path to POI
• Deciding would it be better to 'mount up', and 'run through', to get to POI, instead of engaging mobs

This is not above the skill levels of the HBdev team, but due to the effort involved, I'm sure its not very high on their priority list, either. There is also a significant performance penalty to conduct such an analysis as you travel, and it may be enough that such a feature would never be considered. Since, the cost/benefit ratio would be too high.

9. Not all data is contained in the meshes.
Obviously, the terrain is, and some buildings. But the rest of the information is loaded as 'doodads' (yes, they're actually called this, and its a technical term. ). Doodad information is provided dynamically from the server. This includes mailboxes, 'decorations' such as wagons and fences, seasonal decorations and signs, etc.
Honorbuddy cannot 'see' doodads other than by doing raycasts. Raycasts are frequently needed, but relatively expensive operations to conduct.

10. Again, this is a profile bug, and the specifics should be reported to the appropriate threads.

11. Again, these are profile design decisions.
Your doing so much editing because you don't agree with his decisions. "Completionist"s like me, however, like the decisions. If the questing profiles were 100% AFKable, it might not even be such a problem for you either.

It sounds like you are a mismatch for using Kick's profiles, and you need to seek another author that uses design principles more closely aligned to your preferences. If you choose not to do this, then doing what you currently are--adjusting the profile to what you like--is your other choice.

12. As previously stated, HBdev is aware of the issue, and its waaaay down on their "to do" list.
This means that writing a "Plugin" is the only real solution to a more timely work-around.

13. Bobby53 is simply the best. Super-smart, hard-working, generous, respectful, and humble.


I'm probably not going to respond to this post again, unless it breaks down into a 1-2 topic discussion. Discussion 13 issues at once is just too time-consuming, and most probably treat as TL;DR.

cheers,
chinajade

 

[hackersrage]

@chinajade

Thank you for clearing up who is responsible for what. Some of the issues, the responsibility was admittedly pretty clear where others had a very fuzzy view as to who to inform.

With regards to Kick's profiles, I do like them, however I wish that he would centralize the loot directives as they are the same across all files (or appear to be), this would help to better maintain this and for users like myself who do update from SVN, that it ensures that there are no mismatches/etc when a significant change to the core scripts is done.

I will keep this in mind regarding the CPC cache attachment with logs, however, if I may suggest that Honorbuddy create a thread for such submissions so this data is not publicly viewable, cached by google, forever, online. It's not a difficult issue to grant moderators full access to such a thread, while making it that users can post, but only see their own thread -- and not the rest of the world. If needed, I can give instructions on how/where to do this in vBulletin 4 Admin CP, but from our conversations, I know you are also technically versed, and most likely do not need such instruction.

With regards to the Raycasting for doodads .... I remember when running a server, that such objects fell under the GO's (Game Object) category, which there were two types. Interactive (such as mailboxes, quest items on the ground, signs, etc), and non-interactive (boulders, some trees, decorations, etc), both of which were drawn with GUIDS when they were not something directly present as part of the mesh/map. When the bot does it's raycasts, is it locating these based on GUID, or is it more like a sonar trying to see if there is anything to collide with which is not part of the world map. Further, when I am speaking of the collisions, I have not really noticed any issues with GO's (or doodads), but more with integrated world objects that are directly part of the map such as a mountain.


@Sphjunior - I do not know of a way to turn off vendoring completely, however, you could add the following inside the XML (profile) file after <HBProfile> but before the main part of the script begins. Do not edit unless you know what you are doing, or are not afraid to "break" it while trying to figure it out. Once done, you can simple change "true" to false in each of the tags you don't want it to do.

	<MailGrey>False</MailGrey>
	<MailWhite>True</MailWhite>
	<MailGreen>True</MailGreen>
	<MailBlue>True</MailBlue>
	<MailPurple>True</MailPurple>
  
	<SellGrey>True</SellGrey>
	<SellWhite>True</SellWhite>
	<SellGreen>True</SellGreen>
	<SellBlue>False</SellBlue>
	<SellPurple>False</SellPurple>

@loliceman - I do not find anyones opinion rude, as it is your opinion. My argument is for improvement as all software can always be improved, and it is our duty as the user to report any issues and to provide as much detail on how to reproduce the issue in order for the developers to resolve. HonorBuddy takes pride in the development of their software (as do the scripters, and profile writers), and if they are anything like me (when I write code), they strive to improve it. As a lot of time is spent in the design of such things, minimal debugging can occur, so the user becomes the beta-tester. I am merely pointing out some of the more critical issues that I have personally noticed and how to reproduce in general, with the occasional suggestion as to what might prove to be a better way to improve the script overall.