What's new
  • Visit Rebornbuddy
  • Visit Panda Profiles
  • Visit LLamamMagic
  • Visit Resources
  • Visit Downloads
  • Visit Portal
RebornBuddy Forums

Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!

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

Dungeonbuddy Farm Mode, being able to farm more than a single dungeon on a row, like for example after ticking 3 or 4 dungeons the bot would sequentially or randomly farm each of these selected ones in a loop.

Or if this is too much hassle to code, maybe adding an API option to be able to control Dungeonbuddy current selected dungeon, through PB profiles or a custom plugin.

Thank you :)

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
 
AutoEquip is controlled by the user, as it always has been. DungeonBuddy has absolutely nothing to do with this.

Honorbuddy does not ship with an "AutoEquip" plugin, you should probably do a 'clean install', if you've such cruft remaining around.
[post=1120664]HelpDesk: "Clean installing" Honorbuddy[/post]

To disable AutoEquip,
Honorbuddy
→ "Settings & Tools"
→ Uncheck "Auto Equip" under the CharacterManager group​
I'm not sure I understand the reply to my post, doesn't seem to be addressing what I mentioned, but whatever.
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: [post=1120664]HelpDesk: "Clean installing" Honorbuddy[/post]

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?


New idea:

Does the bot always vendor before mailing or is that a kicks profile thing? Would make immensely more sense to mail before vendoring. Would simplify dealing with BoEs and BoP gear you get for leveling purposes.

As it stands now, you can only either trash all Greens or mail all greens. Would be better to be able to first mail all BoEs, then vendor any quest greens.

But again, that may just be a profile thing and not a bot thing.
That order is fixed and cannot be influenced by a profile

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
 
Last edited:
The update to isle of conquest bg buddy, now makes them wait in keep even longer than before, then rush docks. cant we rush docks without a delay as horde?

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: [post=378165][Guide] How to attach your log[/post]

cheers,
chinajade
 
Please could you support both Me.HasAura and HasAura, basically you support HasQuest but not HasAura, would be great for consistency as sometimes I don't know whenever to put a Me. in front of it.

Small suggestion..

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. :D

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:

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
 
Last edited:
I'm not sure if blacklisting Evade-bug type mobs is done by HB or the CR, but if it's done by HB I'd like to request a feature be implemented that learns a mob is Evade-bugged (can't be attacked, but bot just keeps attacking it anyway and often times just get stuck attacking the evading mob until user manually stops it) and blacklists it so the bot can move on with what it was doing instead of just continuously attacking it infinitely until the user stops it.

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:

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
 
Last edited:
Would be awesome if I could recompile only the selected plugin while bot is running (not started) without having to uncheck any other plugins.

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.


Would be nice to have these items added to the protect list, they are items dropped on timeless isle which are of great help while grinding and the such:
Code:
    <!-- Advanced Items: Timeless Isle Utility (ordered alphabetically) -->
    <!-- iLevel:90 -->
    <Item Name="Book of the Ages" Id="103642" />
    <Item Name="Dew of Eternal Morning" Id="103643" />
    <Item Name="Singing Crystal" Id="103641" />

If it would be possible to add a condition that when you have more than 20 of those, the rest is deleted that would also be of great help since depending on how many hours you stay grinding it can few a bag with buffs easily.

If we could have something like:

Code:
    <!-- Advanced Items: Timeless Isle Utility (ordered alphabetically) -->
    <!-- iLevel:90 -->
    <Item Name="Book of the Ages" Id="103642" MaxAmount="20" />
    <Item Name="Dew of Eternal Morning" Id="103643" MaxAmount="20" />
    <Item Name="Singing Crystal" Id="103641" MaxAmount="20" />

Where the bot would check the "MaxAmount" and remove the extra would be awesome.


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., [post=753914][Plugin] Mr.ItemRemover2[/post]).

cheers,
chinajade
 
Last edited:
Support for Eye of the Storm for RBG's. The logic used for BGbuddy is pretty good and this is the only one that I've come across where it doesn't work.

Hi, Iamsonewb,

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


Also, I think an improved feature for BGbuddy would be to make it so it doesn't want to cap flags and bases at the start of the game (ie: Battle for Gilneas, Eye of the Storm) maps where you generally only want to leave one person at the base at the very start of the game. Usually not the biggest deal, but suppose I'm the only healer in my BG group, and he sits base to cap a base he doesn't even arrive at first, and then takes a couple seconds to load largest fight, etc.

You could probably build upon this to make it more class specific, like Tank specs capping using the default logic.

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


And another thing, it's annoying when I switch toons, I'll have to exit game and restart the whole bot/wow in order to get it synced up correctly.

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
 
Hey, I would love to see an option that varys a waypoint a bot takes. The idea behind this is, that the bot does not take exact same route all the time with certain profiles, but varys it's waypoint by a set amount, not too much, just to avoid the LCP detection.
Would be nice for quest and grind botbase.

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
 
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: [post=1120664]HelpDesk: "Clean installing" Honorbuddy[/post]

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?

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.

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

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
 
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: [post=378165][Guide] How to attach your log[/post]

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.
 
Last edited:
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.

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
 
Last edited:
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, 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.
 
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
 
Back
Top