• 0

    posted a message on ButtonFacade (was LibButtonSkin-1.0)
    Wow, I've actually gone through all 106 pages in this thread...

    Working on adding support to a mod and having some issues.

    I'm not using templates for my buttons (they aren't action buttons) and I can't get them to show the disabled texture when the button is set with :SetButtonState("DISABLED", true)

    Here's the most relevant code I can think to post:

    Creating the actual button and the optional textures for LBF:
    local indicator = CreateFrame("Button", name, RecycledFrame)
    if(LBF) then
    		indicator.icon = indicator:CreateTexture(nil, "BACKGROUND")
    		indicator.disabledicon = indicator:CreateTexture(nil, "BACKGROUND")

    Note that I've tried using different layers to no avail.

    Setting the textures:
    if(LBF) then
    		--NO LBF

    And finally, when it comes time to set the button data it looks like this:
    	if(LBF) then
    		indicator.btndata = {
    			Icon = indicator.icon,
    			Cooldown = false,
    			Pushed = false,
    			Flash = false,
    			Normal = nil,
    			Disabled = indicator.disabledicon,
    			Checked = false,
    			Border = false,
    			Highlight = false,
    			AutoCast = false,
    			AutoCastable = false,
    			HotKey = false,
    			Count = false,
    			Name = false,
    		local group = LBF:Group(LBFHermes.Name, MODNAME);
    		group:AddButton(indicator, indicator.btndata)

    Note that the sizing of the buttons is done elsewhere and I have to call group:ReSkin() but that part seems fine.

    Quote a few comments/questions here.
    1. Why is it that I must set Normal to nil? If I set it to false or an actual texture then things go to hell in a hand-basket. Note that I've tried SetNormalTexture on the button object and then leaving Normal set to nil and that causes the same problems.
    2. The interaction between the various layers just seems real finicky overall. There must be something I don't understand about the requirements of buttons.
    3. Why MUST I use Icon for the texture and not Normal? The ONLY way this is even close to working is by setting the texture to Icon.

    When I disable LBF (by setting it to nil) the addon works perfectly well. I just can't figure out how to use LBF to show the Disabled texture when the button state is disabled. Is this supported?
    Posted in: General AddOns
  • 0

    posted a message on AceConfig - tree groups inside tree groups?
    No solutions for you. Took me a minute to realize what you're asking for (then I noticed all the space to the right). I had this same problem and never found a solution unfortunately.

    For me, I ended up making the "Level 1" items tabs since there weren't very many of them, expanding room horizontally for everything else.
    Posted in: Ace3
  • 0

    posted a message on Does AceComm protect the receiving end too?
    As mentioned, I went ahead and created the addon despite the great wisdom here. If anyone is interested, here's the project page:


    It ended up being a little more trouble that I thought to keep the chatter down during initial communication. And I haven't had a chance to test it our in a real raid environment yet (only 3 users so far).

    I got to play with some new stuff though. Tried getting ButtonFacade support but after a couple of hours I gave up. I was having issues with how ButtonFacade appears to reparent frames or some such. I "sort of" had it working but yanked the code out after spending too long.
    Posted in: Libraries
  • 0

    posted a message on Does AceComm protect the receiving end too?
    Hmm yeah. It's disappointing to read and I'm trying not to get hung up on it :(

    I've seen the code required to try and track the "weird" spells and it's complex, requires heavy combat log monitoring, etc.

    Some of what I thought would be advantages of a message based approach were:
    1. No CLU (at the expense of messages though)
    2. No complex code surrounding weird cooldown timing/changes.
    3. REALLY easy to track anything since we're not tied to CLU weirdness and/or limitations. It's as simple as a receiver sending over a spell id to a sender.

    Guess you could sum all that up by saying it's very simple to code and the data would be very reliable +/- message lag (which I'm personally ok with).

    I think I'm probably still going to work on this, and convince a couple healers to try it out with me. I've got no other projects :)

    I honestly wanted it because I tank, I'm not happy with the features available in RaidCooldowns, and I REALLY want to know status of Guardian Spirit, Pain Suppression, Hand of Sacrifice, and one or two other external cooldowns without having to be so vocal about it in Vent.

    Keep the feedback coming!

    Oh btw, as far as features go (and some of this is already in my working prototype):

    1. You can choose whether you want to receive and/or send to cut down on resources. I expect only tanks, healers, and raid leaders would actually have a use for it.

    2. No spells are hard coded into the program, each receiver configures what spells it wants to monitor. If you look around at similar addons this is the biggest complaint (being hard coded into it)

    3. It's smart about if people are dead, disconnected, or not in the zone.

    As far as UI is concerned:

    1. If Receiving you have a basic box with an icon for each spell you're tracking. In the center is a number showing "how many are available" (just like an aura's stack count for example). Below the icon is a timer which shows up if all people have used the ability and you need to know how long until one is available again (think battle res).

    2. When you hover over an icon you'll see a tooltip with the status of each person who has that spell. It'll show their name, whether it's available, and it not how long until it's available again.

    3. One of the nicer things is that it's not a bunch of bars with one bar per player per spell (and a generic bar at that). But if you're looking for a specific spell, you just look at the one icon and you can quickly know if it's available and if not when.

    In short, you can get a running summary of the status of all people who have a spell, not just that it's on cooldown, but also how many are potentially available and the status for each player.

    Seemed like a useful tool. Could this be done with CLU, yeah. I'm too optimistic and apparently too lazy :)
    Posted in: Libraries
  • 0

    posted a message on WoW PuG Builder [Official Thread]
    Great addon idea. I don't lead pugs but that doesn't mean I don't know the work and frustration involved in doing so. I can see this being very useful to a lot of people.
    Posted in: Raid AddOns
  • 0

    posted a message on Does AceComm protect the receiving end too?
    And I have to admit I'm not completely naive. I'm very suspicious of this idea! Mostly because I'm surprised it doesn't already exist in a mature form (I looked and looked and could not find something equivalent to what I want to do.....I haven't explained all the features btw).

    The fact that it doesn't exist, makes me think there is a fundamental reason for it. Be it technical or otherwise.

    This is really the same thing was what oRA does, and similar to what RaidCooldowns does. But oRA only tracks a few spells and RaidCooldowns uses a hybrid Comm/CLU approach.

    So far the only answer I can find why it doesn't exist, is because it forces people to run addons to be useful. That's a darn good reason but it's the only one I've come up with.
    Posted in: Libraries
  • 0

    posted a message on Does AceComm protect the receiving end too?
    Besides the initial handshaking, broadcasts would only happen every 1 second -IF- something needed to be broadcast. And I'm not sure how often that would be.

    For example, if 40 receivers all wanted to track Guardian Spirit and Guardian spirit were on a 2 minute cooldown, the following would take place anytime a Sender uses Guardian Spirit:

    1. Sender "A" uses Guardian Spirit: Message is sent by Sender "A" to the Receiver comm channel (message contains sender name, spellid and cooldown remainder).

    2. All 40 receivers receive the message and start their own individual cooldown timer based on the message.

    No other messages would be sent by this Sender for this spell unless the
    cooldown duration for it changed dramatically (e.g. it got longer for some reason or it got shorter for some reason). Guardian spirit used to have a thing where it's cooldown would be two minutes if it didn't proc and 3 minutes if it did. It doesn't anymore, but presumably there are still spells like that.

    Of course, that's just one spell. If there are 40 receivers/senders, and all senders use an ability requested by a receiver, then yes, 40 messages would be sent out at the same time more or less.

    So for one spell it's not a big deal, the concerns are when there are a lot of spells, or more specifically, a lot of really short duration spells that are used on cooldown.
    Posted in: Libraries
  • 0

    posted a message on Does AceComm protect the receiving end too?
    Quote from galmok
    How many senders would at most be active at any given time?

    40 would be the worst case scenario based on current raid sizes. With 40 receivers as well. Keep in mind each Sender could have quite a few items to keep track of, say 10 of them. So if all 10 "changed" then on the next message loop 10 messages would be sent out to all 40 receivers.

    I'll stop being so secretive about the idea. It's a raid cooldown tracking addon concept using AceComm instead of using combat log events. I realize using addon comm has some drawbacks but it also has some benefits.

    I'm still in the "is this a sound idea or not" phase so I appreciate all the help here.
    Posted in: Libraries
  • 0

    posted a message on AceConfig resets slider value?
    It makes sense not to have defaults of arbritrary value, there can't be a one size fits all default. Just set it. For the record, here's the documentation:


    And here's the relevant quote:
    If no "min" or "max" are specified, the manual input of the range control will accept any and all values!
    step - step value: "smaller than this will break the code" (default=no stepping limit)

    Note that you can consider the fact that the author used defaults as an error checking condition to prevent crazy errors showing in the addon. Just because defaults were supplied that doesn't mean they shouldn't be entered.

    I wouldn't personally agree that this is a bug. An alternative would have been for the lib author to throw an error if they weren't set. Which I suppose would have helped your cause as you'd have known sooner that the values should be specified.
    Posted in: Ace3
  • 0

    posted a message on Does AceComm protect the receiving end too?
    Here's the current "protocol" (using the term loosely). What are the best practices here? This WOULD be an in combat addon so I'm very concerned about issues. I'd like to know before I start worrying about code whether this is bound to cause issues or not.

    Note that I do have a working prototype.

    There are Senders (S's) and Receivers (R's)
    • R's listen to comm channel "R" and send on comm channel "S".
    • S's listen to comm channel "S" and send on comm channel "R".
    • R's and S's don't listen to the same channel they send on.
    • R's and S's are not activated unless in a raid.
    • All messages go through RAID or WHISPER, but mostly RAID.

    In short, there are three messages:
    1. INTEREST (sent from R's to S's when first joining a raid group, no messages sent in response)
    2. EXIST (sent from S's to R's when first joining a raid group, an INTEREST message is sent in response to the S)
    3. UPDATE (sent from S's to R's as often as every 1 second but only when certain in game events happen, no messages are send in response)

    Here are more specific details if it helps...
    When R's become active they:
    • Join the "R" comm channel.
    • Broadcast message to comm channel "S" indicating they have INTEREST in something.

    When S's become active they:
    • Join the "S" comm channel.
    • Broadcast message to comm channel "R" advertising that they EXIST.

    When S's receive the INTEREST message they:
    • Update internal data structures and identify what, if any messages need to be sent during the next message cycle.
    • On each message cycle all messages that need to be sent are done so via comm channel "R". Let's call these messages UPDATE.
    • Note: A message cycle is basically a one second timer.

    When R's receive the UPDATE message they:
    • Update internal data structures but do nothing in return.

    When R's receive the EXIST message they:
    • WHISPER message to the S who sent the message with an INTEREST message.
    Posted in: Libraries
  • 0

    posted a message on Quartz: Modular Casting Bar
    Quote from lorelye
    Yes but I'm a druid... I have 15000 spells. I use all my Cliques, and my shift-cliques, and all the number keys I can reach with the hand that's not Clique-ing. I am Lyelu, hear me rawr! But seriously, I have a tank selected at all times.

    Someone wrote a "proof of concept", so I'm going to try it out:

    I had a post all typed up yesterday but decided not to post figuring someone with a better answer would come along...

    I understand exactly your situation, although I'm a tank not a healer. You like to have everything important near grid because grid consumes most of your "eye time".

    I don't think you'll ever see an addon that automatically sets a focus, targets a focus, etc (those are protected functions). But there are some other things you can do...

    Have you considered that maybe you don't actually need to see a cast bar? For example, DBM/DXE have all kinds of raid warnings in the center of your screen (by default) and many are mapped to sounds.

    Using the Shambling Horrors Enrage as an example, I know I get a warning in the middle of my screen, and pretty sure there's also a timer bar counting down for it too.

    If you use either of these mods, have you considered tweaking the sounds or timer locations to help you out?

    Case in point: On DBS DXE generates way too many sounds that I don't give a rats ass about when tanking. So I turned off every single sound except for the one that puts blood on the tank. I hear the sound, I know I have to taunt. No other sounds at all to distract me.

    Really, I'm just suggesting you try out customizing the boss mods a bit to make sounds work more smartly for you.

    Good luck!
    Posted in: General AddOns
  • 0

    posted a message on Simple DKP Addon Needs Creator
    Just the fact that you have to sync up who can and cannot access/change dkp data, and that it's stored in a single location (guild notes, etc) is already the first area of complexity. Sure, it can be done, but it's easy to underestimate how "simple" certain tasks are until you dig in there and start really using the API.
    Posted in: Addon Ideas
  • 0

    posted a message on Does AceComm protect the receiving end too?
    Thanks for the answers. I'm looking into an idea that may, at times, be spammy. Most likely when a raid group is just forming and people are accepting quickly. Or if by some crazy coincidence a bunch of people log on at the same time. I have concerns about that as it's when most of the "Hey there!" ... "Oh Hi!" chatter would occur.
    Posted in: Libraries
  • 0

    posted a message on Does AceComm protect the receiving end too?
    Can't find a concrete answer. I guess AceComm uses ChatThrottleLib. And I understand that the addon sending the messages is protected from sending too much too quick. But what about the addon's receiving the messages? Can they get flooded and disconnect or does AceComm handle that end too?

    Thanks. Probably an obvious answer.
    Posted in: Libraries
  • 0

    posted a message on Newbie tip for OnUpdate performance
    Quote from Dridzt
    Just a side note that monitoring UNIT_AURA to set / unset OnUpdate is not always cheaper than a throttled OnUpdate to begin with.

    It would be true when solo but in a raid environment UNIT_AURA can fire exceptionally spammy
    (many more times than a throttled OnUpdate would since that is a fixed interval you have picked)

    Essentially using the OnUpdate would give you a more or less steady performance hit,
    UNIT_AURA will vary greatly with environment.

    I wanted to come back and bump this thread to acknowledge that Dridzt was correct in his thoughts about actual performance. While I still am able to see improvements, it was no where along the lones of 40%. Probably more like 5% truth be told. It's not really possible to reproduce the same exact situation.

    I still have confidence that it was a good decision. Mainly, I already have to hook into UNIT_AURA for other events so I can't avoid it entirely

    Thanks again everyone for the latter posts.
    Posted in: Lua Code Discussion
  • To post a comment, please or register a new account.