Konfer (Suicide Kings Edition) implements the Suicide Kings loot distribution system. This mod is under active development so comments, good or bad, are welcome. I especially want to hear from you if you find any problems so that I can fix them ASAP. The official home for KSK is http://kahluamod.com/ksk. Also if you are able to translate KonferSK into other languages I would love to hear from you.
== Features ==
Supports multiple configurations, including guild configs and PUG configs. Each configuration is completely discrete.
Quick and easy user and list management
Simple, compact user interface
Robust synchronization between administrators
Item editor that allows you to auto-assign items to users or set default loot priorities
User-only mode for non-administrators so they can see their list positions and watch looting take place
Auto-assignment of loot when a bid is won
Auto-assign loot to defined enchanters if no users bid on an item
Supports open rolls that do not suicide users on lists
Open roll system supports alt-spec rolls (/roll 101-200)
Import of existing SKG and Suicide Kings users and lists
Import users by guild rank or from a CSV list
Export to CSV or XML formats
Announces winners in guild or raid chat
Supports silent bidding (highest bidder not announced)
Filters out all mod-related messages for master looter so chat isn't cluttered
Will support automatic list position decay (in a few weeks)
Allows master looter to force bids and retractions
Automatically assigns BOE items that are not bid on to the master looter
Automatically supports class restrictions if an item is class specific
Guild rank based filtering (allow only raiders and above to roll, then members and above etc)
Allows you to define user "roles" such as tank, healer, spellcaster etc, and filter based on that role
== First Time Usage ==
To start using KonferSK you must first create a "configuration". KonferSK supports any number of configurations, each of which can be thought of as a completely different installation of KonferSK. They share no data whatsoever. To create a configuration type:
/ksk createconfig "Configuration Name"
Since this is your first configuration, it will also be the default. You can now use "/ksk" to access the main window. You can also type "/ksk config admin" to get to the configuration admin panel.
The first thing you need to decide is whether or not this is a guild or a PUG configuration. Guild configurations broadcast all of their information to the guild, and PUG configurations only to an active raid. Usually only the guild leader or an officer will create a guild configuration. You should then decide whether or not alts are "tethered". If alts are tethered, it means that only 1 entry will appear in any roll lists for a user. All of that user's defined alts will appear underneath that main user, and they all move on the lists as a group. Thus, no matter which toon they are playing, if they move on a list all of their toons move together. If you want each toon to be its own entity and move independently of each other, turn alt tethering off.
Once the configuration has been created, press the "Users" tab at the bottom or type "/ksk users". This will display the user editor. You can then either create each user by hand, import guild users by rank, or import an existing SKG players list if you were using SKG. When adding users you can assign each user a specific "role". The possible values for the role are "Healer", "Spellcaster", "Melee DPS", "Ranged DPS" and "Tank". It is possible to filter out bids based on which role a user has. If you don't care to do role filtering, leave this as "Not Set" (or you can define the roles for keeping track of who does what and simply not use role filters).
Once you have users defined, you should press the "Lists" button at the bottom or type "/ksk lists". This will show you the currently defined lists and the members on each list, in their correct order. Currently this will be empty. Press the "Config" tab at the top to display the list configuration window. At the bottom right are buttons you can use to create, delete, rename lists etc, or import users into the lists by rank or from an existing SKG roll list if you have SKG installed. Once a list has been created, you can change its sort order if you do not want lists to simply be sorted alphabetically (for example, you want the raiders list displayed before the members list). Lists with the lowest numbered sort order will be displayed first, and lists with the same sort order will be sorted alphabetically. If you do not import users from the guild roster or SKG, press the "Members" tab at the top, select the list you want to add users to, and press the "Insert" button to insert users into the list.
== Commands ==
/ksk or /ksk lists - opens the main window, which is the loot members list
/ksk loot - opens the loot assignment window
/ksk items - opens the item editor
/ksk history - opens the loot assignment history window
/ksk additem itemlink - adds the specified
item to the item editor. You need to shift-click an item link from elsewhere to get the correct item link.
/ksk addloot itemlink - adds the specified item to the loot list (for manually adding loot items)
/ksk users - opens the user editor
/ksk sync - opens the sync manager
/ksk config - opens the loot assignment options window
/ksk help - shows all other commands you can use
== Loot Assignment ==
There are things you can do to make your life easier when it comes time to distribute loot. First, if you have multiple lists that people roll on and you usually start with one particular list, set the default roll list in the loot configuration window (/ksk config). Second, if this is a guild configuration and your ranks are sanely assigned and you use rank filtering, set the default rank you want to start bidding with in each list's configuration. Third, correctly mark those users that are enchanters in the user editor.
When a user has been marked as an enchanter in the user editor, you can select them in the loot assignment options to receive loot that is not bid on. You can set up to 6 enchanters here. Whichever of these enchanters is in raid will be awarded any item that is not bid or rolled on (they will **not** be suicided).
By default "Auto assign loot when bids close" is enabled. What this means is that when users have bid on an item and a winner has been determined (or users have rolled, or no users have bid and a trusted enchanter is online), KSK will give you the option to automatically assign the item to the relevant user. You always have the option of canceling this auto-assignment, but if you accept, the item is immediately awarded to the user, there is no need to select the item in the standard Blizzard loot frame. In fact if you auto-assign the loot, it will be removed from the Blizzard frame.
Sometimes you may want a specific user to receive a specific item, either because they are collecting a set or because you made a loot mistake or correction and want to ensure that a user receives an item the next time it drops. To do this, add the item with /ksk additem, and in the item editor (/ksk items) select "Assign Next Drop to user", and then press the "Select" button to select the user that will receive the item. You can optionally cause this auto-assignment to suicide the user on a given list, and if this is to be a once-off auto-assignment, select "Auto remove when assigned". If you want the user to receive all drops of the item leave that option unchecked. A good use of this option is for items like the shards for the legendary mace out of Ulduar, you can use this to always assign them to the same healer until they have all 30 shards.
When you add an item to the item list you can also select a specific list to roll on for the item (for example, force Tier items to be rolled for on a Tier list). You can also set custom class restrictions, although the defaults are based on the item type, armor type, or any intrinsic class restrictions.
Each time you click on a lootable item (the top right hand window in the loot panel) it will set whichever list is appropriate as the default (either the global default list or a list specifically set for that item in the item editor). It will also set the initial class filters and guild rank, if you have set any of those values for the roll lists or for the item. You can change the list and filters as you see fit, and then press either "Open Bids" or "Open Roll". Opening bids will allow users to whisper you the word "bid" to bid on an item or "retract" to retract their bid. If they are also using KonferSK, they will see the same window you do and will be able to press the Bid or Retract buttons.
You can change the bid list while bidding is active to move from one list to another, and you can change various filters such as the guild rank filter to allow more and more users to bid. For my own guild, we always start bidding for "raiders", and then if none bid change the guild rank filter to "members", then "initiates" etc. There is a little red "-" next to the guild rank filter that will automatically move down one guild rank to make life easier for rank based filtering.
As the master looter you can select a member from the members list (bottom left panel) and press "Force Bid" to force that user to bid, or select a person who has already rolled and press "Force Retract" to force a retraction. When bid time is over, press "Close Bids" and if there was a winner, it will suicide the user on the list they bid on, and optionally automatically assign the item to them. If no users bid and there are enchanters online (and the option is enabled) it will assign the item to an enchanter to be disenchanted. If the item is a BoE item and the option is set (it is by default) it will assign the item to the master looter instead of an enchanter.
If you want users to be able to roll for an item and not be suicided, you can press "Open Roll" instead of "Open Bids". This starts a 10-second roll-off. Only the 5 highest rollers are shown. If a user types /roll within the last 5 seconds of the countdown, the timer will be automatically extended back to to 5 seconds. KSK supports the notion of "rolling for alts". Normal users who want the item for their main spec can use /roll as per normal. If a user is rolling for an alt, they can use /roll 101-200 to indicate they are rolling for an alt. KSK automatically recognizes that a main spec roll of 89 is higher than an alt-spec roll of 190. If a user rolled incorrectly (they typed just /roll instead of /roll 101-200 for an off-spec item), they can re-roll. However, they do not actually get another shot at rolling a higher number. Their original number is preserved. For example, if a user typed /roll and rolled 65, but realized they should have rolled for off-spec and type /roll 101-200, KSK will adjust their original roll and pretend they had rolled 165 initially, even if their new roll was 199. You can manually pause and resume the roll countdown timer by pressing "Pause" and "Resume".
Originally posted by Zanthor The list is picked automatically by the default list or by item. I've also seen this happen if I change lists and quickly hit the Open Bid button.
When a player bids it announced "Bob bid on item at position X" or some such, I don't know the exact verbage... so say on the list thats selected Bob's at position 1, but on the previously selectetd list Bob's in position 25... when this bug occurs it announced Bob's bidding from position 25 when the auctions on the list he should be in 1st place. Stopping and restarting the auction fixes this.
I have taken a very long hard look at this, and my only suggestion is "slow down a bit and look at the screen". When lists change, it needs to send out an event indicating that so that other users who are running the mod will have their bid list changed. That message takes time to travel, especially if users are lagged etc. At every possible place where the bid list is changed, it immediately updates the bid members list, so there is no race condition. However, if you changed the list and a user pressed their "Bid" button in the bidding UI, but their mod had not yet received the "change list" notification, it will in fact send an internal bid message with their list position on the list they currently have selected. That is the only possible way I can see the numbers getting out of sync. So the users just need to make sure that the correct list is selected when they press the Bid button.
Having said all of that, I am looking into the possibility of ignoring the bid list position that was sent with the bid request and recalculating it at the point of display, which could conceivably fix even that problem. But in the mean time, just remember that things take time to travel down the wires and slow down a tad.
Originally posted by Cruciformer "the bid list report from a different list" - reported by what?
How is the list originally selected? By you manually selecting it or automatically becuase of a config default or item setting?
The list is picked automatically by the default list or by item. I've also seen this happen if I change lists and quickly hit the Open Bid button.
When a player bids it announced "Bob bid on item at position X" or some such, I don't know the exact verbage... so say on the list thats selected Bob's at position 1, but on the previously selectetd list Bob's in position 25... when this bug occurs it announced Bob's bidding from position 25 when the auctions on the list he should be in 1st place. Stopping and restarting the auction fixes this.
Originally posted by Zanthor Bug Report: Sometimes when running a bid the list positions report from a different list. For example bidding on an epic item with the epic list shown on the UI shows playerX in 5th place, but when he bids it announces he's in 30th place (which he is, on the Tier list)...
I can fix this by changing lists and then back or canceling the bid and reopening.
This is an issue I've had happen several times now but have never been able to replicate an exact cause or even make happen on demand... I'd wager some form of race condition.
"the bid list report from a different list" - reported by what?
How is the list originally selected? By you manually selecting it or automatically becuase of a config default or item setting?
Bug Report: Sometimes when running a bid the list positions report from a different list. For example bidding on an epic item with the epic list shown on the UI shows playerX in 5th place, but when he bids it announces he's in 30th place (which he is, on the Tier list)...
I can fix this by changing lists and then back or canceling the bid and reopening.
This is an issue I've had happen several times now but have never been able to replicate an exact cause or even make happen on demand... I'd wager some form of race condition.
Originally posted by Cruciformer I cant do what you want. The auto-assigning of loot is optional, closing a bid isn't. That is the only safe place to put the suicide. If your raiders can't make their minds up, leave the bid open a little longer. Confirm with them on vent etc. Sounds like a little communication would solve the problem. They could just as easily change their mind after you press OK too you know
However this has often been requested and I will certainly see what I can come up with to add a proper undo.
I'd appreciate a proper undo at the least... we do communicate, a lot. It never fails though that every week or two this issue comes up, stops raid for 5 minutes while I fix it, etc...
The main issue for me is the guilds culture doesn't allow being a hardass about this. I'd quite happily live by the rule of if a winner changes their mind the loot moves to the next person in line, they get suicided, etc... and the first winner stays suicided. I'd get voted off the island in no time though.
Originally posted by Zanthor Simply moving them back to the previous position doesn't put everyone else back where they belong and is unfair to those who aren't on that raid. The method that I've used is very similar but actually puts everyone back exactly where they belonged before the mishap...
I scroll back up and find what position they were in as well. I then suicide the player in that position until the list is back in it's previous state.
While you can't suicide on receipt of the loot you could suicide on the click of the "OK" button instead of the "Close Bid" button... The dialog where it asks if you really want to give player X item Y... if it suicides at that point you've already had your moments reprieve... Would solve the issue I've run into most often which is players reevaluating right after I click close.
I cant do what you want. The auto-assigning of loot is optional, closing a bid isn't. That is the only safe place to put the suicide. If your raiders can't make their minds up, leave the bid open a little longer. Confirm with them on vent etc. Sounds like a little communication would solve the problem. They could just as easily change their mind after you press OK too you know
However this has often been requested and I will certainly see what I can come up with to add a proper undo.
Simply moving them back to the previous position doesn't put everyone else back where they belong and is unfair to those who aren't on that raid. The method that I've used is very similar but actually puts everyone back exactly where they belonged before the mishap...
I scroll back up and find what position they were in as well. I then suicide the player in that position until the list is back in it's previous state.
While you can't suicide on receipt of the loot you could suicide on the click of the "OK" button instead of the "Close Bid" button... The dialog where it asks if you really want to give player X item Y... if it suicides at that point you've already had your moments reprieve... Would solve the issue I've run into most often which is players reevaluating right after I click close.
Originally posted by Zanthor I'd like to suggest making the Suicide action actually happen when loot is awarded not when the auction ends... (Or putting a single-transaction rollback in place)
I've run into the situation where a player has the item and can't be awarded it, or didn't get permission to receive the loot, and have had to do major monkey business to get the list back straight!
Can not do it on loot receipt because you do not always get the message that someone has received loot. For example if they have changed to a different wing in Naxx or taken a portal to a different part of Ulduar and are out of range, they can still get the loot but you wont receive any message letting you know they have. Its been a thorn in my side that there is not an official event I can trap that tells me when loot is awarded in a raid.
I go to considerable trouble to make sure that only the correct user can receive loot. It filters out inappropriate classes, ensures that the user was actual present for the boss kill etc. As for implementing a rollback, it is quite complicated due to the way in which sync events are managed. In the rare cases where we had to "undo" a suicide it was a simple matter of scrolling up in the chat log to see what position the user was in before the roll happened, and to manually move the user back up to that position. Its a few button clicks and doesn't complicate the data model. I dont understand why it takes any "monkey business" to just move them up. If they were near the top you can "King" them (move them to the extreme top of the list) and then move them down to their previous place, or if they were near the bottom just click move up a few times. Is that not acceptable?
I've thought about having an undo for quite a while and it really is much nastier than you think but if manually moving them is somehow too taxing I can re-visit the idea and see if I can't find a workable solution for it.
I'd like to suggest making the Suicide action actually happen when loot is awarded not when the auction ends... (Or putting a single-transaction rollback in place)
I've run into the situation where a player has the item and can't be awarded it, or didn't get permission to receive the loot, and have had to do major monkey business to get the list back straight!
I have updated the admin guide (http://kahluamod.com/ksk/admins.html) to discuss the various new options that have been added since the guide as first written, as well as added a brief section on XML exports.
Originally posted by Cruciformer To be honest I am a bit in two minds about decay....
Thanks for the update about decay, I know it isn't easy it just sounded so nice. People seem to get upset when they get demoted from the "raider" level but maybe it is because we don't do it very often, but I do agree rank based is probably a better overall solution.
Decaying seems to be a good solution for a problem we see often, a raider takes a break for a month or two and then comes back full time. I guess we could leave them them at the demoted level for a while once they return, we just need to get by the social issues of "why am I not at the raider rank".
