Authors CurseForge

Quote from Phanx

Committed in r1686.

...

Good idea. If you could submit a ticket that would be helpful in not letting me forget about this once the more important fixes are done. :)

Thank you and ticket is created.

Ok, I found another problem when updating GridManaBars:
Currently the only way to make sure that icon, text and corner indicators are drawn in front of the manabar and not the other way around is by setting the manabar as parent for all of them. While this might work for Grids default indicators it does not with third party indicators and isn't a very nice solution anyway.

Therefore I would like to suggest a small change to Grids frame system:

Create a separate "Indicators" frame which lies in front of the healthbar and has the size of the whole unit frame (minus the border offset) and where every "normal" indicator (everything except the manabar) can add itself as child. This way it is assured that every normal indicator is drawn in front of the bars and isn't affected when the bars in the background change positions or size.

PS: Take your time. I know there are currently more important problems to be fixed in Grid.
PSS: The healing bar doesnt work!!!!!!111elf ;-) *takes cover*

Quote from Phanx

I'll commit a change tomorrow so that all default indicators get reset before custom ones.

Thank you, that would be nice! Since I've got a version now that seems to work as long as the manabar is reset after the healthbar.

Hi Phanx!
Awesome work with the new indicator API. I started adapting GridManaBars to use it.
The only problem I have is that the Manabar can't be drawn over the healthbar and therefore needs its own portion of space on the unit frame. Is there some way for an indicator to convince the healthbar not to use the unitframes whole space for itself? :-)
Otherwise I would have to hook the healthbars "reset"-function and reposition it by force, which isn't really the way I would prefer it.

I added it as an experiment, because people often type spell names incorrectly or don't realize it needs to be capitalized, and I thought the library would be helpful. I have not yet decided whether to keep it.

I think that is an extremely useful feature and I really hope you decide to keep it. And who cares about performance in a configuration dialog? It's not a highly repetitive or time crucial activity. I didn't test the feature but as long as it is happening only once to build up the database, its ok.

Thanks!

Quote from Starfox

wtb amazon.de 10€/20€ restock :O

Push? I want to buy Christmas presents :)

Quote from Borlox

The German 10€ cards could need a little restock :)

Thanks in advance!

The German 20€ cards, too.
And thanks from me, too :-)

Quote from Phanx

I've never worked with, or even used, a plugin that added indicators, so I have no idea. It should actually be simpler, though, since you don't need to poke around in AceOO-2.0 anymore.

Ok I think I'm a bit stupid here. With AceOO I could just "extend" GridFrame. How can I do that with Ace3.0 now? I already looked into Ace3.0's API but couldn't find an explanation what the modules really are and how exactly they work.

edit: Ok, the best solution I found is ignoring Ace3 and just manually securehooking every GridFrame method I need. Seems to work.

Thanks for the quick fix! I successfully ported all of my status-addons now.

Are there already some hints on how to port addons which add indicators?

I've got a few more bugs for you :-)

Happens on login:

Grid-1.30300.1311\GridStatusRange.lua:293: attempt to call method 'ScheduleRepeatingEvent' (a nil value)
Grid-1.30300.1311\GridStatusRange.lua:87: in function `EnableRange'

Happens when changing profiles:

Grid-1.30300.1311\GridLDB.lua:74: attempt to index field 'minimap' (a nil value)
<in C code>: in function `?'

Also I have a problem with loading saved variables for my grid addons. For example for GridStatusAurasExt AceDB-3.0 uses "GridStatus_GridStatusAurasExt" as name for the database while old AceDB-2.0 used only "GridStatusAurasExt". Therefore it does not find the old saved variables anymore.
Same goes for "GridStatusShield".

Thanks for the feedback.

I meant to make it a real library if somebody had said that he would need a display for this in his addon but doesn't had the time to write the whole tracking and calculation crap (and keep it up to date). Since no one has, I save a lot of time :D.

I think every other question raised was already answered by another person in this thread :-).

I'm the author of GridStatusShield which tries to track the amount left of shields on the raid. To do this I wrote a seperate file called LibShieldLeft.lua which throws events when shields appear,disappear and especially when they absorb something.
At the moment it calculates only the exact total size of a shield for PW:Shield, Divine Aegis and Valanyr bubble and only if cast by the player himself (not for any shield cast by another player in the raid). For every other shield it assumes a certain minimum total amount (the base amount for this shield without spellpower or any other bonus).
For GridStatusShield it worked fine since almost a year now.

Since I saw today that the author of Vuhdo used that file for his addon (which is ok for me) I wanted to ask if there is a generell interrest for a library like this (to be used for other unit frames). Then I would make it a real stand alone library which can be used by other addons.

Quote from vintoran

I have a question regarding the status "Unit Health".
My guild is slowly starting to get to Anub'arak hardmode p3 and my usual approach of only displaying health deficit is a bit subpar there.
Now my problem: "Unit Health" is doing exaclty the same as "Health Deficit" for me (except for the health threshold).
All I want is a numerical display of the current health.

I think GridStatusStrings (or something like that) does that. If that doesn't work you can try GridStatusControlPipes which definitely does that (among other things) but is far more complicated to use.

Have the same Problem.