ESOUI

ESOUI (https://www.esoui.com/forums/index.php)
-   Wish List (https://www.esoui.com/forums/forumdisplay.php?f=177)
-   -   [open] More quest info for more quests (https://www.esoui.com/forums/showthread.php?t=7322)

Enodoc 08/24/17 06:19 PM

[open] More quest info for more quests
 
We already have GetCompletedQuestInfo(questId) and GetCompletedQuestLocationInfo(questId). Is there a reason this is only available for completed quests? All quests have an (invariable) unique Id, and their name, questType, zoneName, objectiveName, zoneIndex and poiIndex do not change on completion.

Can these functions be changed to GetQuestInfo(questId) and GetQuestLocationInfo(questId), which would return the results for any questId, complete or otherwise? An additional return from this would logically be boolean isCompleted, or alternatively number questState, which would take values 0, 1 or 2 depending on whether the quest is not started, active, or complete.

I would also like to request two additional returns from GetCompletedQuestInfo (or GetQuestInfo if it can be implemented), namely repeatType, taking from the global QuestRepeatableType (self-explanatory), and questDifficulty, taking from the global DifficultyCon, where the quest's internal difficulty (which determines the XP multiplier, as explained by Jess Folsom) is exposed:
Quote:

Originally Posted by ZOS_JessicaFolsom
We add experience multipliers to quests, usually depending on the time taken and relative difficulty. Those experience multipliers look like this:

  • Very Easy = .1 (this would be CON_TRIVIAL)
  • Easy = .75 (this would be CON_EASY)
  • Standard = 1 (this would be CON_APPROPRIATE)
  • Hard = 1.5 (this would be CON_DIFFICULT)
  • Very Hard = 2.25 (this would be CON_IMPOSSIBLE)
Repeatability and Difficulty are clearly defined internally per-quest, so hopefully can easily be exposed to the API.

Thanks!

Ayantir 08/25/17 03:12 AM

I do agree that for now, in order to get all quests ID & names of the game, we need to use the lang files from an extraction of the whole game.

Enodoc 08/25/17 03:07 PM

Quote:

Originally Posted by Ayantir (Post 32436)
I do agree that for now, in order to get all quests ID & names of the game, we need to use the lang files from an extraction of the whole game.

Indeed, and that can only link IDs to names, not types and zones as well.

manavortex 10/22/17 05:34 AM

On DailyAutoShare, I've had some headache with quests and quest names. I agree that it would be awesome, and much easier, to just deal with quest IDs instead of having to localise all the quest names.

My use case:
DAS holds a list of dailies in a zone. That list is right now hardcoded via internal quest name codes that get resolved via localisation files.
It would make my life far easier if I could simply match on quest IDs instead.

Functions I'd like for that:
Lua Code:
  1. -- returns unique quest ID from a journal quest index
  2. GetJournalQuestId(journalQuestId)
  3.  
  4. -- returns unique quest ID from quest name (part)
  5. GetQuestId(questName) or even GetQuestId(questNamePart)
  6.  
  7. -- returns the quest name from a quest ID, defaults to client language
  8. GetQuestName(questId, language)

I would also love it if the quest IDs would be part of the EVENT_QUEST_... anything, which right now just features the journalIndex.

As far as
Lua Code:
  1. param1, ..., param999 = GetQuestInfo(questId)
is concerned, that's probably easier internally than more specific API calls that return just one or two parameters? Whatever's easier on the API, I'd hate to run into any run-time performance issues. :)

ZOS_ChipHilseberg 10/23/17 07:56 AM

An id based API for quests should be possible in addition to the existing API. Steps and conditions would probably be harder to reference this way.

manavortex 10/23/17 07:59 AM

Awesome! Looking forward to it. :)

Enodoc 10/28/17 07:45 AM

Quote:

Originally Posted by ZOS_ChipHilseberg (Post 32968)
An id based API for quests should be possible in addition to the existing API. Steps and conditions would probably be harder to reference this way.

That's great, thanks! Steps and conditions aren't as important for what I was looking for anyway; it's name, type, zone, objective, completion state, repeatability, and difficulty that I'm mostly interested in. This way, we should be able to get both a list of completed quests, and a list of not completed quests, for each zone and guild.

Kyoma 11/05/17 10:13 AM

I would also like to get another parameter to GetCompletedQuestInfo which returns if it has been completed today (if it was a daily).

fritzOSU03 02/09/18 02:20 PM

I think this thread is overdue for a bump. Unless this has happened and I missed it, it would be quite helpful.

Enodoc 04/19/18 08:36 AM

Quote:

Originally Posted by fritzOSU03 (Post 33875)
I think this thread is overdue for a bump. Unless this has happened and I missed it, it would be quite helpful.

Nothing's happened yet that I've noticed. Currently waiting for the API notes for Summerset (don't think they're out yet?); hopefully there's something new in there.

Baertram 04/19/18 02:11 PM

Check the ESOUIDocumentation 18_2.txt file in this thread, maybe some functions or events got chnaged or got added parameters?
http://www.esoui.com/forums/showthread.php?t=7728

calia1120 04/19/18 05:37 PM

There's several functions already on live that could be used:
Code:

GetJournalQuest****
GetJournalQuestLocationInfo
GetJournalQuestStepInfo
QUEST_STEP_TYPE_
QUEST_REPEAT_DAILY
QUEST_REPEAT_NOT_REPEATABLE
QUEST_REPEAT_REPEATABLE

And a handful of others.

Enodoc 04/20/18 07:46 AM

Quote:

Originally Posted by Baertram (Post 34451)
Check the ESOUIDocumentation 18_2.txt file in this thread, maybe some functions or events got chnaged or got added parameters?
http://www.esoui.com/forums/showthread.php?t=7728

Thanks for the link! Nothing new that I can see though unfortunately.


Quote:

Originally Posted by calia1120 (Post 34459)
There's several functions already on live that could be used:
Code:

GetJournalQuest****
GetJournalQuestLocationInfo
GetJournalQuestStepInfo
QUEST_STEP_TYPE_
QUEST_REPEAT_DAILY
QUEST_REPEAT_NOT_REPEATABLE
QUEST_REPEAT_REPEATABLE

And a handful of others.

Anything with JournalQuest in the function only works for active quests.

ZOS_ChipHilseberg 04/20/18 08:41 AM

We added:

DoesItemLinkFulfillJournalQuestCondition(itemLink, questIndex, stepIndex, conditionIndex)

We changed:

GetJournalQuestConditionInfo now also returns the condition type.

Dolgubon 04/20/18 09:39 PM

Quote:

Originally Posted by ZOS_ChipHilseberg (Post 34467)
We added:

DoesItemLinkFulfillJournalQuestCondition(itemLink, questIndex, stepIndex, conditionIndex)
.

Woot! That is awesome! I just need to rewrite this and that and... *Looks at jewelry writs* ... Oh fun...

But seriously this is great. It'll let me do validation on writ items, and make sure that the item will actually fulfill the writ. Moreover, it'll let me do a brute force check for the correct item when the normal stuff fails. That will prevent bugs which occur when there are translation errors, which will decrease maintenance required for each patch.

manavortex 04/21/18 04:56 AM

That's awesome already, thank you Chip!

Any chance that we can get
Lua Code:
  1. GetQuestName(questId)
?

Enodoc 04/21/18 05:18 PM

Quote:

Originally Posted by ZOS_ChipHilseberg (Post 34467)
We added:
DoesItemLinkFulfillJournalQuestCondition(itemLink, questIndex, stepIndex, conditionIndex)

We changed:
GetJournalQuestConditionInfo now also returns the condition type.

Oh nice! I notice those are just for active quests; any progress on the proposed GetQuestInfo(questId) and GetQuestLocationInfo(questId) for any quest (complete or otherwise)?

eventHandler 04/23/18 10:00 AM

Quote:

Originally Posted by ZOS_ChipHilseberg (Post 34467)
We added:

DoesItemLinkFulfillJournalQuestCondition(itemLink, questIndex, stepIndex, conditionIndex)

We changed:

GetJournalQuestConditionInfo now also returns the condition type.

Is there a way to get the decisions a player made for a completed quest?

That information has to be stored in some form, so it would be great if we could do something like:
Code:

local decisions = GetCompletedQuestDecisions(questId)

if not decisions then return end

local choices = { }
local i = 0
for key, val in pairs(decisions) do
    choices[i].text = key -- string of the wording for the choice
    choices[i].chosen = val -- boolean true/false this choice was chosen
    i += 1
end

Where GetCompletedQuestDecisions(questId) returns an array of the possible decisions or nil if N/A.

Even getting the information in a raw form would be useful, like return values of {0,1,2,3} where those are the choice numbers associated with that quest, and the number returned is the one chosen. We would need to do work on our end to translate it to data mined quest information, which is a lot of work, but doable.

The details really depend on how the data is saved to the character, but we know it has to be saved in some form, or the game couldn't react to past quest decisions.

Enodoc 04/22/19 08:39 AM

Quote:

Originally Posted by ZOS_ChipHilseberg
An id based API for quests should be possible in addition to the existing API.

It's been about a year since the last update, so I'd like to check whether there has been any further developments on an id-based API for all quests (not just completed quests or active quests, which already exist with GetCompletedQuestInfo(questId) and GetJournalQuestInfo(questIndex)).

Summary of the request:
  • GetQuestInfo(questId) - string name, number QuestType questType, boolean isCompleted, number QuestRepeatableType repeatType, number DifficultyCon questDifficulty
  • GetQuestLocationInfo(questId) - string zoneName, string objectiveName, number zoneIndex, number poiIndex


All times are GMT -6. The time now is 11:46 PM.

vBulletin © 2019, Jelsoft Enterprises Ltd
© 2014 - 2019 MMOUI