We have shifted development of the Guildomatic WoW in-game module to an open source publicly visible source code repository.

The code is hosted at GitHub. We welcome code comments, contributions, and input from you all.

The official code repository is at:

http://github.com/shaper/gmatic-wow

This is part of our long-talked-about plan to involve our community further in helping to make things better, both for yourselves and for others.

We want to be transparent and incorporate your ideas, features and feedback as much as possible. We know others have developed their own mods, in many cases even better than ours in various ways. We want to learn from that and evolve our own module to incorporate more goodness from you all, and are hoping this approach will make that easier.

This is a new step for us, so we surely have much to work out yet regarding communication and details, but everything starts somewhere.

Feel free to fork the code on GitHub, make any changes you like, send them to us for review, etc.

To provide some background on how we have been doing development, and how to fetch, review, and work with the code, though of course you are free to do as you wish yourselves:

• we do the bulk of our development in Ruby, hence there is a Rakefile which helps in building the distribution archive, and the CHANGELOG is written in RDoc format.
• you will need to use git if you want to actually use the same source-code management tools we use, for committing changes, fetching updates ongoing, etc. GitHub also provides access to the code as a zip and tarball but sending us patches will pretty much require git for it to be an easy and workable process for everyone involved.
• GitHub is free and easy to join and has some great tutorial and help documentation on their web site, be sure to check it out.
• The GitHub Help page has links off to various useful tutorials and FAQs.
• The Forking a project page will be one of the first things that will help you out in creating your own copy and working with it to commit changes to your own local tree. Essentially if you want to contribute any changes or review proposals with us easily, you'll likely want to (1) fork our repo, (2) commit your changes to your local fork, (3) contact us or send a pull request or what have you, to review your changes. It is easier than it sounds once you've been through it a couple of times, or so I hear.
• We are at best dirty hackers in LUA, and have surely done many things awkwardly or non-optimally. Our main focus has always been to make the most common things our users need to do fast and easy, while making less common and complicated things still possible, and hopefully making even those easy over time. We are very much open to dramatic revisions or alternate approaches.
• We still have a long list of planned, not-yet-completed enhancements to the module. A dated version is summarized at the bottom of this post.
• Core discussion on module features to date has been happening here.
• Among the biggest burning open issues is the mod's failure to record those bosses that, when killed, don't actually die. We know what we probably need to do (watch for a different incoming message event re: the monster becoming friendly, or perhaps a specific thing they say), but haven't had a chance to incorporate that in an appropriate manner for each of the involved bosses.

Thank you for using Guildomatic, and again, we welcome feedback as we take this first step with all of you.

>Among the biggest burning open issues is the mod's failure to record those bosses that, when killed, don't actually die

one way to get round this would be to use deadly boss mods. for example we use EPGP and EPGP uses DBM to know when a boss has been downed to award dkp.

so in similar principle dont try to build it into your addon but simply use this feature which is present in DBM to help your addon know when a boss has been downed. almost every raiding guild uses DBM so it might not be a big issue to simply have then d/l and install DBM as any guild should already have.

another idea...DBM has a bidbot, perhaps theres a way to tie in your dkp addon to track bidbot as it uses the +1 scheme which is very popular.
I encourage developers to take a look at DBM's bidbot because its exactly how i need guildomatic dkp to work..
you start it with !bid (link item)
then the auction begins...
if 2 ppl bid, say one 100 and another person 50, at end of auction a box pops up for lootmaster to confirm price which is 51 dkp

the dliemma is i can't upload this to our website...but if guildomatic could somehow read this info to upload, it solves the problem.

in other words there are other addons out there that do exactly what guildomatic dkp needs to do...so by looking how DBM does it or somehow using the info to upload to your site would be helpful

perhaps theres a way to upload a csv file, xml or something. let DBM collect the bids and winnings for the raid then upload that data as the snapshot.

the mroe and mroe i look at deadly boss mods Raid tools the more I realize its exactly what guilodomcatic DKP needs to function as.

I urge if you have not, look at it and i think you'll see its whats exactly needed and if you can find a way to parse the bid history and so forth to upload to the site, you really dont have to put tha tmuch effort into writing a whole new guildomatic dkp



just throwing my ideas out there

This is great news! I hope to see some interesting forks from people. I'd love to contribute but I just don't know if I'll have the time.

one of the big drawbacks to gdkp (guildomatic dkp) is it can not track spent and or lefet over dkp for players
Player A has 500 DKP total to his name before start of the raid
example. player A bids 500 dkp on a trophy which drops in TOC
3 ppl bid, player A bids 500
Playber B bids 300
and player C bids 250

Player A wins with a 300 bid but in fact only pays 301
we use the +1 win system ( next highest bidder) hence +1 so he does not pay his full price. me the lootmaster I have to whisper him "you paid 301 dkp for said item) this way he can do some math and deduct 301 from 500 so he knows how much left over dkp he has because gdkp can't do that.

now we move onto next boss
player A bids 250
player B bids 240
player c bids 220

Player A wins with 250 but paid only 241 dkp for item


i hope you can see the dilemma, player A is now bidding with DKP he does not have, he has gone over. this is where the loot master has to track spent dkp for each player in the raid..

it would be nice if the GDKP could track actual paid DKP and subtract that from the starting dkp he had at beginning of the night, this could be accomplished easily by reading player A name fromt he Static file which I update daily before each raid.

the idea being, is when ppl bid for items the GDKP is keeping track in realtime what they have bid--then paid for item using +1 bid system, and after auction has been won....a box would appear for lootmaster to confirm the final price which should be +1, after lootmaster confirms it whispers the winner how much the bid on item and what their paid cost is and how much DKP they actually have left to bid with now.

in essence deadly Boss mods does this...the +1 and the confirmation box but i dont think it tracks or tells them how much dkp they have left, GDKP has a big advantage because it can draw info from the static file.

but the principle DBM has in place is exactly what needs to be added to GDKP

once again I urge developers to take a look at the DBM raid tools to get a better understanding as yall could draw upon this already build mod to draw ideas from.

If possible, please incorporate BigWigs

Also, the GUI for this is capturing 5 mans