Sky Quest Tracker falsely reporting data

[wizen]

Sky Quest Tracker falsely reporting completed quests, looted items, and unlooted items. It shows me as having looted a bunch of things I did not loot, and as having things I do not have. As well, it says I have not done things that I have done, and that I do not have things that I possess.

Edit: This is after a fresh /outputfile inventory and /outputfile achievements.

---

EQBuddy 1.88.3 · Windows 19045

[DranakCorps-bot]

This was a real bug and a bad one. Fixed in 1.88.4 — thank you for reporting it, because it was silently corrupting checklists and nothing about it looked wrong from the inside.

What happened. When several classes want the same drop, EQBuddy is supposed to tick only the classes you actually play. With no class filter set, an empty class selection was being read as "every class matches" rather than "no class matches". So one Wind Rune Azia ticked the Druid, Monk and Wizard checklists together, and one Red Dragon Scales ticked both the Bard and Warrior epics.

Why it started when it did. It became permanent in 1.88.0. The widget's old Sky and Epic cards used to keep a class selected as a side effect of being on screen; when those cards folded into the Quest Tracker, nothing set it any more — so every install landed in the empty-filter state that triggers it.

What it does now. A shared drop with no class to attribute it to ticks once and wears a * for you to move — which is what it always did when a filter was set. Setting your class(es) in the Quest Tracker's class picker is now the only thing that scopes these ticks, so it's worth doing even if you only play one character.

I have to be straight with you about the damage. The wrong ticks went through the same code path as honest ones and are indistinguishable from them now — there is no marker to find them by and no cleanup I can offer. If your checklists are over-ticked, the fix stops it happening again but cannot undo it: set your classes, then correct the rows by hand. I'm sorry for the tidying; that's the cost of the bug and it's ours, not yours.

You also filed #192 and #197 in the same sitting — I'm answering both of those separately.

[wizen]

I did, figured it was better for organizational reasons.

Is there a way the program can parse the achievements outputfile to glean which quests have been complete, as there are achievements for completing all a class's Sky quests, and unlocking them as primary class? That would let EQBuddy track the quest's current state of completion, not just this log's progress.

[wizen]

I came across a further problem related to this. For reasons of ignorance and lack of patience I bought a couple of class unlocks, and that's making EQBuddy recognize that, for example, Bard quests have been completed when really I just did the quest to find the holy credit card.

From the achievements log:

Untapped Potential: Classes
C	Primary Class Unlock - Bard
C		Obtain Mask of Song.
C		Obtain Mantle of the Songweaver.
C		Obtain Ervaj's Flute of Flight.
C		Obtain Amulet of the Fae.
C		Obtain Denon's Horn of Disaster.
C		Obtain Spear of Harmony.
I		This achievement will autocomplete if you chose to confirm your Primary Class as a Bard.
C		This achievement can be bypassed using a Primary Class Unlock Token.

Achievement parsing may be required for accurate class unlock tracking; I think my use case of unlocking one or two and intending on questing for the rest is not unique. ON the other hand, it is a new file parse to solve a problem that could be solved by including a little switch for "Unlocked" being true or false. I don't believe EQBuddy currently detects a person's primary class or differentiates between quest tracking for chosen first primary or paid unlock or class still locked as primary, so perhaps the ability to mark a class as unlocked is the minimal work solution.

[DranakCorps-bot]

The original bug was fixed in 1.88.4 and the damage is still not undoable — that part of
my earlier answer stands.

Your follow-up about class unlock tokens is a separate and real problem, and your own
suggestion is the right shape. You bought a Primary Class Unlock, the achievement reads
C for the Bard obtain-steps, and EQBuddy takes that as "did the quests". It can't tell
the difference, because the file doesn't cleanly say.

Looking at your paste, the two lines that would distinguish it are right there:

I  This achievement will autocomplete if you chose to confirm your Primary Class as a Bard.
C  This achievement can be bypassed using a Primary Class Unlock Token.

— the bypass line marked C is the tell. But I'd rather not build matching on one
person's file and one class.

What would settle it: if you have exports from a quested unlock as well as a
token one, those two side by side would show whether that line is reliably the
difference. If you only have the token version, say so — that's still useful, it just
means the safer fix is your minimal one (a manual "unlocked, didn't quest it" switch per
class) rather than parsing.

Either way this is worth doing; I'd just rather do the version that's right than the
version that's quick.

— Dranak (Claude Code)

[wizen]

Sure, please find attached the log file.
NAME_SERVER-Achievements.txt

[n3cr0nk1tt3n]

One thing to note here is that the Achievement window counts your primary class (or unlocked with a Primary Class Token) as complete without actually doing the turn ins, which might confuse the tracker as well.

[DranakCorps-bot]

@n3cr0nk1tt3n — that is an important corroboration, thank you, and it matches what wizen reported from the other direction.

To state the problem plainly so we are all describing the same thing: the game's own achievements export marks a class's obtain-steps complete when the class was your primary, or was unlocked with a Primary Class Token — without you having done the turn-ins. EQBuddy believes the export, because believing the game's own file is normally the right call. So a class you intend to quest comes back already ticked.

What I do not want to do is guess at the fix from one person's file. The line wizen pasted (C This achievement can be bypassed using a Primary Class Unlock Token) looks like it might be the tell — if the export marks bypassable achievements distinctly, we can tell "unlocked" from "quested" without asking anyone to configure anything, which is much better than a switch. But I have not seen a quested file to compare against, so I cannot tell whether that line appears on both.

So the ask still stands, and either of you could close it: an achievements export from a class you genuinely quested, alongside one from a class you unlocked with a token. Even the few relevant lines from each is enough — I am looking for what differs, not for your whole file.

Until then I would rather leave this reporting honestly-wrong-the-same-way-the-game-does than ship a guess that makes it wrong in a new way. If it is getting in your way in the meantime, the per-item ticks are yours to correct by hand and EQBuddy will not fight you on them.

— Dranak (Claude Code)