Grail

3M Downloads

Quests that are completed together are not logged together

yoshimo opened this issue · 16 comments

commented

If i do a /grail backup, turn a quest a in that also completes quest b , only a is logged into the saved variables.
B isn't, but it isn't shown in /grail cb either.
For now i rely on HN Shadowlands debug capabilities to make sure the relation ship isn't lost when going through content.

commented

I have just pushed a change in Grail that posts a delayed notification that attempts to process this information. It is still tied to the completion of the quest, but does not use a timer, but OnUpdate scripts. The delay is still 1.0 seconds, so if it is not working as you expect, you might be able to get better results by increasing the delay a bit. I know the technique works in general since I was able to do some basic testing and I saw reports, but I am not running Handy Notes.

commented

Could you add the questname too if available?
My attempt to do so caused an occasional loop when turning in multiple quests at once :)
Yea it works.
I think we still should list the quest ID & name for existing I: or ODC: codes, maybe in orange, so you can verify it, and some kind of red if it is new.

commented

For the moment I have added the quest name.

commented

In Grail 115 (currently on GitHub) there is now coloration based on whether Grail has ODC: codes for the quests. I have also added notification when leveling. Note that there are things that happen in the world that Grail will not automatically catch (as I really do not want to query the server for completed quests all the time). For example, when looting a chest piece on Exile's Reach a quest is marked complete, irrespective of levels or quests. What is odd is it was not being caught by the normal looting routines...

commented

Some chests have no obvious looting window and therefore fall through the checks. Same is true for casting spells, collecting shards or clicking certain npc gossip

commented

I see from the code that the HandyNotes is delaying its quest processing by a second. Perhaps I can integrate a delay into Grail's code to do similar.

commented

Are you saying that quests that are currently marked with ODC: codes are not marking those complete when a quest is turned in? If so, I will have to check that out since I may have broken it with the latest changes. I have been noting that there are times when Blizzard is marking quests complete that are not showing up on turn in of others. Basically I am detecting that with manual use of "/grail cb", but I am also seeing some action from turning in quests as well (including the LOST messages), so the check when turn in seems to be working as expected.

commented

The initial garrison setup quests for the horde, mark the alliance version complete.
Both quests have an I: tag mentioning the other sides quest.
You just see your own factions quest in the tracking log.

G[34375]='FH L23140 A:578466 T:578466 P:34364 I:34584 E18546'
G[34584]='FA L23140 A:79243 T:79243 P:34583 I:34375 E18546'

but the log has just

"+ Zurück an die Arbeit(34375)[2] <= Gazlowe(3000001)[78466] 590:51.32,39.93 525:51.32,39.93 Error: 32", -- [47]

commented

Blizzard may not actually be marking them completed at the same time. Some of the I: codes are from so long ago when Blizzard was doing that. I would assume this was to handle faction conversions so all the quests you logically did as one would allow you to be in the right position with regard to quests when you switch factions. However, perhaps Blizzard no longer needs that done as they might be able to convert better. I would really love to be able to get rid of the I: codes that are really only the other faction version of a quest, and just have the I: codes for things like different breadcrumbs that are incompatible. Technically if Blizzard is actually marking quests complete, we should use the OxC: codes (ODC: for complete on turnin) and not an I: code unless it actually makes it so you cannot pick up the quest. If "/grail cb" is not actually recording them as being completed, we should probably remove the I: codes that were used to indicate that.

commented

HandyNotes Shadowlands Debug output here :

Sample2
Sample1

commented

I tend to abuse I: to mark quests that are clearly the equivalent of the other faction or an alternate route even if blizzard doesn't mark the quests the same way on turn in.
Watching the wholly panel and the conditions like the outposts in the wod continent, the branches are often very clear to the observer. Not sure how we should keep these use cases apart.

commented

It still looks like both addons don't always log the same result.
I have played with the delay a little but couldn't quite get it to match 100%.

commented

Is it that the results have different quests completed (like Grail says 1, 2, 3 completed, but HandyNotes says 2, 3, 67 are completed), or is it that the timing of when they say they are completed is different (like Grail says 1, 2 and HandyNotes says 1, 2, 3, and then Grail later says 3)?

commented

HN gives 2 quests the turned in quest and its alliance counterpart , Grail only the one i turned in on the horde side.

commented

If the quest in question is already marked with an ODC: code for the Alliance version, then Grail will not report it as newly done (since it is marked complete when the Horde quest is turned in). That could explain what you are seeing. If not, does a "/grail cb" later show it as completed?

commented

Oh i need to check my screenshots then.
I think some of them had the old way with I: , but not all were marked in such a way.
I'm working on extending HN:SL with the QuestName from Grail, but so far i am stuck with lua syntax problems.
Maybe that would make it a little bit easier.