Recurring awards do not check for data staleness

[GoogleCodeExporter]

This causes race conditions and data corruption.

Original issue reported on code.google.com by evlogimenos on 16 Aug 2009 at 10:35

[GoogleCodeExporter]

Is this the same issue that I am seeing with 5.5.6 though to 5.5.9 where standby
awards often award at full rate?

EPGP:IncMassEPBy has a bit of a flaw...

        if EPGP:IsMemberInExtrasList(name) then
         DEFAULT_CHAT_FRAME:AddMessage("EPGP debug : "..name.." in extras list")
         extras_awarded[EPGP:IncEPBy(name, extras_reason,
                                      extras_amount, true)] = true
        else
          awarded[EPGP:IncEPBy(name, reason, amount, true)] = true
        end

This defaults to 100% EP if it can't find the person in the extras list. It 
seems
that it's passing the check at line 776 ie:

    if EPGP:IsMemberInAwardList(name) then

but then failing the check at line 786 ie: 

    if EPGP:IsMemberInExtrasList(name) then

Since both check similar things ie:

return UnitInRaid(name) or selected[name]

vs

return UnitInRaid("player") and selected[name]

it suggests that perhaps selected[name] is getting changed perhaps?

I was wondering wouldn't it be a lot simpler to have the test the other way 
round and
award 100% if name was in raid and default to standby if not? ie:

        if UnitInRaid(name) then
          awarded[EPGP:IncEPBy(name, reason, amount, true)] = true
        else
         extras_awarded[EPGP:IncEPBy(name, extras_reason,
                                      extras_amount, true)] = true
        end

This would mean that the default wasn't 100% it was the standby amount and we 
would
no longer get the situation where those on standby are getting 100% of EP for 
only
doing a /w every 15 mins :)

I hope this helps solve the issue. If this isn't linked to the original issue 
would
it be better if I posted a new issue and deleted this post?

Original comment by ShammyLe...@gmail.com on 4 Nov 2009 at 6:27

[GoogleCodeExporter]

EPGP:IsMemberInAwardList(name) is not similar to if 
EPGP:IsMemberInExtrasList(name). 
They are completely different :-). The code is correct, the problem is that the 
extras_amount gets reset to 100% of the amount when you are zoning because of a 
deep architectural mistake. It needs quite a bit of work to be fixed and it 
will when I 
find a large chunk of time to work on it. Thanks for trying to debug it though!

Original comment by evlogimenos on 6 Nov 2009 at 10:05

[GoogleCodeExporter]

No problem, trying to help as its causing issues with the guild EPGP acceptance.

I did appreciate that the two checks were actually different I didn't say they 
were
identical merely similar. NB similar doesn't mean the same just fairly closely
related. :)

As a temp fix until you get the zoning issue resolved, perhaps changing the 
order as
I suggested would at least change the default situation so that only those in 
the
raid got the full award, anyone not in the raid but still on the award list 
would get
standby amounts. Since this is the intention of the checks my fix would at least
solve the current issue until you have time to code a proper fix.

Original comment by ShammyLe...@gmail.com on 9 Nov 2009 at 11:51

[GoogleCodeExporter]

Your suggestion won't fix it. The problem is not that we don't know who is 
standby or 
who is not when we zone. The problem is that the standby modifier gets reset to 
100% 
for a short period of time.

Original comment by evlogimenos on 9 Nov 2009 at 12:31

[GoogleCodeExporter]

Ah ofc, sorry. Oh well back to the drawing board. If there is something I can 
do to
assist let me know, would be happy to see if I can help.

Original comment by ShammyLe...@gmail.com on 9 Nov 2009 at 3:25

[GoogleCodeExporter]

This should be fixed in epgp-6.

Relevant change: 
http://code.google.com/p/epgp/source/detail?r=2c1a977119cb1dce51fba66131431f840c
7e13b2

Original comment by evlogimenos on 2 Dec 2010 at 11:39

• Changed state: Fixed
• Added labels: Version-6
• Removed labels: Version-5