• 0

    posted a message on DKPmon & Bidder v2.0
    Quote from baldylox »

    im looking for some help to change announcements of winners to the raid.

    currently we are using bossauction and our winners are based off the 2nd highest bid +1 pt. id like to adjust the code to pick the 2nd highest bid, add 1 pt and then announce. Some tips maybe for what part of the lua to look in and what section of code to edit?

    what if 3 matching tokens dropped off 1 boss? would i be able to have it pick 3rd highest +1?

    if this is too complicated i can jsut keep using manual look at the winner list and announce via vent :D

    thx for any input


    I already announce the Cost of an item in BossAuction. To do this I hooked DKPmon's Announce function. I just call GetCost for the item and print it right after the item's announcement. However, the right way to do it is probably to modify DKPmon and add a OnAnnounce method to the interface. For DKPsystems that don't implement it a default function would be called with the behavior DKPmon has now. Eraslin, if you do this, could you also add on OnMasterLoot in case people want to announce in guild chat who won an item.

    The multiple token thing is annoying. For BossAuction silent bidding the cost for both winners should go to the 3rd person + 1. I tell all the bidders to bid the same amount on both items. Inevitably not everyone does. After bidding, what I do right now is select player A on one item, player B on the other item. Player B will have the correct cost. Then I refund player A the difference in their cost vs what player B paid.

    To correctly handle this case the items would have to be grouped into one button or else a bid to one item would be duplicated to the other. Then the GetCost function would have to check for duplicates and compute the cost accordingly.

    Eraslin, do you think there should be a item ignore list in DKPmon to ignore items like Badges of Justice? Or is this the responsibility of the dkp system module to ignore?

    Also, I'm close to a release candidate for my dkp web app, which handles multiple pools and DKPmon imports. Hopefully I'll have it out today or tomorrow. I just tried modifying DKPmon_XML to export a giant string of all your logs so that it'd be easier to get started with the web app. Turns out it crashes Wow. I guess they don't check the limit on the edit box text string or something. Anyway, people will have to upload logs one by one. I'll make a post here when I have a release ready.
    Posted in: General AddOns
  • 0

    posted a message on ZOMGBuffs Official Thread
    I apologize if this has been mentioned already, but I don't want to wade through 20 pages of bug reports. In the buff display, instead of showing only the pally buffs that are assigned, could ZOMGbuff show the blessings that a player currently has, and somehow mark any blessings that they shouldn't. Maybe a small red rectangle, or an X over the buff or something. Also, this is low priority, but Detect Invisibility isn't available for warlocks and it'd be nice to have the option to buff pets. (for Arena)


    -Javek
    Posted in: General AddOns
  • 0

    posted a message on DKPmon Module: BossAuction
    Ok, I'll implement your idea when I have time. However, that probably won't be til after spring break. Would you want this feature controlled through the custom.lua file or through the DKPmon System's options menu? The advantage of the custom.lua file is you can share it and everyone will have the same settings/policy, but then again it's a pain to share.
    Posted in: General AddOns
  • 0

    posted a message on DKPmon Module: BossAuction
    I assume the problem you're having is people are bidding at the last second before bidding ends and people don't like it. The easiest solution is to just tell people to bid higher, if someone sneaks a bid they still have to pay the price.

    Your idea of limiting bidders in the last 10 seconds to only those that have bid might help a little, but you could still have people doing last second bids among those who have been bidding.

    Another possible solution is to have the bidding time extend by 5 seconds every time someone bids. However, people could potentially bid forever. Maybe the following solution is the best:

    * After any bid the bidding time is set to 5 seconds if the time left is less than 5 seconds
    * After the normal bidding time you can only bid once.

    In other words, after bidding expires you only get to bid once. Every bid will refresh the timer to 5 seconds, giving you time to respond to a bid.

    What do you think of that idea?


    -Javek
    Posted in: General AddOns
  • 0

    posted a message on DKPmon & Bidder v2.0
    AceComm hasn't been updated for 23 days. Within my own guild I only remember having an AceComm incompatibility once...about 2 or 3 months ago. You need to make sure everyone gets their Bidder/DKPmon addons from the same source. I'm not sure when googlepages was last updated. Your best bet is to have everyone get the newest snapshot from WowAce, either through the "Beta Downloads" page or WAU. Also, if the person running DKPmon has an old AceComm version they'll probably cause errors for all the Bidder clients.

    If you still have people encountering errors after they've updated, have them load WoW with all of their addons disabled except Bidder and its modules. If there error goes away there's some kind of conflict with their other addons. (Probably they're Ace addons with old libraries) The easiest way to fix this is just to update all of their addons using WAU.
    Posted in: General AddOns
  • 0

    posted a message on DKPmon & Bidder v2.0
    I wonder what's different on the MAC platform that causes this. Maybe something to do with the file system? If it's not too much trouble, could you try installing all the Bidder modules and confirm that none of them work. Also, get BugSack and paste the full stack traces from your error(s).
    Posted in: General AddOns
  • 0

    posted a message on WowAce releases. WAU, Does trunk equal release?
    A few more thoughts that I forgot to address: Transitioning to a tags system will take a little while. Untagged addons will have to default to trunk and show the beta warning. One benefit of tagged releases is that it should reduce bandwidth usage substantially. Users will be downloading addon source code less frequently since they won't be following trunk. However, it may actually drive more users to the site as they will see WowAce as the source for the most recent stable releases.


    -Javek
    Posted in: General Chat
  • 0

    posted a message on WowAce releases. WAU, Does trunk equal release?
    So here's the two main issues I've gathered from this:

    1. End users should be aware that WowAce addons are considered beta quality
    • The link to files.wowace is "Beta downloads", which should alert users
    • WAU doesn't really make this clear, the recommendation to display a warning seems like a good one.

    2. Many users treat trunk as fairly stable and look at WowAce as a release site
    • Do we want WowAce to be a release site? Do we have the bandwidth?
    • Should we modify WAU and files.wowace to better handle versioning?
    • If WowAce is not a release site, than authors need to upload to curse/wowinterface more frequently.
    • Is alpha quality code in /trunk unacceptable? Should a policy on branching be made?

    I think the most important point here is that we can't claim beta status and tell users to "use at your own risk" and at the same time not supply users with a way of finding stable releases of WowAce addons.

    So here are my thoughts on solutions. Uploading to curse/wowinterface isn't that much of a pain, but some developers make frequent releases and the work involved does add up. If we want WowAce to take on the role of a stable release site we should do the following:

    Authors should tag their releases in /tags, e.g.
    /tags/PitBull/1.0
    /tags/PitBull/1.1

    WAU and files.wowace should be modified to link users to the highest version in tags rather than trunk. The users should also have the ability to choose among releases within these interfaces. For example, in WAU, I should be able to right-click an addon, select "Revert to", and have a menu of all the tagged versions of that addon. Maybe also have the option to type in a subversion release number. The same should go for files.wowace: by default addon download links should provide the latest tagged version. Next to this link should be a link to "Other releases". This link would give you a listing of all the tags and also let you choose to download from trunk. Users who select to download from trunk should be shown a warning about the beta quality of trunk.

    Now I realize this is a lot of extra work for the authors of those two systems depending on how much functionality you want. At a minimum you could just implement the download the highest tag logic and direct users to subversion documentation if they want to download another release or trunk. However, in WAU's case I think it should be fairly easy to add the "revert to" feature as it's integrated with a real svn client. The hard part is probably tracking what addons the user has reverted and representing that status to the user and providing the option to "unrevert" addons.

    If these modifications aren't made to WowAce's release systems then authors need to be encouraged to make more frequent releases to curse and wowinterface. I'd like to hear from the authors. Would you rather tag your addon with X.Y and be done, or upload to curse and wowinterface. What do the WAU and files.wowace authors think about these modifications to their systems?


    -Javek
    Posted in: General Chat
  • 0

    posted a message on WowAce releases. WAU, Does trunk equal release?
    I was reading through the latest posts in the TinyTip thread and found a lot of frustrated users and developers. Basically, the author made some major rewrites to TinyTip and committed the code to TinyTip trunk. Many of the users considered the new code a "downgrade" or "broken". There seems to be a lot of confusion on what the quality of code in trunk should be. Is it BETA, ALPHA, Release quality? Traditional developers claim that trunk is beta. You develop in trunk, then tag releases and upload them to curse, wowinterface, or wherever. However, as a few people pointed out, the reality of WowAce's download system and WAU is that users treat trunk as release quality or at least expect it to work and rarely break.

    Anyhow, there needs to be a decision made here. Either make it clear that trunk should be semi-stable and large code changes should happen in branches or change the download section and WAU to use tags and warn the user when they choose to download from trunk.

    In either case some documentation needs to be written setting the policy and describing how to correctly develop within the system. In the first case: How to create a branch and merge on to another branch. In the second: how to tag your branch. If the consensus is to adopt the 2nd system, WAU and the download page need to be taught to read tags and a standard tag format needs to be adopted, e.g. /tags/TinyTip-2.0

    I apologize if this discussion already happened but I missed it. What do some of the senior WowAce guys think? I'd be willing to write some of the wiki svn documentation once a decision is made if no one else wants to.


    -Javek
    Posted in: General Chat
  • 0

    posted a message on DKPmon & Bidder v2.0
    Every so often there are changes to AceComm or other libraries that cause incompatibilities between the DKPmon user and the Bidder client. I would just have everyone update from WowAce to make sure they have the latest version.

    I thought libs were versioned to prevent this, but it may be that another addon is loading its embedded version of AceComm, which is out of date.

    Anyway, just go to http://files.wowace.com/
    Everyone should download Bidder and Bidder_ZSumAuction
    Your dkp managers need DKPmon and DKPmon_ZSumAuction in addition

    If you're still getting the errors disable all your addons except for DKPmon/Bidder and see if the errors still occur.
    Posted in: General AddOns
  • 0

    posted a message on DKPmon & Bidder v2.0
    Are you sure you have Bidder_ZSumAuction installed as well as Bidder?
    Posted in: General AddOns
  • 0

    posted a message on DKPmon & Bidder v2.0
    Maybe you could use the checksum in conjunction with a last modified time. The chances that the two leaders would have the same checksum and modified time would be next to nothing.

    So to continue with the Kara example. Say leaders of the two raids (Kara1 & Kara2) just finished their respective runs on 2/18 and Bob is another raid leader. The last item deduction or point award was at 10:03pm for Kara1 and 10:11pm for Kara2. The sync display would look like this:

    Name | Last Change | Status
    Kara1 | 2/18 10:03pm | Modified Database
    Kara2 | 2/18 10:11pm | Modified Database
    Bob | 2/17 10:22pm | Out of sync


    Kara1 broadcasts first. Everyone gets the dkp info from the first kara raid, but the sync check fails because the checksum and/or the last change is different. Now the display looks like this. Notice Bob's last change and Kara1's are the same.

    Name | Last Change | Status
    Kara1 | 2/18 10:03pm | Out of sync
    Kara2 | 2/18 10:11pm | Modified Database
    Bob | 2/18 10:03pm | Out of sync


    Kara2 now broadcasts and everyone is in sync:

    Name | Last Change | Status
    Kara1 | 2/18 10:11pm | Synchronized
    Kara2 | 2/18 10:11pm | Synchronized
    Bob | 2/18 10:11pm | Synchronized


    Logic for the Status message:
    Synchronized: If you have the same last change time and checksum of the person with the most recent change.

    Modified Database: If you have made changes to your database since you last sync'd or broadcasted

    Out of sync: If you don't match the checksum and last change time of the most recent change.

    I'm not sure if you have a modifiedDB variable or not. I think the following would work:
    • When you broadcast set modifiedDB to false
    • When you receive a broadcast set modifiedDB to false only if your checksum and last change time match after you finish receiving (Prevents Kara2 from forgetting they have modifications when Kara1 first broadcasts)
    • Whenever you award points/items set modifiedDB to true

    What do you guys think? Would this work, should some of the language be changed? I probably won't work on this until my dkp web application is done, but it's something I'd like to add to DKPmon.


    -Javek
    Posted in: General AddOns
  • 0

    posted a message on DKPmon & Bidder v2.0
    Couldn't you just do a "need to sync" check using one player entry. For example: Every client would reply to a sync check with the player in their DB with the newest timestamp, resolving ties by ordering alphanumerically and picking the first. If you don't match the player and timestamp then you're out of sync.

    Is broadcasting a two way process? For example, in the kara example, does just one leader need to broadcast or does each kara leader need to broadcast in turn?

    If both need to broadcast, then this method will falsely indicate that they are synchronized after the first sync.


    -Javek
    Posted in: General AddOns
  • 0

    posted a message on DKPmon & Bidder v2.0
    I really think the sync operation deserves it's own UI. Maybe I'll work on it at some point. I'm hoping the Ace3 GUI stuff will have a generic Table/Grid widget that could be used. Anyhow, I was thinking of something along the lines of this:



    Sync
    Name
    DB Timestamp
    Status


    [Sync]
    Bob
    2-16-08 10:05 pm
    Synchronized


    [Sync]
    Joe
    2-12-08 9:30 pm
    Bad Password


    [Sync]
    Jane
    2-13-08 9:30 pm
    Out of date


    [Broadcast Database]

    This would allow you to see who has the wrong password and their last sync time at a glance. Clicking the sync button would be the same as the current "Initiate Sync" feature, except it would only update from that person you clicked. Broadcast would do the same.

    In the Status column I'd like to have the following messages:

    At first the status column shows "Bad Password" if they have the wrong password, otherwise "Out of date" or "Synchronized"
    When you sync from the person it would change to "Broadcasting" for the row of the person broadcasting.
    When you broadcast, everyone's status would chance to "Deciding" indicating their "Do you want to sync" dialog is up.
    If they click "No" it changes to "Rejected"
    If they click "Yes" it chances to "Receiving" and then "Synchronized"

    The timestamps would then update again after the sync. Also, if they're already synchronized they shouldn't get the dialog at all and nothing should happen.

    Eraslin, what do you think of this layout? Would you do anything differently or add other features I missed? We could get fancy and do a progress bar, but the sync operation is fairly quick.


    -Javek
    Posted in: General AddOns
  • 0

    posted a message on DKPmon & Bidder v2.0
    Quote from Eraslin »

    I'll probably change this back at some point soonish. The reason for DKPmon to save the amLeader state was for when you do a /console reloadui mid-raid to save your points database to disk. Saving that state prevents leader flips that would be caused by losing memory of being the "leader" when your UI is reloading.

    -Eraslin


    Maybe while you're at it you could make DKPmon choose the leader more intelligently. For example, choosing the person with the newest dkp database timestamp.

    What happens to the Bidder clients when the dkp leader reloads UI? Do they search for a new leader somehow or just wait until a leader sends them something again?

    When you reload UI you have to assume any amount of time could have passed. So maybe when first loading DKPmon could do something like this:

    1. If in raid, broadcast: "Who's the leader?"
    2. Other DKPmons reply with who they think the leader is; if they don't have one determine the best leader again.
    The person who just reloaded should have the newest dkp database timestamp and be chosen.

    I had another idea but I'm not sure how difficult it would be to implement. What if every time you award/deduct points it broadcasts the change to the other DKPmon clients. They simultaneously make the same changes to their database if they are in sync with you. This would allow anyone to step in where you left off if you crashed or something. However, module state settings might be difficult to transfer, however this isn't that big a deal. For example, BossAuction has a timer going, but the new dkp leader could just start a new timer. The important thing is that the DKP wasn't lost. It'd be nice to sync the log as well, but again I'm not sure how difficult this would be.


    -Javek
    Posted in: General AddOns
  • To post a comment, please or register a new account.