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

Honorbuddy 2.0 - Navmesh and Questing Release Schedule

I was curious about the questing rewards and how they would be handled.

If the quest reward is something that is better then what you are currently using, take that and equip it.
If the quest reward is not better then something you are wearing, then take the highest vender valued item .
 
I was curious about the questing rewards and how they would be handled.

If the quest reward is something that is better then what you are currently using, take that and equip it.
If the quest reward is not better then something you are wearing, then take the highest vender valued item .

Correct. I don't know whether the weights will be autoset or user-supplied, but ideally that is how it should work.
 
Soo, when will you guys send me a beta to test out the HC RAF logic?
^^
 
After you waste an entire bgs running after mounted targets, your bot is bottom of the dps and healing chart and you have endless folk whispering you "w t f are you doing!?"

CCs can't handle this - if an account gets reported, suspended or banned for PVP Exploitation, the users (rightly) blames Honorbuddy for not protecting him. Our existing logic protects your account while you sleep. Allowing toons to chase mounted targets removes that protection. Its not happening.


I'm with the others on this one, I'd certainly like to have a crack at this.
 
After you waste an entire bgs running after mounted targets, your bot is bottom of the dps and healing chart and you have endless folk whispering you "w t f are you doing!?"

CCs can't handle this - if an account gets reported, suspended or banned for PVP Exploitation, the users (rightly) blames Honorbuddy for not protecting him. Our existing logic protects your account while you sleep. Allowing toons to chase mounted targets removes that protection. Its not happening.

Well.. maybe you should add the support for it in the CC's, and make some sort of a rule, that any CC dev who changes the logic in the CC puts a "disclaimer" in the topic that not HB nor the CC dev is responsible if the users enabled the feature?
I know some people would just want to risk it, depending on how good the logic the CC dev implement, the risk may vary :)
 
I sent this to Hawker for consideration earlier. I believe not allowing us to override this can cause more problems then allowing us to.

1. You say that it couldn't be done, but I already have logic that would work with it in my CC (untested, since I've never been able to override it, but it should work)
2. You mention that it would look extremely bottish, but CC devs have access to many other functions that look bottish. I can write into nav a loop that just makes it run in circles, but I don't. Its all about using it correctly.
3. Examples of why its useful (I've seen all of these in a single day):
- A lone rogue is mounted with 20% hp and runs past me, bot targets, ignores. Easy kill, and loots bottish.
- Bot is mounted and running down av with a pack of allies. Horde force is mounted in front. Allies dismount to attack, bot runs through
horde and gets slaughtered. (this happens a lot)
- Bot runs past a person that is mounted, standing still, not moving. Extremely bottish.
- Bot runs past a person that is mounted, person turns around and chases down bot, attacks. Only then does the bot react, effectively
never getting the first hit in.

All of these can be fixed by letting us override the mounted target ignore, and using it safely won't be hard. See code below that is pulsed every combat() iteration:

Code:
        #region Battleground Blacklisting
        public void bgTargetCheck()
        {

            if (Battlegrounds.Battlegroundstatus == BattlegroundStatus.Active)
            {
                if (Me.GotTarget &&
                        Me.CurrentTarget.IsPet)
                {
                    slog("Battleground: Blacklist Pet " + Me.CurrentTarget.Name);
                    Blacklist.Add(Me.CurrentTarget.Guid, TimeSpan.FromDays(1));
                    Me.ClearTarget();
                    lastGuid = 0;
                    return;
                }

                // test, if in battleground and someone is out of line of sight, blacklist for 5 seconds
                if (Me.GotTarget && !Me.CurrentTarget.InLineOfSight)
                {
                    slog("Battleground: Target out of Line of Sight, blacklisting for 3 seconds");
                    Blacklist.Add(Me.CurrentTarget.Guid, TimeSpan.FromSeconds(3));
                    Me.ClearTarget();
                    Lua.DoString("PetFollow()");
                    lastGuid = 0;
                }

                if (Me.GotTarget && Me.CurrentTarget.Distance > 29)
                {
                    slog("Battleground: Target out of Range (" + Me.CurrentTarget.Distance + " yards), blacklisting for 3 seconds");
                    Blacklist.Add(Me.CurrentTarget.Guid, TimeSpan.FromSeconds(3));
                    Me.ClearTarget();
                    Lua.DoString("PetFollow()");
                    lastGuid = 0;
                }
                // if target has bubble up, blacklist for duration
                if (Me.GotTarget && Me.CurrentTarget.Buffs.ContainsKey("Divine Shield"))
                {
                    slog("Battleground: Target has Divine Shield, blacklisting for 10 seconds");
                    Blacklist.Add(Me.CurrentTarget.Guid, TimeSpan.FromSeconds(10));
                    Me.ClearTarget();
                    Lua.DoString("PetFollow()");
                    lastGuid = 0;
                }
                // if target has iceblock up, blacklist for duration
                if (Me.GotTarget && Me.CurrentTarget.Buffs.ContainsKey("Ice Block"))
                {
                    slog("Battleground: Target has Ice Block, blacklisting for 10 seconds");
                    Blacklist.Add(Me.CurrentTarget.Guid, TimeSpan.FromSeconds(10));
                    Me.ClearTarget();
                    Lua.DoString("PetFollow()");
                    lastGuid = 0;
                }
            }
        }
        #endregion
 
Last edited:
Aiobot is the first public bot to have questing implemented into it not HB, but AIO has the creaters of mimic running it so no one uses it and Cypher and kynox destroyed it security slating it very shit and it uses another games protection against warden GAMEGUARD rofl

Actually PPather with Mmoglider could quest. - so has been done before
 
I am worried about the way questing will work. Just because if you want to make a profile following a guide it's gonna be a bitch choosing what quests not to take. They only tell you what quests to do. Also will it support picking up a bunch of quests that are in the same area and go do them? Or is it going to be: Quest - Turn In - Quest - Turn In?
 
ok so we are getting the pvp version then it says works as a level bot 99% of the time, then the week later is the full navigation, what does that mean?
does it mean from tomorrow we can use it to grind then bg then grind or just bg's?
 
As you all probably noticed, we have been very quiet about the set of upgrades we have called HB2.

A few weeks ago, it looked like we were ready to release a preview. However, the "small" bugs that we needed to fix were not small, the PVP changes in patch 3.3.3a have taken a lot of coding to build in and generally the releases have been delayed.

The four main changes we are working on are:
1. A vastly improved navigation system that doesn't require you to record a navigation mesh.
2. PVP support of random battlegrounds including intelligent Strand of the Ancients and Isle of Conquest logic.
3. An improved plugin system so we can create an app store selling features like Gatherbuddy integrated into Honorbuddy.
4. Questing.

Our current status:
Navigation works most of the time but has some issues on long trips, say from Booty Bay to Light's Hope Chapel. Toons in Northrend that need to move from Dragonblight to Sholazar Basin at level 75 fail to make the journey. Main has worked out how to fix this but it will take some time to implement and test.

Strand of the Ancients, Isle of Conquest and Random Battlegrounds all need a few small changes but are ready.

The paid plugin system is on hold until all the other elements are in and working.

Questing is not working. The bot picks up quests and hands in quests but it needs navigation working perfectly to do the quests correctly.

Our release schedule:
Monday April 19th - PVP release that supports all battlegrounds and supports random battlegrounds. This will use the new navigation system so it will work as a levelbot 99% of the time.

Monday April 26th - full release of navigation. This release will have all the existing Honorbuddy profiles supported and making new profiles will be a cinch.

Monday May 10th - questing. The current design is that if you enable questing, the bot will automatically pick up quests and go do them. Profiles will need to be adapted to list quests you do NOT want it to take.

Monday May 31 - paid plugins.

This is a significant set of changes all of which will have issues. There will likely be lots of releases with bug fixes in between the dates above as we fix the problems that you find. But, its fair to say the bot will be technically great and a pleasure to use by the time we are done. Thanks for your patience and for the future bug reports.

EDIT 1 - pyromess pointed out I had a date wrong :S Fixed.


Outright shocking and amazing. Keep up the updates/status it really keeps the customers happy! You guys just turned around things on my end. I fully support you now if this is the kind of customer service I will be getting. Keep it up! Positive changes provide positive responses and support from your customers even when something was to go wrong... because you kept us in the loop. We want to feel part of that.
 
As I've read the blogs, the CC's that are in .dll form will not be supported by HB2.
May I ask what is the reason for this step by the developers of HB2?

This will mean FPSWare's, Mordd's, Nesox, and DarkBen's CC's will NOT be working with HB2 (TheOneCC, Convalesce, Cimmerian, Khryses, DBWarlock amongst others).
These are all the better more complex CC's and also nearly all CC's I'm using the most of all of the released CC's.

A answer would be greatly appreciated.
Regards, Liquid.
 
As I've read the blogs, the CC's that are in .dll form will not be supported by HB2.
May I ask what is the reason for this step by the developers of HB2?

This will mean FPSWare's, Mordd's, Nesox, and DarkBen's CC's will NOT be working with HB2 (TheOneCC, Convalesce, Cimmerian, Khryses, DBWarlock amongst others).
These are all the better more complex CC's and also nearly all CC's I'm using the most of all of the released CC's.

A answer would be greatly appreciated.
Regards, Liquid.

Its hard for me to comment on this since I was on the side that wanted DLL's, but the decision came from the top of the project. As for their reasoning, to sum up: There are no advantages to using a DLL that outweigh the possible disadvantages. Whether or not they want to comment further is up to them, but to the best of my knowledge this hasn't changed.
 
Its hard for me to comment on this since I was on the side that wanted DLL's, but the decision came from the top of the project. As for their reasoning, to sum up: There are no advantages to using a DLL that outweigh the possible disadvantages. Whether or not they want to comment further is up to them, but to the best of my knowledge this hasn't changed.

I'm with Ski on this one - obviously. I won't go into detail I'll simply say ski has summed it up nicely.
 
Last edited:
Seeing as how fpsware already said his "The One CC" is currently working in HB2 and is heavily reliant on it, I suspect that the HB2 version is no longer a DLL.
 
Seeing as how fpsware already said his "The One CC" is currently working in HB2 and is heavily reliant on it, I suspect that the HB2 version is no longer a DLL.

Its running my source code. Though, I won't be releasing it in this state. but as for what "state" it will be released in I don't yet know.
 
As for their reasoning, to sum up: There are no advantages to using a DLL that outweigh the possible disadvantages.
Well, let's sketch a situation...

I get my hands on FPS's CC, but I don't like how something works.
With my unlimited knowledge (of how I get a pizza out of the oven, and the french fries and a burger from the MaC) I start changing stuff around in the code below the part that says don't change anything below this line.
Then it breaks (what a surprise) and I want support from FPS.
FPS is pulling out those last few hairs he has left to figure out wtf is wrong.
It was not him, it was me.

This would not happen if it was a dll that I can't touch.

Support from the developers of the CC's that are in dll would be much more accurate and easier than when it's a .cs file where every dick with a stick can start deleting and adding items.

I would say that's a pretty "pro .dll CC's" argument where all coders can find themselves in that distribute their CC this way.
 
Back
Top