[IDEA] New Quest Bot

[Bengan12]

So the problem is that kickazz has not impelemted a level check on every quest? and HB does not skip green quest automaticly?

 

[jim87]

That's the point of the last part of the discussion, yes. But rather than making one hundred checkpoints, a more dynamic bot would make a simple setting able to skip quests knowing their minimum level and thus difficulty (eliminating checkpoints at all).

 

[lickalime]

Well then there is something wrong with my questing then. If what your saying is true a course. Because i used kicks profiles 1-85 for a pally,warrior,mage and currently a shaman in full boa and g perk. my shammy is running around EPL at lvl 44 doing yellow quests. So if this bot and these profiles are as bad as you say then my 65k/hour is a what? accident. No matter the features of the bot if there are bugs then it wont run at optimum speed or be productive as a bot with less features and no bugs. I haven't made a questing profile yet but have done enough research and watched my bots quests enough that your idea of the bots logic on quest pick ups and completions make no sense to me.

 

[jim87]

Well then it's just me who's doing green quests till level 30 (Stranglethorn Vale). I used profession buddy to raise mining and herbalism to the same level of the character one's zones, still the bot ignores the level and does green quests, making much lower xp/hour. But it must be just me, right?

 

[Croga]

That's the point of the last part of the discussion, yes. But rather than making one hundred checkpoints, a more dynamic bot would make a simple setting able to skip quests knowing their minimum level and thus difficulty (eliminating checkpoints at all).

How do you make the bot smart enough to know that it needs to do some of the green quests because of the quest chain it will encounter in another level or 2?

Basically this entire thread is trying to move stuff that is currently in the XML to the C# code of the core bot. It doesn't change anything, it just gives the profile builders less choice.
If I have a level 85 toon that needs more guild rep, I can currently just set it to run the BC or LK profile, if the bot is "smart enough" to ignore green/grey quests I can suddenly not do that anymore. To me that's not "smart enough", to me that is "limiting what I can use the bot for".

Sorry mate. Some of the ideas in the OP sound nice (like the "check what quests are in the area and dynamically do them all at once" part, which IMHO is an utter nightmare to code and will probably give some performance... challenges) but most is just moving options from the XML into the C# code (again adding performance issues) and taking away the option to *not* have a smart bot.

 

[jim87]

It's really simple: bot configuration, do green quests? do grey quests? Yes/no. How could it know about quest chains? 'cause you write it, as I wrote some replies ago. Again, this is not hard coding any profiler choice, it's just making options, thus enchanting the actual bot system.

 

[lickalime]

to avoid doing green quests simply add more level checks into the profiles you download. But i do have to agree the option would be nice.

 

[Apoc]

So in short, you just want to be lazy and not have to put in the time required for questing profiles?

Sorry, but questing is not even remotely as simple as grinding. As I said before, I do want to add "multi-quest objective" type stuff later. But its low on the list right now until we work out some more major bugs.


You keep asking for us to add features we already have. I won't argue that the questing profile XML is a bit tedious, however simplifying it any more is only going to cause trouble in the future. (We allow you to do basically whatever you want, from a profile alone. Why would we take all that away just to re-add features we already have?)

 

[jim87]

I think that bot settings to allow dynamic quests skip would be better than making a checkpoint for every quest (because this is how you'd avoid green questing ATM), adding quest chain definitions (without it it's impossible to achieve this). You can even leave checkpoints where they are and add the possibility to add quest chain definitions to the profiles and add the bot options: if there is no quest chain definition and the user chooses not to do the green/grey quests, the bot will try to get quests of the chain in any case, but blacklist them if they're not on the gossip of the NPC.

 

[CodenameG]

I think that bot settings to allow dynamic quests skip would be better than making a checkpoint for every quest (because this is how you'd avoid green questing ATM), adding quest chain definitions (without it it's impossible to achieve this). You can even leave checkpoints where they are and add the possibility to add quest chain definitions to the profiles and add the bot options: if there is no quest chain definition and the user chooses not to do the green/grey quests, the bot will try to get quests of the chain in any case, but blacklist them if they're not on the gossip of the NPC.

it checks the checkpoint by level, not each individual quest. if we had it randomly skipping quest just because your heirloom put you a little higher then you needed for the quest, you would run into issues where it would skip parts of the chain, and just break itself.
we also support adding If's

so if you wanted to you could go If(Me.Level >= 30 && !Me.Quests.IsCompleted(1234)) then do pickup quest. blah dee blah.

* i didn't have the api so i couldn't tell you exactly*
but if you just use If's then you can make it skip or do or not do whatever the hell quests you want.

etherway theres no way to automate it and make one condition to rule them all, since wow is so varied theres no POSSIBLE way to for it to automatically know what ones to skip and do and not do, and what parts of the chain are what. we dont need to add more things that profile makers NEED to do.

 

[stevenr]

SO, WHAT DO YOU HAVE IN MIND?
My idea is a quest bot which basically COMPLETES QUESTS ONLY. What I mean is: I have X quests in my quest log, complete them. How? Take the hotspots of every quest, mix them all and then do the tasks. Where to find the data? From an external repository (could be HB website itself).

There is a way to put all quest in a IF-Tag. So you can pickup the quest you want to do by hand and start the bot.

<If Condition="HasQuest(12345)">
<Objective QuestName="Name" QuestId="12345" Type="KillMob" MobId="12345" KillCount="99" />
</If>

The board will not show my IF-Tag

 

[bft3912]

I have the basics of an automatic quest bot implemented, but its not quite ready for prime time. Here's the general concepts though:

There's two main classes on which the bot is built: SearchFor and FindNearest.

SearchFor is a definition of what you want to find. When creating a search, you fill in the priority, what game objects, mobs, etc you want to find, how close you need to get to them, where they are likely to be found and two behaviors. The FoundBehavior is a TreeSharp.Composite that gets run when you find a game object or mob and the NotFoundBehavior is run when the search engine runs out of places to look.

FindNearest maintains a list of SearchFor objects and moves the player towards the nearest (taking into consideration Flight Paths, Zeppelins, etc) and then runs the Found or NotFound behavior as appropriate. It pays attention to priority so that it doesn't follow a rabbit trail of low-priority Gather searches at the cost of the high-priority Escort search.

I found it useful to include a VisitDistance parameter on the search which defines how close you need to get to a node. When looking for ore, herbs or mobs to kill, I set this fairly high (60 yds) which is close enough to get the target on radar if it is there. When one of these items is found on radar, the FoundBehavior then starts another search for that specific GUID with a VisitDistance of InteractRange or PullDistance as appropriate and a FoundBehavior that will mine the ore, pick the herb or Engage the mob. Nodes that are Visited are moved from the KnownLocations list to the VisitedLocations list with a timeout that lets me put them back in the KnownLocations list after a certain amount of time has expired (very useful for farming mats).

For questing, the bot looks at the quest objectives for each quest and sets up a search that will meet the first undone objective. If it doesn't know where to go to find the mob, game object, etc. it uses the AreaPOI and the NavMesh to determine a series of points to search. Once there it adds anything it finds to the database so that the next time we do the quest we already know what to go kill/loot and don't have to poke around for it.

A quest scanner runs every bot OnPulse and looks for nearby quests to pick up or turn in. These are added to the search list just like everything else. In this way, the bot completes every nearby quest objective simultaneously. If you're supposed to kill 10 guards for one quest, and pick up something off 5 soldiers for another, it just does it as appropriate. A well-designed profile can do this too, but the FindNearest behavior allows it to happen more dynamically.

Some quests (vehicle quests, escorts, talk to so-and-so, etc.) need custom behaviors. I added these directly to the source files using a run-time attribute that lets me pull them out of the assembly at run-time and associate them with the correct quest and objective. This will eventually result in a fair amount of code, (though many are similar and can be generalized) so I'd be open to suggestions for reducing the code base.

In the future I hope to make use of the quest database that I'm accumulating to perform something similar to an A* search of the quest tree to find the quests that will provide the fastest combo of XP and gear, but figuring out dependencies could be a nightmare since many aren't explicit in the client db.

Performance: I've been pleasantly surprised at just how well it performs, both it terms of processing time and quest efficiency. It does run into situations where a well-optimized profile would perform better (i.e. if you complete quest 5 first, you can do 7 & 10 together), but there are also lots of cases where the 'do the nearest thing' mindset is quite efficient. When I started the FindNearest class I looked up a lot of information on the Traveling Salesman Problem and eventually just decided to implement a nearest neighbor search. This simpler approach has worked out pretty well so far.

I find that I prefer SearchFor/FindNearest over Hotspots quite a bit now. With a hotspot, the bot will always go to that spot to look and often skip something that is nearby to go to the next hotspot. A recent profile I ran had a bot wait for five minutes on the wrong side of a large tree for a mob that was within sight on the other side, but not within hotspot range. With a SearchFor, that mob would have been tagged as soon as the ObjectManager saw it and a search entered that would return the bot to that location even if we got dragged out of sight by combat/looting. Even if the ObjectManager hadn't seen it, the FindNearest behavior would let us do other nearby things while waiting for the spawn.

The FindNearest behavior results in a very organic flow from node to node. The path is similar but never quite the same and often takes a side path depending upon whether or not a particular node spawned.

I have quite a ways to go before I'm ready to point the bot at a level 1 character and let it run to 85 (taking breaks of course), but I feel good about the design and direction.

 

[mspazz]

Well then it's just me who's doing green quests till level 30 (Stranglethorn Vale). I used profession buddy to raise mining and herbalism to the same level of the character one's zones, still the bot ignores the level and does green quests, making much lower xp/hour. But it must be just me, right?

ignorequestcheckpoints="false" fixes that, by the way

 

[MrBig]

A good feature would be to drop XML profiles at all, and switch to a LUA based profile making. LUA is better at data structures, its better and processing stuff. Better at beeing used as a markup language than XML itself, plus the processing and custumization. And easier to edit, use.

But i guess I shouldnt feed the trolls, since they are already pumped up with too much caffeine and will flame you when you suggest new features that dig deeper than their little brains can grasp.

 

[Apoc]

A good feature would be to drop XML profiles at all, and switch to a LUA based profile making. LUA is better at data structures, its better and processing stuff. Better at beeing used as a markup language than XML itself, plus the processing and custumization. And easier to edit, use.

But i guess I shouldnt feed the trolls, since they are already pumped up with too much caffeine and will flame you when you suggest new features that dig deeper than their little brains can grasp.

Not exactly what world you live in where Lua is a markup language. (Especially given that XML is *only* a markup language [eXtensible Markup Language])


Lua will be no faster, and will only cause more issues since we'd have to write an entire parser to deal with it (thats assuming we come up with some form of structured table-system for profile writers to store things, which is just more confusing than what we have now)


If you're going to give reasons to switch to another language, please state *actual* reasons. (And not ones that are blatantly false, like Lua being a better "markup" language)

 

[jim87]

Not exactly what world you live in where Lua is a markup language. (Especially given that XML is *only* a markup language [eXtensible Markup Language])


Lua will be no faster, and will only cause more issues since we'd have to write an entire parser to deal with it (thats assuming we come up with some form of structured table-system for profile writers to store things, which is just more confusing than what we have now)


If you're going to give reasons to switch to another language, please state *actual* reasons. (And not ones that are blatantly false, like Lua being a better "markup" language)

The only alternative to XML I see here is JSON, which is as fast as XML (there are studies that demonstrate it's even faster to be parsed, and there are already libraries and maybe even C# ones (JavaScriptParser thing, should be there in .NET 3.5 too)), but more human friendly (XML is known not to be).

 

[Stormchasing]

For the Lazy ones i can try to rewrite a older app from me, which creates questprofiles from a trinity database

This database ISN'T very up do date, but with my little app i can create questprofiles for specific levels and with / without questchains.

this is a "very old" project, of a dead priv. bot, i 've written for our users, and there is some work to adapt it to a working version for HB profiles (because we've never used XML, we used c# for flexibility ... but that's not a major problem)

What it does:
- Load Quests from Database for a given level (0 means all levels)
- Load Quests from Database if they're Dropquests (Quests started by a dropped item)
- Load Quests from Database if they're in a Questchain (or ignore questchains)
- Show all related Quests
- Create a profile for the selected Quests

What it not does:
- it does not check for quests for a specific faction (no major problem... easy to implement)
- it does not check if your toon has done quest x,y or z .. because the tool isn't connected to wow (could be implemented, but there never were a need for this, because this is checked by the bot...)
it doesn't create lower quests if they are in dependicy with one of your currently selected quests... ( this "bug" is known by me, but weren't fixed, and after 2 years there wasn't a need to fix this bug, because the priv. bot is dead)

 

[Apoc]

The only alternative to XML I see here is JSON, which is as fast as XML (there are studies that demonstrate it's even faster to be parsed, and there are already libraries and maybe even C# ones (JavaScriptParser thing, should be there in .NET 3.5 too)), but more human friendly (XML is known not to be).

Its all in the parser, not the language. (You could argue that having plain C# is faster than both, but again, it gets you nowhere really.)


Also; JSON is not nearly as human friendly as XML. (Go look at the usual JSON output, and compare it to XML. You'll notice a stark lack of consistency between different JSON objects)

 

[jim87]

I've worked with both formats and prefere to work with JSON 'cause it IS more human friendly. And please don't tell me XML is... 'cause it's not (a human will never ever write tags to describe data).
In which way would you prefere to write your notes?

<mynotes><dinner><![CDATA[Today I'm going to have dinner with my wife]]></dinner></mynotes>

or

{"dinner": "Today I'm going to have dinner with my wife"}

? (hint: the 2nd)

JSON: The Fat-Free Alternative to XML (OK, this site is influenced by the fact it's the official site)
Tim Bray on JSON and XML - Don Box's Spoutlet - Pluralsight (some aspects about data handling)
Web Services: JSON vs. XML ? Digital Bazaar (a debate about JSON over XML)

The fact is that profiles are simple, and JSON is made for it, and even if they weren't, JSON would still be able to handle them. It's simplier than XML, it doesn't need to be extended, it doesn't need to have stylesheet layers 'cause in our case we don't have to. You don't have to write TAGs, it's all about "variable":"value". It has most of the pros of XML and others for sharing data, it's easier to write (and yes, you can still use whitespace as you like just you do with XML).

 

[bft3912]

Your example its very realistic for a profile. Which would you rather read?

XML:

<While Condition="Me.Class == WoWClass.Hunter &amp;&amp; !IsQuestCompleted(25139)">
	<If Condition="!HasSpell(56641)">
		<CustomBehavior File="ForceSetVendor" DoTrain="True" />
	</If>
	<CustomBehavior File="WaitTimer" WaitTime="1000"/>
	<CustomBehavior File="CastSpellOn" QuestId="25139" NumOfTimes="5" SpellId="56641" MobId="44820" X="-579.9462" Y="-4240.132" Z="38.17958" />
	<TurnIn QuestName="Steady Shot" QuestId="25139" TurnInName="Karranisha" TurnInId="39214" />
</While>

JSON:

{ "While": {
	"Condition": "Me.Class == WoWClass.Hunter && !IsQuestCompleted(25139)",
	"sub-elements": [
		{ "If": { "Condition": "!HasSpell(56641)",
			"sub-elements": [
					{ "CustomBehavior": {"File": "ForceSetVendor", "DoTrain": true } }
				]
			}
		},
		{ "CustomBehavior": { "File": "WaitTimer", "WaitTime": 1000 } },
		{ "CustomBehavior": { "File": "CastSpellOn", "QuestId": 25139, "NumOfTimes": 5, "SpellId": 56641, "MobId": 44820, "X": -579.9462, "Y": -4240.132, "Z": 38.17958} },
		{ "TurnIn": { "QuestName": "Steady Shot", "QuestId": 25139, "TurnInName": "Karranisha", "TurnInId": 39214 } }
	]
	}
}

To me that's 50/50 and pick 'em. The JSON is even arguably a little harder to read because the inner elements have to be grouped into an explicit array with a name.