Making SK more WM friendly...

[apollor]

It's amazing what you can discover about a guildy if you dare to probe into the depths of their souls ;-) Or, at least chat to them for 5 mins

There are a couple of programmers out there in War Machine, that have tinkered with LUA coding (the code base behind in-game mods) and they have suggested that they may be able to improve some of our favorite mods to make them more friendly.

I'm certainly keen to see what might come of this. At worst we scrap it and just plug on with our current mods, but there's a chance we'll get something awesome.

There is no cost for awesomeness!

So with that in mind, I promised I would start a thread to capture the thoughts and ideas of what could be fixed in some of the mods we use. And if it's within the constraintsof the programming API's and the minds of our WM-programmers we might be able to do something.

Okay - First of all, Baby-Steps! Lets choose one mod and try and work with that. Focus is very handy on these things, too much dispersion of effort and we could end up frustrated and getting nowhere.

I'd like to see if we can take a stab at Suicide Kings mod first. As there are a few, hopefully simple changes that would really make a big difference in making this mod much more friendly.

Here's some of the short fallings of the SK mod as I see it. Hopefully this list can simply feed into a list of changes that improve it a bit at a time.

• No time stamp visible for the list - there is no way to tell "when" you received that list.
  - This means it's very hard to tell quickly "who" has the latest list.
  - There is also no timestamp data on each toon's name, so you can't tell when a toon was last "inserted/moved/suicided" this would make any manual changes easier.
  
  
• the SK Master appears to be within a party or raid group - instead of "across the SK mod runners"
  - We currently run without using the "private data channel" config option selected. I think this is worthy of testing, because I have a feeling it will change the mod's behavior. And perhaps in our favor.
  - In non-private data channel mode, I assume that it is using the Party/Raid channel (or a dynamically named side-channel) to do update conversations. Because of this it divides SK-mod runners when they are in separate raids or parties.
  - I think that if we enable the private data channel and use that, it will mean that all the SK mod runners in WM will always sit in the same data channel. i.e. we're always connected to each other. despite the raid group we're in. And there is a chance that this will mean that when someone /sk master's they will be across ALL SK mod runners, and this may mean raid group updates will be realtime combined updates - How awesome is that if it works?
  - If it did work, all that has to happen when twin raids are run, is the loot-master of each raid /sk master's up as they do loot. Thus flipping it back and forward. And everyone else sitting in channel stays up to date all the time. Well worth testing yes?
  
  
• Display is crowded and disorganised, lack of hover-helpers.
  - Buttons need renaming to be more intuitive.
  - Insert button, when clicked without a target selected should simply popup a standard text input box to take the name you want as input. So you can shift-click a chat/guild chat name link and have it work etc.
  - There should be a way to "filter" the view when running in a raid. So that when I want to quickly scan the list of currently active toons I can filter out all the grey un-highlighted names from the view.
  - The bidding system is nice in that it will look to the loot list you've "selected" for opening bidding on for who is "winning" the bid. However, there is no feedback to the raid other than "person X is winning". The openness of /roll'ing means that everyone can see who is participating in the roll, or at least who is interested in the piece. This may prompt someone to give up their winning position in favor of passing to someone else. The simple fix for this is to have names announced in raid-chat as 'every' bid is placed or retracted.
  - Unsure on the behavior of bidding if someone not on the list bid's. i.e. a PuG'er. It would be annoying to have to ask guild members to /roll first to win the decider on wether it's PuG or Guild loot, and then have to "/t loot-master bid" to bid for the item. Having a single command of just bidding would be best I think.
  
  
• Auto-syncs when someone /sk masters doesn't provide any details on the list that the person is attempting to send out.
  - If time stamp data was recorded, this info could be provided so that you can see quickly "XXX is sending version 2009-02-11-231451, you currently have 2009-02-11-220911. Okay to accept?"
  
  
• There is no raider-SK-lite mod
  - For all our raiders, a really simple little mod that monitors raid-chat for "Bid on item..." messages and so forth would be very cool.
  - When an item is opened for bidding, you mod pop's up and presents you with the top 10 current list of players in the loot list relevant to the roll. And offers you a "Bid" and "Retract" button which you can use on an item. This of course auto sends the 'bid' 'retract' whispers to the loot-master.
  - Once the bid is closed, the mod would notice the "bidding closed on ..." message and close for the next bid.
  

These are just a few of the things I've thought about that would make the mod a little nicer from my perspective. If anyone has any ideas... send me a message on the forums and I can add them in. Or just post follow ups etc.

I don't think most of the things I've suggested are that hard to change. And since we could just build on and improve an existing mod most of the hard work is already done. To core functionality of the list workings is fine.

[Dansus]

Sounds good, I'd really like to see that horrible calendar fixed. Especially its annoying bug where it'll change your status to "Yes I'll attend". I might even have a go at learning lua .

Regarding SK, a raider view mod would be handy. Or improving the /w method finding your position on the list.

[kimbeli]

When I get a bit of free time, I'll poke through the LUA source, and see what I can come up with. I think some of those changes would be easy - others might require a little more work. Of course, i'm not the best lua programmer, so whatever I can't implement (or do efficently), we can see what others can come up with. i'll have a go at the simplest ideas first - time stamps, syncing with dates, etc.

It's always hard to modify someone else's code without familiarising yourself with it, so it might take a bit, but we can make this work!

[Apiecost]

I'd say between us we can make it work the way we want, but one concern is that we'd be effectively forking the code off which may lead us to issues if the maintainer of the mod does something exceptional in a future release. e.g., we'd be left in the position of having to roll our changes into the major public releases occasionally, or having to try and roll the major release changes into our version. I can't see anyone being able to do this long term, especially if parts of the API break the mod between patches... that's a big burden to carry.

Maybe we can take the approach of submitting code to the maintainer and having the functionality then available for everyone?

Dare I stir the pot and ask that we consider a web-based solution? We than have tremendous freedom in terms of UI and maintaining a "single source of truth" for all loot items. Think of the functionality we'd have by being able to show a history of who got what loot and to being able to integrate wowhead popups on items. I mean, as long as somebody has dual screens or can tab to the UI there's no reason why it couldn't dump down the current list after a change and then have a basic in-game mod that blatted it into raid. Perhaps something like this already exists.

[castus]

That's a good point Apie...

You could also provide a link from this website.

[gbsilk]

Or have it hosted here?

That would bring in the punters...

[apollor]

An externalized web solution does provide a single authoritative source of the list that is always up to date. But at the cost of in-game integration.

That last part should be considered because as it currently stands just having to stand there and deal with the rolling and distribution of loot is a p.i.t.a on the poor loot master. It detracts somewhat from the overall enjoyment of the raid a little in that you're left behind mopping up while everyone goes and blows stuff up.

So the big plus to having an in-game mod that ties into the interface means you spend less time type names in to add to list, alt-tabbing or duel-screening off to update loot etc etc. You can just click some buttons and be on your way.

I really think that we can solve the cross raid syncing issue. And perhaps from there, we could easily develop a little script to take the loot list file and post it to a webpage for easy visibility. Actually I'm betting that we can even automate the linking to wowhead item page links also with a bit of work....

-A

[thoragk]

Feb 20, 2009 13:34:58 GMT 10 Apiecost said:

I'd say between us we can make it work the way we want, but one concern is that we'd be effectively forking the code off which may lead us to issues if the maintainer of the mod does something exceptional in a future release. e.g., we'd be left in the position of having to roll our changes into the major public releases occasionally, or having to try and roll the major release changes into our version. I can't see anyone being able to do this long term, especially if parts of the API break the mod between patches... that's a big burden to carry.

Maybe we can take the approach of submitting code to the maintainer and having the functionality then available for everyone?

Extremely valid points. I'd suggest contacting the developer with enhancement suggestions, and see whether they are things already on the to-do list, or perhaps organise a collaborative arrangement.