Lazy leecher question: easy way to get quest objectives?

[amadmonk]

So, my bot's working quite well at basic tasks like killing and looting mobs, following targets, and so on. It's not a grinding bot, and not intended to be, but I WOULD like to have the bot be aware that, for instance, a nearby mob is a quest kill/loot requirement, or a nearby gameobject is a quest pickup requirement.

Is there any way built into the WoW API to know this sort of thing, or do libs like Questhelper (etc.) just rely on huge Lua libraries of quest objectives?

If the answer is "libraries," I may look into loading something like Questhelper and then having my bot "tap in" to its knowledge (rather than roll my own, which would take a small eternity...)

TIA for the info.

[ostapus]

i would say - hook to existing "quest helper" addons, i am currently lazily looking into that way as well - exactly for the purpose "dont drop out of bag quest items" for the looted objects - wont be much problem - hoot to tooltip and scan for text, most of quest helpers addons (carbonite it), puts quest info into item tooltip.. pretty much same can be done for objects around - can be bit slow though to iterate over objects and scan tooltip for each one, but this can be done once per every 100 feets or so and not on every frame.

[amadmonk]

Hmm, good ideas. Definitely, let the creators of Questhelper do the work

[ostapus]

yup, in my bot i am using bunch of libraries (ACE-3 branch), to hook event, timers, draw GUI etc... just easier to leech stuff (which is widely supported by addon developers) rather than "invent bicycle" itself and update on each wow api change imo.

---------- Post added at 03:15 PM ---------- Previous post was at 03:13 PM ----------

heh, my bot is actualy Ace addon

MyAddon = LibStub("AceAddon-3.0"):NewAddon("MyAddon", "AceConsole-3.0", "AceEvent-3.0", "AceTimer-3.0", "LibSink-2.0")
it shows in addon list and easily configured thru standart blizzed addon configuration UI

[amadmonk]

I should look into making my bot a "real" addon too. Right now it's all just dynamically invoked code, which makes it really easy to reload everything without restarting the game, but it does limit some of the things I can easily do (like using XML for a frames UI). Don't addons have all kinds of limits about what kinds of resources can be dynamically loaded? It would be great to be able to use the addon API for things like playing sounds/alerts, etc., but I don't want to be restricted too much...

[ostapus]

Not really sure what resources you talking about. I dont use sound in my bot nor XML for frames UI but based on the fact that any addon can be made "loading on demand" there might be less limitation than you think. with fast look into sound functions - i dont see any limitations, well, except maybe if you need to play sound file outside of wow directory. For frames constructed from XML file - this might be tricky, i dont see in widget api frame's method to like "load frame xml from file" = pretty much they should be defined in .toc file for addon. However it wont be "that" hard to write/leech simple xml parser in pure lua to
1. read xml file
2. parse file and create frame, populate frame attributes from xml file
exactly what blizz does for XML files.
should be simple enough because each attribute in xml file has direct mapping in frame object.
thought it might be a bit tricky for event handlers defined in xml.

---------- Post added at 04:42 PM ---------- Previous post was at 04:38 PM ----------

just a note, i dont really hits any limitation in my bot, but maybe because my bot is just not complicated enough

[amadmonk]

I guess the only reason I care about xml frames is just that it seems easier to build complex UI's this way, and it would be a useful RAD tool for whipping up the bot UI.

[ostapus]

i see, then from my expirience, i would recommend to "convert" your code into valid wow addon and check existing library frameworks (Ace ie).

[jjaa]

Are you talking about quests that you currently have or quests that you don't have. If its quests that you do have, then i'm pretty sure that the information is stored in the creature cache (its used to build the tooltips). If its quests that you do not have, then a database would be your best option. From Emulator, wowhead, QuestHelper ect.

[amadmonk]

Quests that I do have. But it's not just "to be killed" creatures, but also "to be looted," "to be interacted with," and so on. I wouldn't be surprised if a lot of that is available, but I bet that most of the stuff in eg Questhelper is hardcoded. I think that I'm going to leech off of their good work Now, to find the best addon to use...

[ostapus]

"looted" is easy, loot everything and just dont drop quest items interacted with - since cata - quests NPC (and also the ones needs to be killed) - have red names over their heads, supposed it can be catched as well.

[jjaa]

Quests that I do have. But it's not just "to be killed" creatures, but also "to be looted," "to be interacted with," and so on. I wouldn't be surprised if a lot of that is available, but I bet that most of the stuff in eg Questhelper is hardcoded. I think that I'm going to leech off of their good work Now, to find the best addon to use...

All that info is stored in the cache, much more reliable then a database imo. Look for references to the formatting strings such as "QUEST_MONSTERS_KILLED". 0x008AAC60(not rebased..) is an example.

[MaiN]

Quests that I do have. But it's not just "to be killed" creatures, but also "to be looted," "to be interacted with," and so on. I wouldn't be surprised if a lot of that is available, but I bet that most of the stuff in eg Questhelper is hardcoded. I think that I'm going to leech off of their good work Now, to find the best addon to use...

Check the LUA function 'QuestPOIGetIconInfo'.
As jjaa said, quest items that gameobjects/creatures drop are stored in their caches, game object cache and creature cache respectively.
The quest cache also contains a lot of information - like item ID's to collect, mobs to kill, game objects to use etc.

[amadmonk]

But doesn't the cache assume that it's already dropped? If I haven't yet killed monster X that drops quest item Y, how can I have that fact cached? Maybe I'm just misunderstanding your suggestion.

Also, the thing I *most* want is ground clicks; I multibox(bot) a LOT, and the "click 25 sparkly things on the ground" quests are by FAR the most annoying ones to finish, since right now I either have to switch to each toon and click in turn, or hard-code in the quest item in a look for-interact loop.

[MaiN]

But doesn't the cache assume that it's already dropped? If I haven't yet killed monster X that drops quest item Y, how can I have that fact cached? Maybe I'm just misunderstanding your suggestion.

Also, the thing I *most* want is ground clicks; I multibox(bot) a LOT, and the "click 25 sparkly things on the ground" quests are by FAR the most annoying ones to finish, since right now I either have to switch to each toon and click in turn, or hard-code in the quest item in a look for-interact loop.

You only have the cache entries if you have already seen the unit/game object.
It could be the server sends you info about them when you pickup the quest - I'm not sure about that. But as soon as you're near the game object/creature you gets its entire cached struct - including quest items it drops.

For the "click 25 sparkly things on the ground", it can be one of two types:

1. Collect items. In this case, as already said, the game object cache contains the quest items a game object drops.
2. Use game object. In this case the ID of the game object(s) to click is stored in the quest cache.

Contact me on MSN and I can get you the structs for them.