• 0

    posted a message on Grid
    Quote from soltari »

    Any chance to implement that as an option in game? If I change the code for myself it gets overwritten by WAU with each Grid update.

    Thank you for your time. :)


    If you wanna do it so it doesn't get overwritten, have a look at GridLayoutForHealers. You can make your own layout as a separate addon and select it in game, just like what GridLayoutForHealers does.
    Posted in: Grid & Grid2
  • 0

    posted a message on Unofficial oUF - methods used for layouts
    Quote from Rabbit »

    http://www.wowwiki.com/Widget_API


    Point taken. :)

    I never looked at secure templates before, that's why I wasn't quite sure what I needed to do. I had tried to use :Hide() before I posted here, but the frame was hiding and then showing up again immediately. Then I messed with the events registered for that unit, no luck. So now I took another good look at ouf.lua and I found RegisterUnitWatch, using UnregisterUnitWatch did the trick.



    Posted in: Unit Frames
  • 0

    posted a message on Unofficial oUF - methods used for layouts

    Apologies if this was answered before, searching didn't return any useful matches, but how is it possible to hide frames once they're spawned, without reloading UI?

    And oUF_Ammo rocks! Maybe because I've been using agUF forever. :)
    Posted in: Unit Frames
  • 0

    posted a message on Unofficial oUF - methods used for layouts

    It's the coordinates I think. :)
    Posted in: Unit Frames
  • 0

    posted a message on Unofficial oUF - methods used for layouts
    Thanks for the reply, I had actually missed the part where it stops at the first debuff valid for highlighting. :P

    You're right, the possible performance gain is offset by the amount of work needed to replicate the oUF aura functions in your own layout. I had in mind a priority system for highlighting such as what the old Minigroup used to have, or what Grid has, which would involve iterating through all auras. Might be handy for druid/priest, but since I play a paladin now, I won't gain any benefit from it at least.



    Posted in: Unit Frames
  • 0

    posted a message on Unofficial oUF - methods used for layouts

    Ammo, I have a question related to iterating auras, specifically to oUF and oUF_DebuffHighlight, but it's quite common in general.

    First off, oUF iterates through unit auras following a UNIT_AURA event. Then oUF_DebuffHighlight does the same thing again to determine the debuff type it needs to highlight (or not).

    The way I see it, this has the advantage that you can use oUF_DebuffHighlight as a separate addon, so it's easy to reuse by others. On the other hand, replicating the functionality from oUF/elements/aura.lua in oUF_Ammo and bundling the debuff highlight code with it would save the second iteration through the unit auras.

    Considering a raid situation, it's often that auras change and UNIT_AURA triggers a lot. So the tradeoff is, I think, between speed and modularity/reuse.

    My question then is, if one was gonna do his own oUF layout that includes debuff highlighting, would it be better to rewrite the oUF aura code and add debuff highlighting as part of it? Do you have any approximation regarding the performance loss due to parsing the auras twice instead of once?
    Posted in: Unit Frames
  • 0

    posted a message on Grid
    Quote from maia »

    There's a simply reason why the number of apps isn't included in the core Grid app: the feature was added by Blizzard in 2.1 (I believe), and noone cared to update Grid after SpecialEvents was updated to support this functionality. So feel free to branch Grid, make the appropriate changes, test your version for a few days and then let Pastamancer know that it's stable and he can merge it back to the trunk. I havn't looked into it, but if you're right it's probably just a few lines that need to be changed/added.



    I've had this in my local version of Grid for over a week, and it worked fine with no side effects that I noticed. Actually, the "refreshed" events are not even needed for this, I had them in because testing something else and I blindly copy/pasted. So the actual lines that need to be added are:

    self:RegisterEvent("SpecialEvents_UnitDebuffCountChanged", "SpecialEvents_UnitDebuffGained")
    self:RegisterEvent("SpecialEvents_UnitBuffCountChanged", "SpecialEvents_UnitBuffGained")


    The reason why I didn't think this should be part of vanilla Grid was the limited possibilities to show things like number of stacks. The center icon doesn't have a counter and the corner indicators need extra options to allow changing colour based on applications, which is what plugins like the GridStatusLifebloom do.

    But well, I might be wrong, I guess is up to Pastamancer to decide if it should go in or not. :)
    Posted in: Grid & Grid2
  • 0

    posted a message on Grid
    Quote from Phanx »

    You can easily do that from a plugin; other plugins do it already to track stack counts. GridStatusRaidDebuff does it for debuffs, but from what I've read is rather poorly coded and wastes many CPU cycles. I think GridStatusHotStack does it for buffs (specifically HoTs), and the code should be easily adaptible to tracking debuffs instead.


    Yeah I know, I looked at those plugins, but what I wanted was to allow those additional icons to function like the builtin statuses, while showing things like number of stacks. For example, in GridStatusAuras:SpecialEvents_UnitDebuffGained:

    	self.core:SendStatusGained(u.name,
    				  status,
    				  settings.priority,
    				  (settings.range and 30),
    				  settings.color,
    				  settings.text,
    				  apps,
    				  nil,
    				  tex)


    This sends the number of applications to the indicator, but it won't be refreshed properly because SpecialEvents_UnitDebuffCountChanged event is not registered.

    What plugins like GridStatusRaidDebuff do is they register their own events and send the result to Grid indicators, which is not exactly what I want.

    So I'm just looking for advice if it's possible for a plugin to register those events as part of Grid. I'm not sure I got the terminology right, I hope what I wrote makes sense.


    Posted in: Grid & Grid2
  • 0

    posted a message on Grid

    Would it be possible to have the padding separated into horizontal padding and vertical padding? To explain why, I want to add a couple of icons for each player in Grid, and I couldn't find any practical way to do it inside the frame itself. So I resorted to anchoring them to the right of player frames, and I need to increase the padding to avoid overlapping. While I only need to adjust the horizontal padding, this will also increase the vertical padding, so I had to hardcode a 0 vertical padding into GridLayout.lua.

    There might be a better way to do it, which I didn't find, but any suggestions are welcome. :)

    And another question: I want to display debuff count, but the events to enable this are not registered. I realize this will be seen as wasted CPU cycles for most Grid users, so I'm not asking to add it to Grid itself. I'm not knowledgeable enough in Lua, but is there any way to do it from another addon, to avoid changing Grid code? Currently I have this in GridStatusAuras:OnEnable:

    	self:RegisterEvent("SpecialEvents_UnitDebuffCountChanged", "SpecialEvents_UnitDebuffGained")
    	self:RegisterEvent("SpecialEvents_UnitDebuffRefreshed", "SpecialEvents_UnitDebuffGained")
    	self:RegisterEvent("SpecialEvents_UnitBuffCountChanged", "SpecialEvents_UnitBuffGained")
    	self:RegisterEvent("SpecialEvents_UnitBuffRefreshed", "SpecialEvents_UnitBuffGained")


    Thanks in advance.
    Posted in: Grid & Grid2
  • 0

    posted a message on Hourglass - A lightweight oCD/CooldownTimers2 improved remake.

    Looks good. :)

    One bug I found: the get and set functions for min and max duration need tostring and tonumber respectively:

    				min = {
    					type = "input",
    					name = L["Minimum duration"],
    					desc = L["Minimum cooldown duration to display"],
    					pattern = "%d+",
    					get = function() return tostring(Hourglass.db.profile.min) end,
    					set = function(info, v) Hourglass.db.profile.min = tonumber(v) end,
    					order = 1,
    				},
    				max = {
    					type = "input",
    					name = L["Maximum duration"],
    					desc = L["Maximum cooldown duration to display"],
    					pattern = "%d+",
    					get = function() return tostring(Hourglass.db.profile.max) end,
    					set = function(info, v) Hourglass.db.profile.max = tonumber(v) end,
    					order = 2, 
    				},


    Otherwise the addon gives errors when trying to change the values.
    Posted in: General AddOns
  • 0

    posted a message on BadBoy: An extremely minimal spam blocker & reporter
    Just got gold spammed with <>, I'd appreciate if you can add it, thanks.
    Posted in: General AddOns
  • 0

    posted a message on ag_UnitFrames Status (What's going on?)
    Quote from andreasg »

    It's because the event UNIT_MAXHEALTH or whatever isn't registered, which means that ONLY if your max health is changed it won't be noticed right away. In instances, people taking damage, getting healthed etc. isn't slow. But I can register the event, it's no problem :P


    Great to see you back. :) Seems like this "issue" is not much of an issue, I was getting worried, thanks for the reply.

    One other thing that has bugged me is the behaviour of party pets. They choose to disappear at times, usually after zoning in/out, or when resummoned. Would be great if you can have a look at it, thanks in advance!


    Posted in: Unit Frames
  • 0

    posted a message on ag_UnitFrames Status (What's going on?)
    Quote from Mist »

    One thing I noticed while playing around with oUF is that the health bars in agUF (Ace3 version) update slightly late. I had both agUF and oUF frames for player and target on screen on top of each other and agUF health update was delayed by a small amount, less than 1 second. This wasn't a once-off ocurrence, it happened every time the health changed or close to that (I wasn't monitoring every single health change). I wonder if it's the aggro code that interferes with the updates? I have that turned off, but I didn't find anything else that looked suspicious.



    Quoting myself here on an older post, I did some testing recently and here's what happens: on health loss, agUF health bar will update with a delay of 0 to 2 seconds. I'm not sure what is the maximum delay, but I've definitely seen it bigger that the global cooldown. On health gain the update is always instant.

    It's easy to test with another UF as a reference and self-buffing with a health increase buff. In my case, I used oUF side-by-side with agUF and self-buffing with BoK, cancel the buff, rinse and repeat. So when I say 0-2 seconds delay or instant, it's relative to oUF update speed.

    It feels like it updates on a schedule rather than as soon as a health update occurs. Unfortunately I've been looking through the code but couldn't find anything that might cause this.

    It's a big issue if you want to use agUF for healing, health update delays bigger than the global cooldown are significant. I'd appreciate to hear any suggestions as to why it happens, and fixes are even more appreciated. :P

    Posted in: Unit Frames
  • 0

    posted a message on ag_unitframes - own buff filtering

    Try put this before "while (name) do":

    local istarget = self.unit == "target"


    and replace:

    if (duration) then


    with:

    if (duration or istarget) then


    Rather hackish, but hopefully it does the job. :)
    Posted in: Unit Frames
  • 0

    posted a message on ag_unitframes - own buff filtering

    You need to do something similar to what is done for debuffs just below the code you pasted. Debuffs are treated similar to what you want for buffs, except that instead of checking for duration it checks for the special case of Weakened Soul. Something like this should work I hope:

    while (name) do
    	-- record buffs
    	if (duration) then
    		c = aUF.cache.buffs[id]
    		c.id, c.name, c.texture, c.count, c.duration, c.timeLeft = buffid, name, texture, count, duration, timeLeft
    		id = id + 1
    	end
    	buffid = buffid + 1
    	name, rank, texture, count, duration, timeLeft = UnitBuff(unit, buffid, filter)	
    end


    You will also need to change:

    bcount = buffid - 1


    to:

    bcount = id - 1




    Posted in: Unit Frames
  • To post a comment, please or register a new account.