[5.3.0a1r2] EPGP Addon breaks Carbonite Quest tracker

[Lolaan]

5.3.0 Alpha 1 R2

I noticed a couple other threads mentioning quest tracker problems. I've tracked my specific problem down to the EPGP addon ( http://www.curse.com/addons/wow/epgp-dkp-reloaded ). Hopefully all the following information will help you track down the bug.

- The quest tracker will not update beyond the initial load in (whatever quests are there when I load in stay there).
- I can track individual quests that are there after a fresh ui reload (the white circle), but the quest data for them won't update and no new quests will show up in the tracker. Auto-track also does not function
- The tracker will also keep showing these quests even while minimized. Anything quest related still shows up on the map (the area the quest is in, where to turn it in, etc.)
- Its just the quest tracker that seems to be "frozen."
- There's no lua error.

Seems to be related to LibGuildStorage-1.2.lua (and LibDebug-1.0.lua but I think that's just because LibGuildStorage doesn't function without it) because I can comment out all but those two in the epgp.toc and still have it break the quest tracker.

I can easily get around this by simply turning off epgp except for raids (I'm the master looter so I have to have it on for that) but a fix would be nice, and hopefully by fixing this you might also be able to solve some of the other quest tracker problems I've seen around.

[Chmee]

I wonder if the problem in this particular case isn't with EPGP, or the libraries you mentioned. If so, the person to fix the problem is not Rythal. You're right though that if the problem is with Carbonite, a fix to this may fix others' problems too.

[Lolaan]

Originally Posted by Chmee I wonder if the problem in this particular case isn't with EPGP, or the libraries you mentioned. If so, the person to fix the problem is not Rythal. You're right though that if the problem is with Carbonite, a fix to this may fix others' problems too.

That's certainly possible that somehow that library is interfering with Carbonite.Quest's function and it is what will require the change as opposed to Carbonite. If that turns out to be the case, I'll be more than happy to open a ticket over there (or Rytahl can as he can probably tell em better where the problem is if he finds it). However, since the broken functionality is on Carbonite's end, I figured this would be the place to start.

[Twink]

This may well explain my problems!!

I use EPGP for my guild and have all of the same symptoms - aswell as my quest tracker being stuck "open" (cant minimise it but can move it)


If there is something we can do to test or debug, please just let us know!!

[Rythal]

as an update on this, I was able to find out why it happens after it started happening with TSM aswell, and I just submitted a ticket with the team responsible for it so hopefully they can fix it up.

For those curious, the addons are calling debugprofilestart() which causes a global reset of the debug timers. Carbonite uses those timers in the quest window to say how often an update can occur instead of trying to redraw several times a second.

[buffon]

this solve my problems I turn out EPGP and carbonite start working

[Rythal]

EPGP has been patched and next release should work with Carbonite.

[Lolaan]

Question. Is there a specific reason you're using debugprofilestop() as opposed to GetTime()? Looking around (granted I'm sure I have much less programming knowledge than you do) you're not using the precision granted by debugprofilestop and so the only difference I can see is that GetTime will only change every OnUpdate but it doesn't seem like that'd be a problem? If it does make a difference, let me know how as I'm trying to learn.

[Rythal]

The only reason I use debugprofilestop is as a time keeper for how often the quest window can update, without the checks it was updating several times per second and causing rather large overhead. The window can be updated for any number of reasons and there is a half dozen calls or more through out the code to do the update, so it was easier to use a function as percise as possible to ensure the most accurate timing of the redraws...

already some people don't like the small delay I do have in place, prefering the old way of instant window update as things happen.

[Lolaan]

Originally Posted by Rythal The only reason I use debugprofilestop is as a time keeper for how often the quest window can update, without the checks it was updating several times per second and causing rather large overhead. The window can be updated for any number of reasons and there is a half dozen calls or more through out the code to do the update, so it was easier to use a function as percise as possible to ensure the most accurate timing of the redraws... already some people don't like the small delay I do have in place, prefering the old way of instant window update as things happen.

Perhaps a setting, I know that's what ovale does (its the other addon I have that has a lot of overhead). Ovale has a throttle slider that delays the next update from 0 to 500 ms (unless an event causes ovale to need to update first).