I just spent some time looking into the modules and stuff, it looks great. :)
Did anyone write a Module to support the following?
- Every Raidmember gets points for a Bosskill, normally fixed per Boss/Instance but it should be customizable for firstkills etc.
- Every Raidmember can bid any sum of points on any item he can use, as long as his points don't go below zero. Other Raidmembers can see the bids and place (higher) bids themselfes, until the Bidding ends.
I'd like to state that my members in my raid I"m testing with dkpmon/bidder are expiriencing the same bug in the screen shot provided above. I also was able to recreate it on my wife's computer vs my computer at my house testing things. At this time one member of my raid was able to create a good working auction while the rest had no luck whatsoever.
We're using zsum-auction for our bid.
All modules are up to date on both sides.
When I use DKPMON/BIDDER and the other person uses BIDDER alone, the symptom is created with the following steps. (Even including notes that might not be even notable)
1. I created a full loot table of "minimum bids" in the custom section of my DKPmon. This is based off Karazhan only.
2. Created 2 dkp pools in custom.lua. 1 was karazhan (1) and other was Gruul's lair(2)
3. Both I (Leadmodule) and raider removed all saved variables on both platforms, to ensure out testing with earlier dkp systems didn't interfere. We did so while out of the game, and rebooted afterwards to ensure ram was clear.
4. Logged into game, raider was in shattrah, I was in different zone east of shattrah.
5. Selected Zsum_auction, set to autoadd items, set loot threshold to gray/poor.
6. Awarded myself and raider 10 dkp
7. Killed random spider
8. Touched corpse, showed "Fractured carapace". Selected minimum bid of 2 to dkppool 1. Assigned points
9. Opened Bidding.
...A. Bidder shows up on my module perfectly.
...B. Bidder shows the error shown in the screen shot on previous page for other raider. Bidder doesn't open up.
10. Close bidding, open bidding, same symptoms except no error (I get bidder window, raider does not)
Interesting notes:
A. After step 10, I checked to see if I could manually set a bid on raider's behalf, it successfully happens and raider gets text confirmation that his bid was accepted.
B. He informed me that he thinks he was able to use the text commands to manipulate what he wanted. The window seems to be the source of the error.
C. This is almost global to all the members of my raid. We have not turned off all the other mods to see if this is a conflict yet, but a friend of mine (raiderchick) has no other addons but bidder, and it repeats the symptom after the steps 1-10 are provided. So I don't think this is a conflict of addons.
D. Have attempted steps 1-10 with raider having DKPmon and zsum module installed for it, same symptom, no change.
E. Same symptoms if the raider is in the same area as me or in a distance. I was not able to test with an item from my pre-designed list, as we're attempting Karazhan first time this upcoming weekend.
F. All other portions of Bidder work for other people, it's specifically surrounding the bidder window, when it appears and attempt to propogate the information about the item.
I don't know if this is a very tedious to read post... but I figured any information to fix this bug is very useful. If this bug is fixed, dkpmon/bidder are the backbone of my future raids, hands down.
I'd like to state that my members in my raid I"m testing with dkpmon/bidder are expiriencing the same bug in the screen shot provided above. I also was able to recreate it on my wife's computer vs my computer at my house testing things. At this time one member of my raid was able to create a good working auction while the rest had no luck whatsoever.
We're using zsum-auction for our bid.
All modules are up to date on both sides.
When I use DKPMON/BIDDER and the other person uses BIDDER alone, the symptom is created with the following steps. (Even including notes that might not be even notable)
1. I created a full loot table of "minimum bids" in the custom section of my DKPmon. This is based off Karazhan only.
2. Created 2 dkp pools in custom.lua. 1 was karazhan (1) and other was Gruul's lair(2)
3. Both I (Leadmodule) and raider removed all saved variables on both platforms, to ensure out testing with earlier dkp systems didn't interfere. We did so while out of the game, and rebooted afterwards to ensure ram was clear.
4. Logged into game, raider was in shattrah, I was in different zone east of shattrah.
5. Selected Zsum_auction, set to autoadd items, set loot threshold to gray/poor.
6. Awarded myself and raider 10 dkp
7. Killed random spider
8. Touched corpse, showed "Fractured carapace". Selected minimum bid of 2 to dkppool 1. Assigned points
9. Opened Bidding.
...A. Bidder shows up on my module perfectly.
...B. Bidder shows the error shown in the screen shot on previous page for other raider. Bidder doesn't open up.
10. Close bidding, open bidding, same symptoms except no error (I get bidder window, raider does not)
Interesting notes:
A. After step 10, I checked to see if I could manually set a bid on raider's behalf, it successfully happens and raider gets text confirmation that his bid was accepted.
B. He informed me that he thinks he was able to use the text commands to manipulate what he wanted. The window seems to be the source of the error.
C. This is almost global to all the members of my raid. We have not turned off all the other mods to see if this is a conflict yet, but a friend of mine (raiderchick) has no other addons but bidder, and it repeats the symptom after the steps 1-10 are provided. So I don't think this is a conflict of addons.
D. Have attempted steps 1-10 with raider having DKPmon and zsum module installed for it, same symptom, no change.
E. Same symptoms if the raider is in the same area as me or in a distance. I was not able to test with an item from my pre-designed list, as we're attempting Karazhan first time this upcoming weekend.
F. All other portions of Bidder work for other people, it's specifically surrounding the bidder window, when it appears and attempt to propogate the information about the item.
I don't know if this is a very tedious to read post... but I figured any information to fix this bug is very useful. If this bug is fixed, dkpmon/bidder are the backbone of my future raids, hands down.
That is an absolutely awesome bug report! Just in case it's a factor, can you email me the custom.lua file that you wrote up? My email address is in the .toc file for DKPmon and Bidder. I'm not going to have the time to look at this tonight, I expect, but I will look into it deeper this weekend.
Oh, regarding your point (B). There are no text commands for casting a bid. ;) The confirmation that he's seeing isn't linked to the window in any way, nor does it require that an auction was set up correctly -- which is probably why he still received it after the error.
-Eraslin
edit: Can you also get me the revision number of the AceComm-2.0 library that raiderchick is using? She can look it up in the header of Bidder\Libs\AceComm-2.0\AceComm-2.0.lua My standing theory about this bug is that the item link isn't getting sent correctly by AceComm, for some reason.
Eraslin.
Thanks for your reply on my question about a FCZS variant earlier on this thread.
(external addon as cost provider, multiple pool support).
It looks like the best way to go.
Quote from Eraslin »
Astaldo:
iteminfo.zone is the name of the zone that you were in when the item dropped. You might consider just putting in a big ol' if-then in your :GetItemInfo(iteminfo) function that maps zone names to pool numbers.
Looking over DKPmon code to see where zone is populated I find it in looting.lua:71 (local zone = GetZoneText()).
Most other addons I know that deal with zones (map addons like atlas, gathering addons, bigwigs etc) are using GetRealZoneText
The comment at the API page I'm linking suggests GetRealZone returns more standard zone names.
I'm thinking to use Babble-Zone-2.2 for zone names instead of Periodic Table (seems overkill for just zone names).
I'm worried that iteminfo.zone would have some discrepancies due to using different APIs.
While I have your ear...
If I choose the big ol' if-then idea (in fczs.lua) which seems easier to hack up in a hurry.
My code will be something like
if (iteminfo.zone) then
if (iteminfo.zone == "Karazhan") then
dkpinfo.poolIndex = 1
dkpinfo.poolName = "Kaz/Gru/Mag";
elseif (iteminfo.zone == ..
.
. etc
do I have to keep the exact duplicates in custom.lua?
custom.poolnames = {
[1] = "Kaz/Gru/Mag",
.
.etc ?
local cInfo = DKPmon.Custom:Get(<your module identifier string here>)
dkpinfo.pool = cInfo.zonemap[iteminfo.zone]
if pool == nil then
error("Don't have a pool number for zone "..iteminfo.zone)
return nil
end
dkpinfo.poolName = cInfo.poolnames[dkpinfo.pool]
If you're going to put the pool number determination in your DKP-points addon, then just make zonemap a table in that addon instead. But, that's the way I'd assign the poolName.
Then in your custom.lua just add a table, .zonemap, that is indexed by zone name ("Karazhan", "Molten Core", etc") and gives the pool number for that zone.
ex:
It just occured to me that I should probably find out what version of AceComm-2.0 you're running as well in your tests -- just in case it's different from raiderchick's. So, could you send me that as well?
Myself: AceComm-2.0.25921
Hrm.... well lookie there, out of date. Raider and raider chick are not online, I'll update later, As well, I'll update all our AceComms as well and see how that goes.
Now, when the other person is present for a bid, this happens.
[i]:: /buggrabber 1[/i]
Bidder-2.0.0\Looting\lootitem.lua:150: Usage: GetItemInfo(itemID|"name"|"itemlink")
Bidder-2.0.0\Looting\lootitem.lua:150: in function `SetItem'
Bidder-2.0.0\Looting\lootframe.lua:241: in function `f'
Bidder-2.0.0\Comm\comm.lua:153: in function `DispatchMessages'
Bidder-2.0.0\main.lua:56: in function `func' Metrognome-2.0-29790 (Metrognome):182:in function <...\AddOns\Metrognome\Metrognome-2.0\Metrognome-2.0.lua:176
RESOLUTION PROCEDURE: [i]With this information I found out quickly that the metrognome on the bidder addon is horridly out of date. This may have been downloaded directly from your googlepages site. And since the revision isn't changed, it won't update the bidder automatically with the aceupdater.
So to resolve this error, update your metrognome to current patch, and upload a new revision, that should fix it for tons of peeps.
First off a bit out of topic,
it's great to witness such kind of cooperation between author and users as Eraslin/Jacklifear :)
Back to my Fixed Cost Zero Sum variant.
Everything is coming along quite nicely.
A question not for Eraslin specifically(seem to have alot to deal with already) but anyone that has used the FCZS module.
Is the only way to test the module to do a raid and get actual boss drops?
I tried the following procedure to test it.
Make a 2-man raid.
I am RL and masterlooter.
Setup DKPmon to use the Fixed Cost Zero Sum system.
Use /dkpmon biditem <itemlink1> <itemlink2>
with items from my inventory to populate the Loot Distribution window.
Use Actions to:
1. Open bidding.
- I bid on item1 (from bidder)
2. Close bidding.
3. Select winner.
4. Announce winner.
At this point I'm getting stuck.
The relevant portion of the manual says:
Note #2: If you are using one of the zero-sum modules, points will not be awarded by selecting "deduct points"
-- hence the use of the word "deduct" rather than "adjust", or something similar.
You must go through the "Points awarding" window to award the points from distributed items.
If I don't select "Deduct Points" from winner and instead open the "Points Awarding" frame.
In the middle "sub window" you will find DKP system specific widgets to allow you to select how many points you want to select.
What appears here depends on what DKP system you are using.
If you are using one of the zero-sum modules, you will be able to choose the name of a downed boss
-- this will set DKPmon up to distribute points equal to the item-drop value of the boss divided by the number of players you've selected to each player selected.
Hence my original question.
Is there no other way to test the point allocation than do an actual raid and kill a boss recognized by DKPmon?
If that is the case, what is the expected behaviour of the Award Points button?
Deducts item cost from winner and distribute evenly among raid members all in one push of the Award Points button?
Appreciate the help from anyone familiar with FCSZ.
I'd be happy to expand on the Zero-sum portion of the manual and submit it for inclusion, but I have to figure it out myself first :)
Lastly, is it possible to run parallel raids to the same dungeon (eg. 2 raids to Karazhan).
Assume I am managing raid1 dkp and RL2 is managing raid2 dkp.
Is it sufficient for both of us to form a raid before starting the raids, synch,
then form a raid again after both our respective raids are done and synch again?
(raid1 roster and raid2 roster considered mutually exclussive)
Now, when the other person is present for a bid, this happens.
[i]:: /buggrabber 1[/i]
Bidder-2.0.0\Looting\lootitem.lua:150: Usage: GetItemInfo(itemID|"name"|"itemlink")
Bidder-2.0.0\Looting\lootitem.lua:150: in function `SetItem'
Bidder-2.0.0\Looting\lootframe.lua:241: in function `f'
Bidder-2.0.0\Comm\comm.lua:153: in function `DispatchMessages'
Bidder-2.0.0\main.lua:56: in function `func' Metrognome-2.0-29790 (Metrognome):182:in function <...\AddOns\Metrognome\Metrognome-2.0\Metrognome-2.0.lua:176
RESOLUTION PROCEDURE: [i]With this information I found out quickly that the metrognome on the bidder addon is horridly out of date. This may have been downloaded directly from your googlepages site. And since the revision isn't changed, it won't update the bidder automatically with the aceupdater.
So to resolve this error, update your metrognome to current patch, and upload a new revision, that should fix it for tons of peeps.
The error was caused by Metrognome being out of date?! Wow, that completely blows by mind! Seriously, I wouldn't have expected for a minute that updating metrognome would have fixed that error; it looked like the item link just wasn't getting sent. I'll update the googlepages downloads later tonight.
Regardless of the DKP system being used, you still need to hit "deduct points" after announcing the winner -- this will deduct the points for the item(s) from the winner. In the case of the zero-sum system, this will also tally up the points that need to be awarded but won't actually award them -- the "note 2" in the manual was a late-night fustrated addition after getting a few emails where people didn't realize that "deduct" points didn't also award points in the zero-sum systems.
Then, you go to the award frame to distribute points. When using zero-sum, the action of hitting "deduct points" in the loot window will set up an item for you to select from the dewdrop menu you get from clicking the button in the middle frame. In the case of setting items from the console via the /biditem command the "boss' name" will be "Console", otherwise it'll be the name of the boss/mob that dropped the item.
To summarize, regardless of the system being used, all loot distributions follow these steps:
1) Looting window:
a) Open bidding
b) Close bidding
c) Select winner(s)
d) Announce winner(s)
e) Deduct points
2) Award points window:
a) Select members from raid to award points to
b) Query standby members, if you desire
c) Select players from your database to also receive points if you want
d) Interact with the widgets in the middle "mini-frame" to select the amount of points to be awarded
e) Click "Award Points"
3) Optional, but recommended
a) Run "/dkp bcast" to share your updated points database with other raid officers (distributed backups are a good idea)
b) Run "/console reloadui" to write your updated database to disk; ensuring that a game crash doesn't wipe out your changes.
b) Run "/console reloadui" to write your updated database to disk; ensuring that a game crash doesn't wipe out your changes.
For those who didn't know, since Ace2 is loaded when you load DKPmon, Ace2 peeps were nice enough to make a command for /rl (As in Re-Load ui) which does the /console reloadui command. This makes for easier on the peeps who are trying their best to learn systems and addons as a whole ;)
Is it possible to enable auto-start logging when in a raid? CTRaidTracker had this option which saved us from a few errors down the line. My guild is not using DKP for Karazhan yet but we need the loot and attendance logs.
But E-man, I gotta favor of a minor feature for you to add. I need the ability to remove or tweak the bids. For example, we have 4 peeps with 40 dkp each. The bidwar (zsumauction) goes upwards a bit, (oh noes! 24 dkp, you animal!) and it gets to the point that someone is a putz and types 255 instead of 25 dkp.
... someone else wants to bid 26... another wants to do 31... but they can't bid, cause it's less than current bid. We have to revert to tells. It's something that can be abused and easily fixed by freezing the timer and having an admin edit it. Another alternative is restarting the bid. And frankly, that's just inconvient.. which is against your clause of "This addon rules cause it's not inconvient!"
Another feature (that's merely interface mind you) is in the long run to have a little set of dots on the right side of the Loot distributing interface that's verticle and non-clickable. The location of the bullet and it's tooltip can be an easy indicator of which step of the process you are on. *note the ones you posted above*.
This should help not only the sleek look of the addon (You can use different things than dots, it was just an idea, but yeah, still very uber! And stuffs.... and MOTIVATION UBER! And whatnot!)
Oh, and the error for Lootitem.lua:150 is back again (same ones as above) with many members. Metrognome didn't resolve it, only made it sparatically resolved.
Is it possible to enable auto-start logging when in a raid? CTRaidTracker had this option which saved us from a few errors down the line. My guild is not using DKP for Karazhan yet but we need the loot and attendance logs.
Have to say, this mod looks really nice.
I was trying to stray away from automatic log starting; only because not all raids are DKP raids (ex: running around in ZG/MC/UBRS for nostalgia). What I can probably do, though, it create a popup that asks if you want to start a log when you join a raid -- could potentially be annoying though (so I'd probably have a toggle to disable the popup, and thus, the autostart).
Would that be a useful feature for most people?
Jacklifear:
I can probably swing some sort of way to remove stupid bids; I'll have to refamiliarize myself with that module, though. ;-)
I guess it would have been too easy if the bug was from an out-of-date metrognome. :-(
eqDKP export is now working, great job! The only thing it's not providing is the cost of the item, but I think that should be easy to fix if you wanted and it's certainly not a huge issue since Dahn is working on his own module.
Bidder/Looting/lootitem.lua:150 bug is fixed! /flex
Long story short, AceComm does not appear to receive item links if the item is not in the users local cache.
So, I'll be submitting a bug report to ckknight for AceComm to, hopefully, get it fixed in the main library.
In the meantime, I've got a hack in place to get around it. As part of this hack, I had to address another bug with the Bidder window when the itemlink isn't in the user's local cache. The result of the bugfix is that if a bidding item is not in the user's local cache, the item's icon will appear blank in the Bidder window, and the item's name will always be "epic" coloured. Furthermore, the user might not get the mouse-over tooltip from the Bidder window; if this happens, they just need to click the item link for the item in raid chat, and they'll start getting the mouse-over tooltip again.
Fixed version's in the svn, and I'll have it on googlepages in a little bit.
Anyways, there ya go. What an absolute pain in the arse!
seems ckknight was quick to address this.
Ace2 r29920
.AceComm-2.0 - apparently, if you receive an item link that is not in your local cache, GetItemInfo() returns nil, so starting on March 21, AceComm-2.0 will send the name and color with the link.
Question: before I push an update out to my guild.
Will your workaround function properly with the new Ace2 installed?
What's a working combo currently?
seems ckknight was quick to address this.
Ace2 r29920
.AceComm-2.0 - apparently, if you receive an item link that is not in your local cache, GetItemInfo() returns nil, so starting on March 21, AceComm-2.0 will send the name and color with the link.
Question: before I push an update out to my guild.
Will your workaround function properly with the new Ace2 installed?
What's a working combo currently?
Edit: erm now I'm not so sure ... March 21?
I bugged ckknight on IRC last night, so I guess he's fixed it in the library already. I just glanced at the AceComm code, and it appears that the fix is indeed in. So, I'm going to remove my hack.
To have fully working DKPmon/Bidder, everyone in the raid will need to be using DKPmon v2.2.0 and Bidder v2.1.0. I changed my internal comm version to force the update -- so Bidder & DKPmon lower than those versions will not talk with the new versions (they'll be silently ignored). They're currently in the svn, and I'll put 'em on googlepages in a bit.
-Eraslin
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
Did anyone write a Module to support the following?
- Every Raidmember gets points for a Bosskill, normally fixed per Boss/Instance but it should be customizable for firstkills etc.
- Every Raidmember can bid any sum of points on any item he can use, as long as his points don't go below zero. Other Raidmembers can see the bids and place (higher) bids themselfes, until the Bidding ends.
I'd like to state that my members in my raid I"m testing with dkpmon/bidder are expiriencing the same bug in the screen shot provided above. I also was able to recreate it on my wife's computer vs my computer at my house testing things. At this time one member of my raid was able to create a good working auction while the rest had no luck whatsoever.
We're using zsum-auction for our bid.
All modules are up to date on both sides.
When I use DKPMON/BIDDER and the other person uses BIDDER alone, the symptom is created with the following steps. (Even including notes that might not be even notable)
1. I created a full loot table of "minimum bids" in the custom section of my DKPmon. This is based off Karazhan only.
2. Created 2 dkp pools in custom.lua. 1 was karazhan (1) and other was Gruul's lair(2)
3. Both I (Leadmodule) and raider removed all saved variables on both platforms, to ensure out testing with earlier dkp systems didn't interfere. We did so while out of the game, and rebooted afterwards to ensure ram was clear.
4. Logged into game, raider was in shattrah, I was in different zone east of shattrah.
5. Selected Zsum_auction, set to autoadd items, set loot threshold to gray/poor.
6. Awarded myself and raider 10 dkp
7. Killed random spider
8. Touched corpse, showed "Fractured carapace". Selected minimum bid of 2 to dkppool 1. Assigned points
9. Opened Bidding.
...A. Bidder shows up on my module perfectly.
...B. Bidder shows the error shown in the screen shot on previous page for other raider. Bidder doesn't open up.
10. Close bidding, open bidding, same symptoms except no error (I get bidder window, raider does not)
Interesting notes:
A. After step 10, I checked to see if I could manually set a bid on raider's behalf, it successfully happens and raider gets text confirmation that his bid was accepted.
B. He informed me that he thinks he was able to use the text commands to manipulate what he wanted. The window seems to be the source of the error.
C. This is almost global to all the members of my raid. We have not turned off all the other mods to see if this is a conflict yet, but a friend of mine (raiderchick) has no other addons but bidder, and it repeats the symptom after the steps 1-10 are provided. So I don't think this is a conflict of addons.
D. Have attempted steps 1-10 with raider having DKPmon and zsum module installed for it, same symptom, no change.
E. Same symptoms if the raider is in the same area as me or in a distance. I was not able to test with an item from my pre-designed list, as we're attempting Karazhan first time this upcoming weekend.
F. All other portions of Bidder work for other people, it's specifically surrounding the bidder window, when it appears and attempt to propogate the information about the item.
I don't know if this is a very tedious to read post... but I figured any information to fix this bug is very useful. If this bug is fixed, dkpmon/bidder are the backbone of my future raids, hands down.
That is an absolutely awesome bug report! Just in case it's a factor, can you email me the custom.lua file that you wrote up? My email address is in the .toc file for DKPmon and Bidder. I'm not going to have the time to look at this tonight, I expect, but I will look into it deeper this weekend.
Oh, regarding your point (B). There are no text commands for casting a bid. ;) The confirmation that he's seeing isn't linked to the window in any way, nor does it require that an auction was set up correctly -- which is probably why he still received it after the error.
-Eraslin
edit: Can you also get me the revision number of the AceComm-2.0 library that raiderchick is using? She can look it up in the header of Bidder\Libs\AceComm-2.0\AceComm-2.0.lua My standing theory about this bug is that the item link isn't getting sent correctly by AceComm, for some reason.
Thanks for your reply on my question about a FCZS variant earlier on this thread.
(external addon as cost provider, multiple pool support).
It looks like the best way to go.
Looking over DKPmon code to see where zone is populated I find it in looting.lua:71 (local zone = GetZoneText()).
Most other addons I know that deal with zones (map addons like atlas, gathering addons, bigwigs etc) are using GetRealZoneText
The comment at the API page I'm linking suggests GetRealZone returns more standard zone names.
I'm thinking to use Babble-Zone-2.2 for zone names instead of Periodic Table (seems overkill for just zone names).
I'm worried that iteminfo.zone would have some discrepancies due to using different APIs.
While I have your ear...
If I choose the big ol' if-then idea (in fczs.lua) which seems easier to hack up in a hurry.
My code will be something like
if (iteminfo.zone) then
if (iteminfo.zone == "Karazhan") then
dkpinfo.poolIndex = 1
dkpinfo.poolName = "Kaz/Gru/Mag";
elseif (iteminfo.zone == ..
.
. etc
do I have to keep the exact duplicates in custom.lua?
custom.poolnames = {
[1] = "Kaz/Gru/Mag",
.
.etc ?
Thanks again for your input and a great addon.
I would probably do something like this:
If you're going to put the pool number determination in your DKP-points addon, then just make zonemap a table in that addon instead. But, that's the way I'd assign the poolName.
Then in your custom.lua just add a table, .zonemap, that is indexed by zone name ("Karazhan", "Molten Core", etc") and gives the pool number for that zone.
ex:
Jacklifear:
It just occured to me that I should probably find out what version of AceComm-2.0 you're running as well in your tests -- just in case it's different from raiderchick's. So, could you send me that as well?
Hrm.... well lookie there, out of date. Raider and raider chick are not online, I'll update later, As well, I'll update all our AceComms as well and see how that goes.
Now, when the other person is present for a bid, this happens.
[i]:: /buggrabber 1[/i]
Bidder-2.0.0\Looting\lootitem.lua:150: Usage: GetItemInfo(itemID|"name"|"itemlink")
Bidder-2.0.0\Looting\lootitem.lua:150: in function `SetItem'
Bidder-2.0.0\Looting\lootframe.lua:241: in function `f'
Bidder-2.0.0\Comm\comm.lua:153: in function `DispatchMessages'
Bidder-2.0.0\main.lua:56: in function `func' Metrognome-2.0-29790 (Metrognome):182:in function <...\AddOns\Metrognome\Metrognome-2.0\Metrognome-2.0.lua:176
RESOLUTION PROCEDURE: [i]With this information I found out quickly that the metrognome on the bidder addon is horridly out of date. This may have been downloaded directly from your googlepages site. And since the revision isn't changed, it won't update the bidder automatically with the aceupdater.
So to resolve this error, update your metrognome to current patch, and upload a new revision, that should fix it for tons of peeps.
it's great to witness such kind of cooperation between author and users as Eraslin/Jacklifear :)
Back to my Fixed Cost Zero Sum variant.
Everything is coming along quite nicely.
A question not for Eraslin specifically(seem to have alot to deal with already) but anyone that has used the FCZS module.
Is the only way to test the module to do a raid and get actual boss drops?
I tried the following procedure to test it.
Make a 2-man raid.
I am RL and masterlooter.
Setup DKPmon to use the Fixed Cost Zero Sum system.
Use /dkpmon biditem <itemlink1> <itemlink2>
with items from my inventory to populate the Loot Distribution window.
Use Actions to:
1. Open bidding.
- I bid on item1 (from bidder)
2. Close bidding.
3. Select winner.
4. Announce winner.
At this point I'm getting stuck.
The relevant portion of the manual says:
If I don't select "Deduct Points" from winner and instead open the "Points Awarding" frame.
Hence my original question.
Is there no other way to test the point allocation than do an actual raid and kill a boss recognized by DKPmon?
If that is the case, what is the expected behaviour of the Award Points button?
Deducts item cost from winner and distribute evenly among raid members all in one push of the Award Points button?
Appreciate the help from anyone familiar with FCSZ.
I'd be happy to expand on the Zero-sum portion of the manual and submit it for inclusion, but I have to figure it out myself first :)
Lastly, is it possible to run parallel raids to the same dungeon (eg. 2 raids to Karazhan).
Assume I am managing raid1 dkp and RL2 is managing raid2 dkp.
Is it sufficient for both of us to form a raid before starting the raids, synch,
then form a raid again after both our respective raids are done and synch again?
(raid1 roster and raid2 roster considered mutually exclussive)
The error was caused by Metrognome being out of date?! Wow, that completely blows by mind! Seriously, I wouldn't have expected for a minute that updating metrognome would have fixed that error; it looked like the item link just wasn't getting sent. I'll update the googlepages downloads later tonight.
Thanks a tonne!
Regardless of the DKP system being used, you still need to hit "deduct points" after announcing the winner -- this will deduct the points for the item(s) from the winner. In the case of the zero-sum system, this will also tally up the points that need to be awarded but won't actually award them -- the "note 2" in the manual was a late-night fustrated addition after getting a few emails where people didn't realize that "deduct" points didn't also award points in the zero-sum systems.
Then, you go to the award frame to distribute points. When using zero-sum, the action of hitting "deduct points" in the loot window will set up an item for you to select from the dewdrop menu you get from clicking the button in the middle frame. In the case of setting items from the console via the /biditem command the "boss' name" will be "Console", otherwise it'll be the name of the boss/mob that dropped the item.
To summarize, regardless of the system being used, all loot distributions follow these steps:
1) Looting window:
a) Open bidding
b) Close bidding
c) Select winner(s)
d) Announce winner(s)
e) Deduct points
2) Award points window:
a) Select members from raid to award points to
b) Query standby members, if you desire
c) Select players from your database to also receive points if you want
d) Interact with the widgets in the middle "mini-frame" to select the amount of points to be awarded
e) Click "Award Points"
3) Optional, but recommended
a) Run "/dkp bcast" to share your updated points database with other raid officers (distributed backups are a good idea)
b) Run "/console reloadui" to write your updated database to disk; ensuring that a game crash doesn't wipe out your changes.
-Eraslin
For those who didn't know, since Ace2 is loaded when you load DKPmon, Ace2 peeps were nice enough to make a command for /rl (As in Re-Load ui) which does the /console reloadui command. This makes for easier on the peeps who are trying their best to learn systems and addons as a whole ;)
Have to say, this mod looks really nice.
But E-man, I gotta favor of a minor feature for you to add. I need the ability to remove or tweak the bids. For example, we have 4 peeps with 40 dkp each. The bidwar (zsumauction) goes upwards a bit, (oh noes! 24 dkp, you animal!) and it gets to the point that someone is a putz and types 255 instead of 25 dkp.
... someone else wants to bid 26... another wants to do 31... but they can't bid, cause it's less than current bid. We have to revert to tells. It's something that can be abused and easily fixed by freezing the timer and having an admin edit it. Another alternative is restarting the bid. And frankly, that's just inconvient.. which is against your clause of "This addon rules cause it's not inconvient!"
Another feature (that's merely interface mind you) is in the long run to have a little set of dots on the right side of the Loot distributing interface that's verticle and non-clickable. The location of the bullet and it's tooltip can be an easy indicator of which step of the process you are on. *note the ones you posted above*.
This should help not only the sleek look of the addon (You can use different things than dots, it was just an idea, but yeah, still very uber! And stuffs.... and MOTIVATION UBER! And whatnot!)
I'll provide feedback later about it.
I was trying to stray away from automatic log starting; only because not all raids are DKP raids (ex: running around in ZG/MC/UBRS for nostalgia). What I can probably do, though, it create a popup that asks if you want to start a log when you join a raid -- could potentially be annoying though (so I'd probably have a toggle to disable the popup, and thus, the autostart).
Would that be a useful feature for most people?
Jacklifear:
I can probably swing some sort of way to remove stupid bids; I'll have to refamiliarize myself with that module, though. ;-)
I guess it would have been too easy if the bug was from an out-of-date metrognome. :-(
eqDKP export is now working, great job! The only thing it's not providing is the cost of the item, but I think that should be easy to fix if you wanted and it's certainly not a huge issue since Dahn is working on his own module.
Bidder/Looting/lootitem.lua:150 bug is fixed! /flex
Long story short, AceComm does not appear to receive item links if the item is not in the users local cache.
So, I'll be submitting a bug report to ckknight for AceComm to, hopefully, get it fixed in the main library.
In the meantime, I've got a hack in place to get around it. As part of this hack, I had to address another bug with the Bidder window when the itemlink isn't in the user's local cache. The result of the bugfix is that if a bidding item is not in the user's local cache, the item's icon will appear blank in the Bidder window, and the item's name will always be "epic" coloured. Furthermore, the user might not get the mouse-over tooltip from the Bidder window; if this happens, they just need to click the item link for the item in raid chat, and they'll start getting the mouse-over tooltip again.
Fixed version's in the svn, and I'll have it on googlepages in a little bit.
Anyways, there ya go. What an absolute pain in the arse!
-Eraslin
Ace2 r29920
Question: before I push an update out to my guild.
Will your workaround function properly with the new Ace2 installed?
What's a working combo currently?
Edit: erm now I'm not so sure ... March 21?
I bugged ckknight on IRC last night, so I guess he's fixed it in the library already. I just glanced at the AceComm code, and it appears that the fix is indeed in. So, I'm going to remove my hack.
To have fully working DKPmon/Bidder, everyone in the raid will need to be using DKPmon v2.2.0 and Bidder v2.1.0. I changed my internal comm version to force the update -- so Bidder & DKPmon lower than those versions will not talk with the new versions (they'll be silently ignored). They're currently in the svn, and I'll put 'em on googlepages in a bit.
-Eraslin