HB ARCHIVES: Feedback for Honorbuddy Improvements--DO NOT DELETE!

Hi, Dmyoussef,

The feature does not currently exist because most people are after a mount or reputation that comes out of a particular dungeon. For instance, Deathcharger's Reins only drops in Stratholme, and Sporregar rep only comes out of The Underbog.

For those just wanting to gain experience, there is the "Random dungeon" feature. Can you provide more information as to why cycling dungeons to farm may be useful? Please keep in mind there would be a natural limitation that 'multiple dungeons to farm' would need to be on the same continent, since Honorbuddy does not do inter-continental travel.

cheers,
chinajade

 

Hi again, LowKey,

To your first point...
We believe we clearly answered your question, but you missed a key point → there is no "AutoEquip" plugin any more. AutoEquip is now built into Honorbuddy. It has been this way for several Honorbuddy releases, now.

If you have an (old) AutoEquip plugin in your Honorbuddy installation, then your installation is damaged and you need to do a 'clean install':

Ref: HelpDesk: "Clean installing" Honorbuddy​

The previous response also indicated how you could turn AutoEquip off to prevent equipping the BoE gear.

In what way was your question not answered?

To the second point...
Laria is spot on with this answer. The order is sell/mail order is selected and executed only by Honorbuddy. As we've stated many times (in other threads), a profile is not even running when Honorbuddy makes the decision to sell/repair/mail and starts executing that logic.

If you believe there is a problem in this logic, please open a ticket in the Support forum with a log that captures the issue. Please be very specific as to what you expected Honorbuddy to do (with particular items), and what you observed Honorbuddy actually doing. They will need timestamp references from the log. They will need to cross-reference this activity with the profile you are running to make certain the <SellGreen>/<MailGreen> settings are correct—so please attach your copy of the profile to that Support ticket also.

If the Support staff determines here is a problem with the sell/mail logic, then a bug report will be opened for development staff investigation and redress.

cheers,
chinajade


cheers,
chinajade

 

Hi, Kkoon,

Sounds like you want to report a bug, rather than suggest an Honorbuddy improvement.

For your issue, please open a new thread in the Support forum. They MUST have your full log that captures whatever incident you are reporting.

Ref: [Guide] How to attach your log​

cheers,
chinajade

 

Hi, Giwin,

As you know Honorbuddy has gone through many refactoring phases—shuffling responsibilities from one API object to others as Honorbuddy has grown in capability. We will admit that the Honorbuddy API does have such duplicated functionality, but this functionality exists only to maintain backward compatibility. Many of the developers want to rip the (now) 'incorrect' methods out to prevent confusion; however, Hawker stands steadfast that maintaining backward compatibility is not optional.

Honorbuddy does not intentionally introduce duplicate functionality. Allowing multiple ways to do the same action is considered *very* bad practice (unless it is to maintain backward compatibility).

You may find this reference useful in your endeavors:

Honorbuddy Profile Tag Attribute: Condition - Buddy Wiki​

It clearly shows "Me.HasAura(id)". If a method is found in the ProfileHelperFunctionsBase, then it will NOT be prefixed by "Me.".

Hope this clears things up.

cheers,
chinajade

 

Hi, Zeldrak,

Honorbuddy and the Combat Routine cooperate in this matter. How the logic works is:

• Honorbuddy selects a target and moves within "Pull Distance" of the target
  (Ref: Honorbuddy:What is PullDistance and TargetingDistance? - The Buddy Wiki).
  
  
• Once within PullDistance, Honorbuddy issues a Pull Directive to the CombatRoutine, then transfers control the CombatRoutine to dispatch the mob.
  
  
• Once the mob(s) are dead, then Honorbuddy takes control (from the CombatRoutine) again, and resumes going about its business.

If Honorbuddy core (HBcore) finds a mob blacklisted, it will not attempt to 'pull' it, and selects another target (or task to perform).

Since HBcore is not in control when the CombatRoutine is running, it is up to the CombatRoutine to detect an evading mob and blacklist it properly. Indeed, mobs only evade when in combat. When all the combat mobs are dead or blacklisted, the CombatRoutine's job is complete. HBcore will notice the blacklisting when it gets control again after combat, and act appropriately.

You may find this article helpful in understanding the delegation of responsibilities within Honorbuddy:

Honorbuddy:Honorbuddy Architecture - The Buddy Wiki​

So with all that said...
If a mob is evading and Honorbuddy is not "moving on", then this is a problem with your selected CombatRoutine. Such problems should be reported in the appropriate CombatRoutine thread.

cheers,
chinajade

 

Hi, NamedNoob,

Honorbuddy currently provides a "recompile all" functionality. The development staff cannot justify the cost-benefit ratio such a limited use feature would provide.

The development staff does not feel these items belong in the distributed Protected Items.xml file. These items are consumables and subject to excessive accumulation. Also, the items cannot be mailed or otherwise shared.

Although the MaxAmount idea is intriguing, the cost-benefit ratio cannot be justified to develop and maintain code to support three items out of the hundreds in Protected Items.xml.

For now, you are welcome to edit the Protected Items.xml file yourself, or look at a plugin to manage the items on your behalf. (E.g., [Plugin] Mr.ItemRemover2).

cheers,
chinajade

 

Hi, Iamsonewb,

We've created feature request HB-859 ("Support for Eye of the Storm for RBG") for this.

We've created feature request HB-860 ("Better logic for "capture the flag/base"-type battlegrounds") for this.

This is feature request HB-30 ("Allow the user to change routines without restart"). As a reminder, bug reports take precedence to feature requests.

cheers,
chinajade

 

Hi, Syunsi,

The Grind bot (and consequently the Questing bot's grind areas) already support the <RandomizeHotspots> attribute. It is up to the profile writer to take advantage of the feature.

GatherBuddy2 already provides for a "Randomization Factor" in its configuration.

cheers,
chinajade

 

I think maybe there's a communication issue going on here. I'm not saying the bot isn't working properly. This is the feedback thread, not the support thread and I understand that.

I'm saying the way autoequip works as it's built in to HB is worse than when it was a plugin. A lack of settings for the HB built in autoequip is what I view as the issue. Hence my feedback that explains how the settings could improve functionality.

Again, feedback thread. I'm not saying anything is not working properly. I'm saying the way it works doesn't make sense.

The way it is now gives people less options. I always think more options are better, hence why I suggested a small chage that could theoretically double the options users have.

I asked if it was built into the profile or HB because I didn't know. Since it's built into HB, it makes sense to suggest it here, as it would improve the bot.

 

Hey Developers,

I saw recently in an update that claimed you had fixed the problem where horde were sitting in base long long after Isle of Conquest had started. However, this is still a HUGE problem. I am currently farming IOC and Horde sits a solid 25-30 seconds PAST when the BG has started. I was hoping to see an update on this soon as it gives us a major disadvantage.

Thank you

 

Hi, Droban,

Please create a new thread in the Support forum regarding this issue. You will also need to attach your full log that demonstrates the problem.

Ref: [Guide] How to attach your log​

From this, the Support team will open another bug report, if necessary.

cheers,
chinajade

 

I would love to know what HonorBuddy plans on advising or editing their botting program to not use the click to move feature which is one method blizzard uses to track down the botters of World of Warcraft and uses it to perform the banning process on the account. I understand bans went our recently and Luckily I wasn't included in such bans but I am sure blizzard will find methods to ban users.

I want to know if Honor Buddy has Identified how Blizzard is identifying there are bots being used instead of people playing and see if they recommend methods to prevent further bans on accounts.

 

API Support for more functions, and where necessary - return structures containing the data (variables as specified).


Questing

Code:

SelectQuestLogEntry(arg1);
QuestLogPushQuest();

Battle.net

Code:

// Get current Battle.net status, message, and id
BNGetInfo()
// variables: presenceID, toonID, currentBroadcast, bnetAFK, bnetDND

// Get current Battle.net information about another player logged into battle.net.  Cross game support (for wow,  'gameName' = 'WoW')
BNGetToonInfo(presenceID)
// variables: _, _, gameName, realmName, faction, _, race, class, _, zoneName, level

// Get detailed information based on Battle.net ID of another player
BNGetFriendInfoByID(presenceId)
// variables:  presenceID, givenName, surname, toonName, toonID, client, isOnline, lastOnline, isAFK, isDND, messageText, noteText

Party

Code:

// Check if player is friendly, in WoW, and not in a state where you can't party or interact with them
CanCooperateWithToon(BNGetInfo(toonID))

// Check if player is in party
UnitInParty(toonName)

// Invite player to party
InviteUnit(toonName)

Recruit-A-Friend Specific

Code:

// Grant a player a level  (playername, how many levels -- currently this only supports 1 at a time so the value is always 1)
GrantLevel(name,1)

// Accept a level being granted
AcceptLevelGrant()

// Decline a level being granted
DeclineLevelGrant();

// Get cooldown on Summon Friend ability
GetSummonFriendCooldown()
// variables:  start,  duration

// Summon your friend
SummonFriend(name)

// Accept summon
ConfirmSummon()

// Do not accept summon
CancelSummon()

// Check if accounts are linked (current account plus target account)  ( sender is the remote player id ... not name )
IsReferAFriendLinked(sender)

Also, the ability to register events and have them call a native c# / . NET function when that event fires and wait for the code in that function to finish exiting before continuing would be fantastic.

 

you can call any lua function from hb.

 

Hi, Owen,

Your information is conjecture, a non-sequitur, and completely incorrect. If CtM were being used to track down botters, then all Honorbuddy users would be caught. Obviously, we have a very large user base.

The bot is a power tool, and like any power tool you can get hurt using it if you don't know what you're doing. Part of this understanding is knowing that if you bot, you will (eventually) get caught—either through player reports, not 'botting smart', or getting your account investigated for other reasons (i.e., bad luck).

Honorbuddy will change click-to-move when it becomes necessary and no sooner.

Sorry to be so blunt, but those are the facts.

cheers,
chinajade

 

Hi, Hackersrage, and thank you for the suggestion.

As Laria points out, these capabilities exist through LUA which Honorbuddy provides a straight-forward C# interface to use. If you are writing a Combat Routine, Plugin, Quest behavior, etc., it is relatively easy to wrap this LUA and cast the data in whatever form you need. This technique is even employed inside the HB API and many of the shipped quest behaviors to prevent unreasonable code bloat.

We understand that LUA is not nearly as fast as direct memory access. But, we hesitate to 'widen' the HB API unless a demonstrable performance problem is discovered. 'Widening' the HB API has significant maintenance concerns, and increases downtime on patch days.

cheers,
chinajade

 

I mainly use the combat bot. And often I wish I could make the bot change targets. Sometimes it will but sometimes it will switch straight back no matter how many times you try. I would like to see an option to change targeting so
that if I swap target the bot will attack the one I swap to until dead or until I swap again.

 

this seems like a routine issue, if you diable targetting in the CR then you should be able to pick the target you want....

 

id really love to see a bot for all professions inscription lw engineering blacksmith the creating professions also love to see bot arenas 2s 3s 5s 10s

 

the one thing i would love to see is 64bit hb as i get less frames in 32bit but i know it will never happen