SolarStrike Software

Posted: **Sun Aug 19, 2012 2:34 am**

This userfunction adds a "questlog" class to the bot that provides information and some functions for the quest log (the quests you currently have). It gets this information from memory so is very fast. It also replaces the "getQuestStatus" function with one that works from memory so takes about 7% the time the old function took.

Functions And Info Available
Here are some of the new functions available;

Code: Select all

questlog:questCount()

Returns the number of quests in your quest log.

Code: Select all

questlog:haveQuest(nameorid, questgroup)

Just returns true or false if you have the quest. questgroup is optional and can be "normal", "daily" or "public".

Code: Select all

quest = questlog:getQuest(nameorid, questgroup)

Returns information about the quest. Some of the information looks like this, assuming you did the above command first. For the rest, please check the file.

Code: Select all

quest.Name 
quest.Id 
quest.Level
quest.AcceptLevel
-- There can be more than 1 quest giver
quest.QuestGiver[1].Name 
quest.QuestGiver[1].Id
-- There is only 1 quest taker
quest.QuestTaker.Name
quest.QuestTaker.Id
-- Item goals are things you have to collect or tasks you have to do.
quest.ItemGoals[1].Name
quest.ItemGoals[1].Id
quest.ItemGoals[1].NumReq
-- Kill goals are things you have to kill.
quest.KillGoals[1].Name
quest.KillGoals[1].Id
quest.KillGoals[1].NumReq
-- You can have multiple item and kill goals.

You also have the quest function.

Code: Select all

quest:isComplete()

Returns true or false if the quest is complete.

Code: Select all

quest:getKillCount(goal)

Returns the kill count of the goal specified. If 'goal' is not specified then it defaults to '1'.

Note: When getting the status of a quest that is not an item quest or kill quest (which is a minority, most quests are item or kill quests) it will fall back to using the in game function as the status can't be gotten from memory.

New: All the collected base item info is now in a separate function so that you can get info about quests you don't have.

Code: Select all

questdata = getQuestBaseData(questid)

Future Of This Userfunction
I've just added basic functions. I'll add functions as users request them, so please ask.

I can see the future of this userfunction going 2 ways. Either there is enough interest in it that the whole thing will get added to the bot, or there is not much interrest in which case I'll just add the speed improvements to getQuestStatus.

userfunction_QuestLogClass.lua: Version 0.06 - Added questgroup support to getQuestStatus to match change to bot version.; (8.59 KiB) Downloaded 476 times

userfunction_QuestLogClass.lua: Version 0.05 - Updated to support patch 5.0.5. Only works with bot rev 743 and above.; (8.17 KiB) Downloaded 449 times

For older versions of rombot revision 742 and older.

userfunction_QuestLogClass.lua: Version 0.04 - Fixed: no longer interfers with 'character' option when starting the bot.; (8.73 KiB) Downloaded 404 times

Posted: **Sun Aug 19, 2012 3:01 am**

for nameorid can it be partial name or does it need to be the full name?

Posted: **Sun Aug 19, 2012 3:05 am**

Partial is ok. Like the old getQuestStatus it can also handle pattern or non pattern names.

Edit: and case doesn't matter either.

Posted: **Sun Aug 19, 2012 1:58 pm**

Woah! I've been waiting for something like this for ages. Excellent! Can this differentiate between quests with the same name? i.e. Extinguish More Flames daily and event quest if quest id is provided instead of quest name?

Posted: **Sun Aug 19, 2012 7:40 pm**

Alkaiser wrote:Woah! I've been waiting for something like this for ages. Excellent! Can this differentiate between quests with the same name? i.e. Extinguish More Flames daily and event quest if quest id is provided instead of quest name?

As I mentioned in the first post, if the quest is neither an item quest or kill quest then it falls back on using the in game function. The in game function only accepts names, not ids. By the looks of it thos quests look like they are task based quests so it will probably use the in game function so you will still have the same problem. The in game function should be updated to include id checks. I believe the QuestByName functions suffer from the same problem.

I think the issue is it's hard to get id's in the game but I'll see what I can do.

Posted: **Sun Aug 19, 2012 10:43 pm**

I think I can add support for quest ids in getQuestStatus but I'm having trouble with the QuestByName functions. I can't get their ids. I can get whether they are a daily or not so maybe I can add an option to select only dailies. I need to know if public events are seen as dailies but seeing as I don't have any public event available to me, I can't check. Could you check for me?
Use the following command in the game.

Code: Select all

/script _QuestName, _Daily, _QuestGroup = GetQuestNameByIndex( 1,1 ) SendSystemChat(_QuestName..", ".. tostring(_Daily)..", ".. _QuestGroup)

To use it, make sure you have neither of the 2 quests. If you do, abondon them. Open a dialog with the npc. Enter the command above but match the second number to the quest. The above command checks the first unaccepted quest. If you use a 2, it will check the second.

Use the above command on the daily and non daily quest and show me what it prints.

Posted: **Mon Aug 20, 2012 12:37 am**

Never mind, some public events appeared and I was able to test it. It does see public events as dailies but I can use the 3rd returned value of the command "quest group" to tell which is which.

This is how I think I'll have the option work.

Code: Select all

AcceptQuestByName(questname, questgroup)
CompleteQuestByName(questname, questreward, questgroup)
AcceptAllQuests(questgroup)
CompleteAllQuests(questgroup)

If questgroup is specified then it has to match. Options for questgroup are "normal", "daily" and "public".

So for example if you have an npc that has normal and daily quests and you want to accept all normal quests only you can use

Code: Select all

AcceptAllQuests("normal")

Or if you have an npc that has a daily and public event with the same name and you want to accept the daily you can use

Code: Select all

AcceptQuestByName("Extinguish More Flames","daily")

How does that sound?

Posted: **Mon Aug 20, 2012 3:41 pm**

Code: Select all

AcceptQuestByName("Extinguish More Flames","daily")

That works for me! Right now I'm using the DailyNotes addon to get the right quest, daily/event.

Posted: **Mon Aug 20, 2012 5:51 pm**

rock5 wrote: I'm having trouble with the QuestByName functions. I can't get their ids

I use a different in game function

Code: Select all

	i = 0
	repeat
		i = i + 1
		local index, catalogID, name, track, level, daily, bDaily_num, iQuestType, 
		questID, completed, QuestGroup = RoMScript("GetQuestInfo("..i..")")
--fancy stuff here
	until name == nil

Sounds like you have it doing what you want anyway =)

Posted: **Mon Aug 20, 2012 11:23 pm**

lisa wrote:I use a different in game function

Like I said, I figured out how to get the Ids for the getQuestStatus function. I'm just using "GetQuestId".

What I can't get is the Ids for the QuestByName functions. For them, I need to get the Ids of quests in an npc dialog. I could only come up with that other solution. It would be preferable to be able to use Ids but I can't see how to do it.

Posted: **Tue Aug 21, 2012 12:16 am**

I think I've thought of a way of doing it.

I was thinking of adding support for Ids. It would just convert the Ids to names using GetIdName. This is so it is easier to create multilingual scripts. But then I thought what if I could also get the quest group from memory for that Id as well? Then, with the name and quest group, I'd be able to match 100% the quest without the need for the second option. This assumes I'll be able to get the group from memory.

Unless users would like the option to, for instance, accept all normal quests.

Posted: **Tue Aug 21, 2012 12:38 am**

rock5 wrote:This assumes I'll be able to get the group from memory.

I'm not having much luck. Looks like I might leave it at it is although I might still add the basic support for Ids.

Posted: **Tue Aug 21, 2012 3:42 am**

I was wrong. I have found the quest group in memory.

That means we can reliably use the Ids in the QuestByName functions like so,

Code: Select all

AcceptQuestByName(424171)

The last question is, should I add the group argument anyway so that you can accept/complete specific types of quests? Example

Code: Select all

AcceptAllQuests("normal")

Would people want this option? I guess it wouldn't hurt to add it anyway, especially as I've already written it.

Posted: **Tue Aug 21, 2012 6:47 am**

I've committed the above discussed changes. Read about them here.
http://www.solarstrike.net/phpBB3/viewt ... 728#p40728

I've also updated this userfunction version of getQuestStatus to accept Ids as well.

Posted: **Wed Aug 29, 2012 3:43 am**

For KillGoals and ItemGoals, would it be an idea to have the goalCount available together with the NumReq? Hmm perhaps not really nessesary for ItemGoals as an inventory:itemTotalCount would do the trick but for KillGoals it would be nice.

-dx

Posted: **Wed Aug 29, 2012 3:50 am**

I've added one line to the update function which implements GoalCount:

Code: Select all

					end
					self.KillGoals[i].NumReq    = memoryReadUInt(getProc(), self.BaseItemAddress + 0x1B8 + 0x4 * (i - 1))
					self.KillGoals[i].GoalCount = memoryReadByte(getProc(), self.Address + 4 + i)					
				end
			until id == 0 or i == 5

regards
DX

Posted: **Wed Aug 29, 2012 4:15 am**

dx876234 wrote:For KillGoals and ItemGoals, would it be an idea to have the goalCount available together with the NumReq? Hmm perhaps not really nessesary for ItemGoals as an inventory:itemTotalCount would do the trick but for KillGoals it would be nice.

The reason I didn't add it is because the only need for it is to know if the quest is complete. So it only needs to get that value when you are checking the quest status. Why get that information if you are not checking the quests status? So in fact the quest log hold no information that changes. This makes updates quicker because if the quest hasn't changed, it doesn't need to be updated. This was intentional because a full questlog:update() would otherwise take too long.

Do you have some need for it? Why do you need it? How do you want to use it?

Posted: **Wed Aug 29, 2012 4:41 am**

Well, I was looking for ways to detect when I could stop following a cow in the cowboy event, this would be when a cow was in bin, i.e. when GoalCount increased.

In my ignorance there is probably other ways to detect this as well.

-dx

Posted: **Wed Aug 29, 2012 5:00 am**

You could probably just check the possition of the cow. When it passes a certain point, it's there. Would that work?

Posted: **Wed Aug 29, 2012 7:38 am**

Tbh, simplest way is to check progress of the quest but if its a problem I dont need to put it into the userfile, can do the test directly in the waypoint.

-dx

SolarStrike Software

Rock5's QuestLog Class

Rock5's QuestLog Class

Re: Rock5's QuestLog Class

Re: Rock5's QuestLog Class

Re: Rock5's QuestLog Class

Re: Rock5's QuestLog Class

Re: Rock5's QuestLog Class

Re: Rock5's QuestLog Class

Re: Rock5's QuestLog Class

Re: Rock5's QuestLog Class

Re: Rock5's QuestLog Class

Re: Rock5's QuestLog Class

Re: Rock5's QuestLog Class

Re: Rock5's QuestLog Class

Re: Rock5's QuestLog Class

Re: Rock5's QuestLog Class

Re: Rock5's QuestLog Class

Re: Rock5's QuestLog Class

Re: Rock5's QuestLog Class

Re: Rock5's QuestLog Class

Re: Rock5's QuestLog Class