Open GoogleCodeExporter opened 8 years ago
I same problem!!
Original comment by magokim...@gmail.com
on 21 Jan 2011 at 4:21
I didn't check that huge list of addons, but I had the same problem monday and
now at today's raid it seems fixed. I disabled QuestGuru and some Inspect-fix
addon, can't find the exact name or link. :S
Original comment by r.sierev...@gmail.com
on 26 Jan 2011 at 7:49
Same problem, I do not use quest guru though. Probably every second raid the
announce options change themselves
Original comment by tef...@gmail.com
on 26 Jan 2011 at 8:18
I've found that being whispered for standby while ghosted and returning to my
body is the cause of turning of the whisper functionality. It also resets the
recurring EP.
Dont know if Im the only one that this happens to.
Original comment by wyn...@optonline.net
on 31 Jan 2011 at 6:15
@wyn yes this seems likely, I also had a recurring EP reset the other day too.
Original comment by dan.para...@googlemail.com
on 2 Feb 2011 at 2:45
Had a reset once during today's raid. I had no people on standby,so
it's not (just) the whispers when in ghostform. :(
Original comment by r.sierev...@gmail.com
on 2 Feb 2011 at 10:33
I have all my setting reset themselves during a raid multiple times.
(unchecking themselves)
Original comment by WTri...@gmail.com
on 2 Mar 2011 at 11:10
I've been having this problem occur on average about once every other week. I
have spent some time trying to track down the control flow through the addon by
adding extra debug statements to the code that handles enables/disables the
announce settings.
It seems that the settings aren't being disabled by some unexpected mechanism
(eg: announce:OnDisable() is never called), but that they aren't correctly
getting restored when reloading the addon after zoning out of a raid instance.
Original comment by oski...@gmail.com
on 10 Mar 2011 at 8:07
This is starting to get very annoying. Is there a simple work-around to fix
this?
Original comment by r.sierev...@gmail.com
on 5 Apr 2011 at 1:06
We never found the real cause of the problem. We only know that some other
addons affect EPGP in this way. It would help if you can find which addon is
causing EPGP to misbehave.
Original comment by evlogimenos
on 13 Apr 2011 at 5:03
I am still having this problem with 5.5.27 several times even in the same raid
instance I'll have to recheck my options for Loot, Announce, Tooltip and they
will be unchecked when I go to distribute loot from the next boss.
Original comment by WTri...@gmail.com
on 19 May 2011 at 10:05
Here's where I think it fails (in epgp.lua):
function EPGP:GUILD_ROSTER_UPDATE()
...
local guild = GetGuildInfo("player") or ""
if #guild == 0 then
GuildRoster()
...
So, we get a roster update event, which probably means that GuildRoster was
called less than 10 seconds ago. If GuildRoster is called within 10 seconds of
the last call, it is ignored.
Assuming there's a situation where the guild name of the player is nil or empty
(when in the process of zoning), you end up calling a no-op function in order
to try to trigger another GUILD_ROSTER_UPDATE. You'll only get another update
if some other addon happens to call GuildRoster after the "cooldown" is over.
Suggested fix (no code yet, I might write something later tonight): move the
initialization code into a proper function of its own (pretty much everything
in the "else" clause of this function) and when we get into this situation,
have the recurring reward OnUpdate event handler call that function until we
get the guild name & initialize successfully. Relying on a second
GUILD_ROSTER_UPDATE is the problem.
BTW, LibGuildStorage does seem to understand that there might be a "cooldown"
for GuildRoster and it calls GuildRoster on every frame until it gets what it
needs. Once it gets the event, it stops the spam. It doesn't seem very elegant
(but then the whole 10 second cooldown thing that Blizzard has given us is
rather ugly), but I guess it works OK there.
Original comment by jmun...@gmail.com
on 5 Jul 2011 at 11:51
I fixed the no-op call to GuildRoster, but I at least playing solo, I wasn't
able to reproduce a nil guild name, so maybe that's not it.
BTW, I noticed that a lot of the code uses "method" calls like
EPGP:CancelRecurringEP() etc. EPGP is a local variable in the main epgp.lua
file, but it's a global variable for the functions in epgp_recurring.lua and
epgp_options.lua. This means that if anything overwrites that global, functions
in those files will stop working. Also, using self instead of a global is
faster & more compact in Lua, so I changed all those as well. The global EPGP
getting overwritten would probably be rather catastrophic, so I doubt that's
the reason for the zapped settings either.
Original comment by jmun...@gmail.com
on 5 Jul 2011 at 3:56
A raid later last night confirmed that my changes didn't fix the issue. I'll
keep looking and report if I manage to find a cure.
Original comment by jmun...@gmail.com
on 6 Jul 2011 at 6:22
I have found one obvious typo in whisper.lua (it should say "enabled"):
mod.dbDefaults = {
profile = {
enable = false,
medium = "GUILD",
}
}
AceDB is cleaning off any values that are equal to their defaults (probably in
order to save some space and so that if the default changes, the value will
change to the new default). The above typo doesn't cause any issues except that
the "enabled" setting for that value is never cleared.
We had a raid tonight (I wasn't loot master though) and the EPGP settings
didn't get wiped. Doesn't prove anything though.
Original comment by jmun...@gmail.com
on 7 Jul 2011 at 10:04
I've long suspected the issue is with acedb or some interaction with it. Let
me know how this works out for you -- definitely a long lasting and annoying
bug I'd love to fix!
Original comment by chip.turner
on 7 Jul 2011 at 10:12
Comment #4 offers an important clue. My interpretation is that you tend to zone
when ghosted and if you get a whisper, it's likely that some log activity
(recurring award) happened at almost the same time as when you zoned (to
release or to re-enter the instance).
I put a debug print statement on the function that trims the EPGP log to one
month length and it shows that it is run every time you zone. It's possible
that log trimming may somehow break the settings DB. It would at least be
consistent with what is happening. My next step is to modify the log module so
that it only trims the log once per login at most and not every time the player
enters the world (once per day or week would be plenty, but takes more effort
to implement).
Another suspect is the arrival of log changes (through AceComm) while zoning or
dead. I might have another look at that code again this weekend.
Original comment by jmun...@gmail.com
on 15 Jul 2011 at 11:06
Issue 715 has been merged into this issue.
Original comment by chip.turner
on 24 Oct 2011 at 2:58
I just pushed a change that I think fixes it:
http://code.google.com/p/epgp/source/detail?r=4e6e0196045cfe791e9b705f936aefcaaf
9a57da
I'm going to test it more but if it proves stable, I'll make a release soon.
Original comment by chip.turner
on 24 Oct 2011 at 2:58
I think 5.6.5 will fix it; if people could try it out, that'd be great!
Original comment by chip.turner
on 25 Oct 2011 at 8:30
I still have such a problem - settings randomly (on zoning?) resetting,
everything gets disabled, without any notifications, and after killing a boss /
looting I have to do stuff manually.
I use v5.7.1.
Original comment by lrdxgm
on 6 Jan 2012 at 12:03
Still experiencing this issue post patch 4.3. It does seem to be related to
zoning, though it doesn't do it every single time, just occasionally.
Original comment by LenaD...@gmail.com
on 10 Feb 2012 at 11:46
[deleted comment]
I found the cause of this problem in epgp.lua. The IsInGuild function fails in
the loading screen(It happens often by zoning and raid difficulty change). Thus
all modules are disabled.
I added the following few lines to at the end of epgp.lua.
local GroupRosterUpdated, GuildRosterUpdated
local OrgGROUP_ROSTER_UPDATE = EPGP.GROUP_ROSTER_UPDATE
local OrgGUILD_ROSTER_UPDATE = EPGP.GUILD_ROSTER_UPDATE
EPGP.GROUP_ROSTER_UPDATE = function() GroupRosterUpdated = true end
EPGP.GUILD_ROSTER_UPDATE = function() GuildRosterUpdated = true end
local OnUpdateFrame = CreateFrame("Frame")
OnUpdateFrame:SetScript("OnUpdate", function(self, elapsed)
if GroupRosterUpdated then
GroupRosterUpdated = nil
OrgGROUP_ROSTER_UPDATE(EPGP)
end
if GuildRosterUpdated then
GuildRosterUpdated = nil
OrgGUILD_ROSTER_UPDATE(EPGP)
end
end)
Original comment by erute...@gmail.com
on 18 Nov 2012 at 6:02
Ah! This is very plausible! I've adapted your patch to do something slightly
different (rev 858dcc7, basically only enabling those events after OnUpdate has
been called). I'll try it out and make sure it works before pushing the diff,
but this seems very plausible.
Great find!
Original comment by chip.turner
on 18 Nov 2012 at 7:05
This happened to me last night; either eruteiHT's idea wasn't right or my
different approach patch didn't fix it. This still seems like it is the cause
so I'm going to add some debug info and such to see if I can nail down the
exact issue.
Original comment by chip.turner
on 22 Nov 2012 at 4:49
This problem has not happened to me for 1.5 month after using fix that I showed.
I saw the latest implement. I guess that OnEnable don't called when zoning.
when you runback or change of raid difficulty it will still happen.
Original comment by erute...@gmail.com
on 1 Dec 2012 at 6:14
The best solution that I think about. GUILD_ROSTER_UPDATE should set OnUpdate
then OnUpdate calls original GUILD_ROSTER_UPDATE, and sets nil to OnUpdate.
It's necessary to do so in GROUP_ROSTER_UPDATE maybe.
Original comment by erute...@gmail.com
on 1 Dec 2012 at 6:30
Original issue reported on code.google.com by
dan.para...@googlemail.com
on 19 Jan 2011 at 7:22