Attempting to track a quest from the vanilla quest book when the Wynntils quest book is disabled results in an error on a newly started instance. The only way around this is to enable and disable the Wynntils quest book again then quest tracking starts working with the vanilla quest book once again.

This is a rather complex issue, seems to be happening after @magicus patch for a much faster quest book.

Multiple things can fix this:
1, Force quest book analysis on class join (not worth it imo)
2, Don't allow opening the regular quest book when the feature itself is enabled, so we can skip the work

Regarding 1, I have been thinking that we should persist quest information per character. Then we could assume that our current persisted state is correct, and just update/verify it when doing quest stuff.

This could also allow us to re-track a tracked quest when logging in with a character, something that always has annoyed me, that tracked quests are forgotten when switching servers or relogging.

I just wanted to get full player UUID + storage in models to work properly first, before implementing this.

I just wanted to get full player UUID + storage in models to work properly first, before implementing this.

Both work now, so it is time to do this :)

Unless you've done things I've missed, both are not fully complete as to how I want to see it.

Unless you've done things I've missed, both are not fully complete as to how I want to see it.

How so?

You added storage to models (only configs don't work) and we parse the uuid from the compass?

Right, storage to models work, not just configs. I was mixing this up.

But, the UUID is still just partial. I want to match it to the full UUID from the Wynncraft API, before we start storing any substantial data for it.

I am also a bit unhappy that it is still guesswork involved in matching UUID and characters in the selection screen. :( But at least I'd like to implement that guesswork, so we can track the UUID of characters even before they are selected.