Open GoogleCodeExporter opened 8 years ago
Well, i guess i didnt notice that this should be under enhancements, not issues.
but, i didnt have any option to make it an enhancement...
Original comment by bjorn.so...@gmail.com
on 25 May 2007 at 12:06
I think Alkis will change it to an enhancement request himself. Anyway, I
support
this request too - sounds like a nice feature. Currently, as a workaround, we're
putting their character names in their officer notes (abusing the "alt"
designation
technique by telling EPGP that PlayerA is PlayerA's alt eliminates them from the
listing).
Original comment by morgan...@gmail.com
on 25 May 2007 at 12:19
Original comment by evlogimenos
on 25 May 2007 at 9:27
Original comment by evlogimenos
on 23 Sep 2008 at 11:46
Issue 183 has been merged into this issue.
Original comment by evlogimenos
on 27 Nov 2008 at 11:18
Mark all as New without owner.
Original comment by evlogimenos
on 8 Jan 2009 at 11:03
Original comment by evlogimenos
on 26 Feb 2009 at 12:29
Seconding this request. A simple way to exclude alts and casuals from the
display and
logs would make it a lot more compact & readable. Can you add something like a
MIN_RANK configuration option?
Original comment by johngalt...@gmail.com
on 21 Mar 2009 at 8:01
Original comment by evlogimenos
on 2 Apr 2009 at 9:49
I'd love to have the functionality to give certain guild ranks different levels
of EP.
I have a Core Raider rank which are my very best raiders and are only a select
few.
I'd like to give people at this rank more ep while leaving everyone else at the
standard amount.
Original comment by m.estr...@gmail.com
on 1 Dec 2009 at 4:07
@m.estrada - The idea is to sort the EPGP list by ranks as well as EPGP/PR - So
that
people of a certain rank are either excluded from the list or go lower down the
list
(i.e. a raider rank gets priority over a trial member on loot regardless of
their
PR). Making it so a higher rank gets more ep for being in a raid than other
ranks
might be a big issue especially when those 'non-core' members are putting in as
much
effort on the nights they turn up as the 'core' raiders. The core group will
have
more EP simply because they raid more already, imo they dont need to get more
ep.
Original comment by dingochavezz@gmail.com
on 3 Dec 2009 at 2:10
I would like to have a way to set it so people below a certain rank are put on a
lower tier in the PR listing automatically, so people on trial are easier to
spot
when distributing loot. An extra bit of @EPGP info in the Guild Information tab
could
be added like Min_RANK.
Original comment by dingochavezz@gmail.com
on 28 May 2010 at 2:03
/bumping for inclusion in EPGP 6 please.
Original comment by dingochavezz@gmail.com
on 15 Nov 2010 at 7:58
COMPLETELY UNTESTED
Would this be a good starting point?
split the list into 2 areas, those above min_rank and those below min_rank,
with the usual min_ep being applied to each area as well.
This does mean that those above the min_rank will always show higher than those
below min_rank, regardless of ep, gp, prio, min_ep
Note: this assumes GetRank(name) returns a number from 0 (GM) to 8? 10? (lowest
rank)
diff --git a/epgp.lua b/epgp.lua
--- a/epgp.lua
+++ b/epgp.lua
@@ -254,24 +254,30 @@ local comparators = {
local b_ep, b_gp = EPGP:GetEPGP(b)
return a_gp > b_gp
end,
PR = function(a, b)
local a_ep, a_gp = EPGP:GetEPGP(a)
local b_ep, b_gp = EPGP:GetEPGP(b)
+ local a_rank = EPGP:GetRank(a) >= EPGP.db.profile.min_rank
+ local b_rank = EPGP:GetRank(b) >= EPGP.db.profile.min_rank
+
local a_qualifies = a_ep >= EPGP.db.profile.min_ep
local b_qualifies = b_ep >= EPGP.db.profile.min_ep
- if a_qualifies == b_qualifies then
- return a_ep/a_gp > b_ep/b_gp
- else
- return a_qualifies
- end
+ if a_rank == b_rank then
+ if a_qualifies == b_qualifies then
+ return a_ep/a_gp > b_ep/b_gp
+ else
+ return a_qualifies
+ end
+ else
+ return a_rank
end,
}
for k,f in pairs(comparators) do
comparators[k] = ComparatorWrapper(f)
end
local function DestroyStandings()
wipe(standings)
@@ -567,16 +573,20 @@ function EPGP:GetEPGP(name)
return ep_data[name], gp_data[name] + EPGP.db.profile.base_gp, main
end
end
function EPGP:GetClass(name)
return GS:GetClass(name)
end
+function EPGP:GetRank(name)
+ return GS:GetRank(name)
+end
+
function EPGP:CanIncEPBy(reason, amount)
if not CanEditOfficerNote() or not GS:IsCurrentState() then
return false
end
if type(reason) ~= "string" or type(amount) ~= "number" or #reason == 0 then
return false
end
if amount ~= math.floor(amount + 0.5) then
@@ -657,24 +667,25 @@ end
function EPGP:GetBaseGP()
return EPGP.db.profile.base_gp
end
function EPGP:GetMinEP()
return EPGP.db.profile.min_ep
end
-function EPGP:SetGlobalConfiguration(decay_p, extras_p, base_gp, min_ep)
+function EPGP:SetGlobalConfiguration(decay_p, extras_p, base_gp, min_ep,
min_rank)
local guild_info = GS:GetGuildInfo()
epgp_stanza = string.format(
- "-EPGP-\n@DECAY_P:%d\n@EXTRAS_P:%s\n@MIN_EP:%d\n@BASE_GP:%d\n-EPGP-",
+
"-EPGP-\n@DECAY_P:%d\n@EXTRAS_P:%s\n@MIN_EP:%d\n@BASE_GP:%d\n@MIN_RANK:%d\n-EPGP
-",
decay_p or DEFAULT_DECAY_P,
extras_p or DEFAULT_EXTRAS_P,
min_ep or DEFAULT_MIN_EP,
- base_gp or DEFAULT_BASE_GP)
+ base_gp or DEFAULT_BASE_GP,
+ min_rank or DEFAULT_MIN_RANK)
-- If we have a global configuration stanza we need to replace it
Debug("epgp_stanza:\n%s", epgp_stanza)
if guild_info:match("%-EPGP%-.*%-EPGP%-") then
guild_info = guild_info:gsub("%-EPGP%-.*%-EPGP%-", epgp_stanza)
else
guild_info = epgp_stanza.."\n"..guild_info
end
@@ -744,16 +755,17 @@ function EPGP:OnInitialize()
last_awards = {},
show_everyone = false,
sort_order = "PR",
recurring_ep_period_mins = 15,
decay_p = 0,
extras_p = 100,
min_ep = 0,
base_gp = 1,
+ min_rank = 1,
}
}
db:RegisterDefaults(defaults)
for name, module in self:IterateModules() do
-- Each module gets its own namespace. If a module needs to set
-- defaults, module.dbDefaults needs to be a table with
-- defaults. Otherwise we initialize it to be enabled by default.
if not module.dbDefaults then
@@ -847,14 +859,15 @@ function EPGP:GUILD_ROSTER_UPDATE()
end
end
function EPGP:OnEnable()
GS.RegisterCallback(self, "GuildNoteChanged", ParseGuildNote)
GS.RegisterCallback(self, "GuildNoteDeleted", HandleDeletedGuildNote)
EPGP.RegisterCallback(self, "BaseGPChanged", DestroyStandings)
+ EPGP.RegisterCallback(self, "MinRankChanged", DestroyStandings)
self:RegisterEvent("RAID_ROSTER_UPDATE")
self:RegisterEvent("GUILD_ROSTER_UPDATE")
GuildRoster()
end
diff --git a/guild_info.lua b/guild_info.lua
--- a/guild_info.lua
+++ b/guild_info.lua
@@ -4,16 +4,17 @@ local AE = LibStub("AceEvent-3.0")
-- Parse options. Options are inside GuildInfo and are inside a -EPGP-
-- block. Possible options are:
--
-- @DECAY_P:<number>
-- @EXTRAS_P:<number>
-- @MIN_EP:<number>
-- @BASE_GP:<number>
+-- @MIN_RANK:<number>
local global_config_defs = {
decay_p = {
pattern = "@DECAY_P:(%d+)",
parser = tonumber,
validator = function(v) return v >= 0 and v <= 100 end,
error = L["Decay Percent should be a number between 0 and 100"],
default = 0,
change_message = "DecayPercentChanged",
@@ -37,16 +38,24 @@ local global_config_defs = {
base_gp = {
pattern = "@BASE_GP:(%d+)",
parser = tonumber,
validator = function(v) return v >= 0 end,
error = L["Base GP should be a positive number"],
default = 1,
change_message = "BaseGPChanged",
},
+ min_rank = {
+ pattern = "@MIN_RANK:(%d+)",
+ parser = tonumber,
+ validator = function(v) return v >= 0 end,
+ error = L["Min Rank should be a positive number, in the rannge of allowed
ranks"],
+ default = 1,
+ change_message = "MinRankChanged",
+ },
}
local function ParseGuildInfo(loc)
if not EPGP.db then
Debug("EPGP db not loaded")
return
end
local info = GetGuildInfoText()
Original comment by owenca...@live.co.uk
on 1 Dec 2010 at 10:57
any news on adding this feature or if the idea was tested in the 11 months
since suggestion?
Original comment by seth.law...@gmail.com
on 31 Oct 2011 at 10:33
no news, I'm afraid. it has a lot of stars so it would possibly be something I
would look at soon, but only if major bugs are under control (which seems to be
the case at the moment) and if the scope of it isn't huge (which seems to be
the case here but there are a number of corner cases and concerns that need
some deliberation first).
Original comment by chip.turner
on 31 Oct 2011 at 11:18
Has this been done yet.. I LOVE this idea...
Original comment by 4151...@gmail.com
on 4 Nov 2012 at 7:18
Original issue reported on code.google.com by
bjorn.so...@gmail.com
on 25 May 2007 at 12:05