Questie

Questie

116M Downloads

Can't share quests with Questie enabled

athei opened this issue ยท 13 comments

commented

Whenever I have Questie enabled I can't share quests. It always says "[player]" is already in that quest" even if that is not the case. When i deactivate Questie it immediately works. Using questie 3.69 but the bug was there in earlier versions, too.

commented

Wow... this is a new one. OK. Incoming rant. Not your fault so this isn't directed at you personally...

Questie doesn't handle this function in the slightest. However, if you're running EQL3 or ShaguQuest or some other "QuestLog Mod"... typically those do but they don't generally modify the method since the API - QuestLogPushQuest() - is hard coded. The default game client files only refer to this API once - it's embedded in the XML and it only fires when you select the button "Share Quest". The only thing that would prevent Questie from allowing this to work is if we discovered a clever way to spoof or change the [questIndex] - which we don't. Besides, the game client will default to the selected quest if the [questIndex] is omitted. Also, the "Share Quest" only lights up when you select a valid quest. Questie doesn't even run the API that checks - GetQuestLogPushable() - before lighting up the "Share Quest" button so I fail to see how Questie is involved with this bug.

Your error is suggesting that something is using the Blizzard UnitName() API or possibly UnitName("party"..i) API incorrectly. Questie runs neither of these functions. If I had to guess? I'd say you have an AddOn that is using it wrong. Or some how it's changing the var %s. For example, the only appearance of: ERR_QUEST_PUSH_ONQUEST_S = "%s is already on that quest"; is in the game client. It's not found in EQL3 or Questie so the error you're seeing should only be coming directly from the game client and not one of your AddOn's.

Disabling Questie, "oh, it works... it must be Questie" isn't a valid test case. :) Questie could simply be showing that a bug is occurring someplace else in another mod which is active. A real test case would be to disable ALL your mods, delete your local cache (..\WDB), run Questie solo and see if Quest Sharing is foobar'd.

commented

Questie was the only mod enabled when testing of course. Did not delete the WDB folder, though.

commented

...well I could be wrong but I have no idea why this would occur when we aren't doing anything with those API's... I can't imagine a rouge REGEX going sideways on us to that extreme.

commented

I am happy to do some more testing. A friend of me and I did find out that it only matters that the one who is trying to share has Questie enabled. For receiving the quest it did not matter if it was activated or not.

On top of that it is not 100% reproducible. Some times it was resolved just by relogging. At some point we NEEDED to share a quest and disabled all addons -> then it worked. Then we enabled them one by one and it did not work when Questie was enabled (even with all other deactivated). This is not for all quests. Some are still shareable. It seems to be random.

I had EQL3 installed but switched to UberQuest. But with them disabled and Questie enabled it did still not work. Is there a way for them to corrupt the WDB or something?

commented

Ahhh... see these little bits of info that you give me just gave me an idea. If you want to help then please try this...

Search for this " ChatFrameEditBox:Insert( " specifically in QuestieTracker.lua... then replace the whole line with this:

ChatFrameEditBox:Insert(gsub(this:GetText(), " *(.*)", "%1"));

When I mentioned REGEX this is the only line of code that recently changed. And it has a %s in it to this:

ChatFrameEditBox:Insert("["..gsub(this:GetText(), ".*%]%s(.*)", "%1").."]");

It specifically strips out the QuestLevel from the chat link but it's ONLY supposed to affect Quest linking.

commented

I think I may have found the bug and it did pertain to the %s I had in my regex. I keep forgetting that LUA regex is more persnickety.

Next release will have a fix. I'm going to use this instead:

ChatFrameEditBox:Insert("|cffffff00|Hquest:0:0:0:0|h["..gsub(this:GetText(), ".*%] (.*)", "%1").."]|h|r")

raw spaces are allow in LUA regex. I'm so used to using %s which in regex is the same as a space. Unfortunately, %s is also a WoW Global Var... it's the only logical explanation and it does't breaking the function.

commented

Nice to hear that you found the bug. You did not push the commit yet, did you?

commented

Not yet. Zoey was working on a HUGE new feature that we just merged. I'm doing a FULL round of testing to make sure it's code doesn't interfere with my new features.

Stay tuned for more info!

commented

Great news. We are excited to hear that you merged the pull request.

Please enlighten us exactly what the /questie cluster does.
I tried it and I can't see any difference.

commented

It's on by default... you'll notice a significant reduction in ! ! ! ! ! on your world map. Doesn't affect the mini map and it only affects Objectives if they are at the same cords. No distance calculations on those since we discovered some quests where the objectives are ALL over the bloody world and it was causing too much lag. Zoey is looking at making it better but for now, we're happy with the result so far. A cleaner world map. :) If you finish a quest and it gets clustered in with a bunch of other available quests, it gives preference to the finished quest; thus painting the ? icon to represent that cluster.

Before Clustering:

stv-before-clustering

After Clustering:

stv-after-clustering

commented

Yes, it is the player arrow.

commented

@Dyaxler what the heck is that underneath the quests in the after picture? is it your player arrow? Would be more obvious how much the clutter is reduced without whatever that is :P

commented

New beta release is out. It can be downloaded here.