Authors CurseForge

Quote from Merl »

@ Dragon: The falloffs where fixed on the SVN, but not in the zip, I have updated it now. I'll add the old plain arch sometime soon :)

I'm not sure if this fixes the falloff bug, but the problem is that your last 'tick' to full is like twice as big as your entire bar, and red.

(edit) and it turns out that is incorrect. The bug appears to have something to do with going into combat.


I agree with the other comments: I want my UI symmetrical, and I have my own health on one side and my mana on the other. I want to be able to have my losses always fall towards the center of my screen and my gains all come in from the outside (or vice versa.) Having it always fall off right is unpleasant.


Also I totally agree that having preset bars that can't be mouse-scrolled in smaller increments is frustrating when trying to align. I wish I could point you to how it's done in other addons, but the semi-standard of having the slider move in 5/10 increments and a mousewheel scroll move it in 1 is ideal.

@ Saryai: Sorry, it seems I hid these options a bit to far away? Does anyone have a better suggestion than
modules - XXX ? But this is what you're looking for right? There is one thing missing tho, removal of 1 value, but it's coming :) Yes, the defaults are hard coded, but they are also over writable.

This is where you find the templates:
http://ace.chainweb.net/mhud/mHud_046_02_03.jpg
http://ace.chainweb.net/mhud/mHud_046_02_01.jpg
http://ace.chainweb.net/mhud/mHud_046_02_02.jpg

Edit: Skins can also register color/alpha templates, but at currently they can't overwrite the defaults, that's been changed, but haven't committed it yet.

@ All: In regards to the .1 on sliders, you can click the text / value and manually type in numbers, as long as its within the outer range of the slider.

Shows how often I look there. Everything I suggested was already in, just in an odd spot. Thanks for clarifying. :)

I'd just rename the menus to Color/Alpha Templates, then put them into the Skins section. Makes the most sense to me, at least.

If I'm looking at those screenies right, it seems we don't even need an out-of-combat-regen flag. So if I did this...

Value=1, Alpha=0.1
Value=0.98, Alpha=0.3
Value=0.4, Alpha=0.3
Value=0.01, Alpha=0.6
Value=0, Alpha=0.1

...I'd get about what I'm looking for in my OOC regen. I can deal with that.

Next up, debuff coloring. ^_^

Not sure how to implement that, but I'll give it some thought =) Added a skin template zip to the 1st post if you want to check it out, haven't tested it, I'm late for a raid ;)

Nice easy template to follow. You might want to fix the link name though. :D

Debuff coloring shouldn't be too bad to pull off. Set some extra default templates (Physical, Magic, Curse, Poison, Disease) so that you have the colors on hand and editable, and override the current color template when the unit is debuffed.

Have filtering set on a per-bar basis (I'd judge by class there for simplicity's sake, pretty sure it's a Blizz API call) and you have a winner.

Quote from Saryai »

statusbar.zip
* Middlebar.blp - The center bar.
* RB1.blp - Right bar, assuming unmirrored. Note that due to the design of the bar, it is very hard to judge rage and low mana.
* LB1.blp - Left bar. Simple arc fitting the center.

<snip>

Thanks a lot, after some time I've managed to set it up and it just looks awesome :) And thanks to Merl too for this incredible add on, I've always wanted a highly customable HUD.

Looking good so far, the only issues I have deal with updating using falloff, where there's this vertical bar that extends to the top of the screen from the top of the HUD that's the width of the falloff/gain, somewhat distracting. Also happens very quickly so hard to get a SS of it...

Second issue is when changing targets, instead of just instantly adjusting the bars to the new levels, there's either a big gain or a big loss on falloff, old version never did this, falloff needs to check for target changes and not activate if the change is due to that...

@ StormFX: I noticed myself earlier today, committed some changes, but didn't take the time to fully debug it, hope it's OK tho.

@ Dragon: I hope it's not to annoying, I'll have a look at it when I get the chance :)

Quote from Merl »

@ Dragon: I hope it's not to annoying, I'll have a look at it when I get the chance :)

Oh it's extremely annoying, tho I think I got a SS of it but it's at home and I'm at work. Quite frankly there's only 2 things more annoying than this bug, going without a HUD, or going back to an old version without all the new fun stuff. :P

That all being said I got 2 more for ya, one request one bug. Request is the old threat meter as a module, much <3 for that, tho it could have used some improvement as it seemed to stop at 110% where that was the melee limit not the ranged limit. Seeing threat above 110% would be nice, as would using something like your abyss module to show where the tank's threat is when the bar is full, or if you do have agro, what your threat is VS the next highest persons, tho just giving it a precursory think over I can see the challenges innate in a single bar representing threat...

The bug is if you rotate arch textures so they're horizontal and try to make the bar move across, the moving bar goes all funny and it just doesn't work at all. Can't really SS this one as you have to see it in action, just rotate the bar horizontal instead of vertical and you should see it.

Dragon, are you using the latest SVN build? If not, you might want to update.

Here's mine just in case. Falloff works perfectly. It's a revision or two old. you may or may not run into already-fixed bugs, but so far it's been perfect for me.

Edit: IIRC, the arched texture rotation bug has been around since before the rewrite. I remember having issues with it. Lesson learned, use unitframes for horizontal bars and huds for vertical. >.>

I used to use RapidSVN to download stuff from SVN's then discovered my update script could access any SVN but needed the official subversion client installed, which promptly broke RapidSVN and I haven't really tried to fix it yet... As far as horizontal arches go, I used them all the time in old mHud with no problem for months, see attached for what I'm going for (and what no longer works). Pet bars are the (extremely) faded bars underneath.

@ Dragon: I'll write a Threat-2.0 module after 2.4 has hit, don't want to waist time on Threat-1.0.
About the texture, I'll have a look at it :)

Edit: Just committed the changes, had renamed a variable, but not everywhere. Should work as intended now, thx for the heads up :)

"Gradiant" should be spelled "Gradient", in all cases that the word appears. Makes hand-editing a pain. >.>

I'm working on creating a skin based on the bars I posted a page or three back. Finally got around to making some frames. I'll release it when it's ready and tested.

Quote from Saryai »

"Gradiant" should be spelled "Gradient", in all cases that the word appears. Makes hand-editing a pain. >.>

I'm working on creating a skin based on the bars I posted a page or three back. Finally got around to making some frames. I'll release it when it's ready and tested.

Hehe, over 200 tokens where replaced. In the event I forgot some, plz let me know :)

Looking forward to see your skin! :)

Hehe, thanks. Ran through with Notepad++, don't think I found any.

It should be ready in about an hour, working on it now.

[2008/03/21 16:13:45-231-x2]: mHud\GradientAlpha\GradientAlpha.lua:92: Usage: <unnamed>:SetBlendMode("mode")
mHud\GradientAlpha\GradientAlpha.lua:92: in function `?'
CallbackHandler-1.0\CallbackHandler-1.0.lua:146: in function <...Ons\Ace3\CallbackHandler-1.0\CallbackHandler-1.0.lua:146>
<string>:"safecall Dispatcher[2]":4: in function <[string "safecall Dispatcher[2]"]:4>
<in C code>: ?
<string>:"safecall Dispatcher[2]":13: in function `?'
CallbackHandler-1.0\CallbackHandler-1.0.lua:91: in function `SendMessage'
mHud\mBar.lua:121: in function `SetValue'
mHud\mBar.lua:78: in function `ConfigChange'
mHud\mBar.lua:47: in function `CreateBar'
mHud\mHud.lua:90: in function <Interface\AddOns\mHud\mHud.lua:69>
(tail call): ?:
<in C code>: ?
...:
Baggins-Beta 1\Baggins-Filtering.lua:1732: in function `ForceFullRefresh'
Baggins-Beta 1\Baggins-Options.lua:1105: in function `OnProfileEnable'
Baggins-Beta 1\Baggins.lua:225: in function <Interface\AddOns\Baggins\Baggins.lua:170>
<in C code>: in function `pcall'
AceAddon-2.0-57245 (Ace2):24: in function <Interface\AddOns\Ace2\AceAddon-2.0\AceAddon-2.0.lua:23>
AceAddon-2.0-57245 (Ace2):998: in function `ManualEnable'
AceAddon-2.0-57245 (Ace2):926: in function <Interface\AddOns\Ace2\AceAddon-2.0\AceAddon-2.0.lua:919>
<in C code>: ?
AceEvent-2.0-63812 (Ace2):260: in function `TriggerEvent'
AceEvent-2.0-63812 (Ace2):917: in function <Interface\AddOns\Ace2\AceEvent-2.0\AceEvent-2.0.lua:910>

Disabling Baggins just spawns the same error with PT3Bar. Not quite sure what's up. Only happened after updating to the latest SVN build.

Also, question on the skin before I head out to work. Only reason it's not ready yet is because I'm getting cockblocked by Lua syntax. Error:

[2008/03/21 16:21:07-233-x1]: mHud_sArcasm\mHud_sArcasm.lua:29: '}' expected (to close '{' at line 27) near '['

At first I thought I hadn't closed a table (several of which I hadn't, GG editing too quickly, but I'm still getting the same error after going through it a few times), it really doesn't seem to like my alpha template table.

I'll probably end up just commenting out the alpha templates, but in the meantime would you mind proofreading to see where that error really is?

OOCTarget = {
overWrite = true <= missing ','
[1] = { v = 1.00, c = { a = 0.60, b = "BLEND" }},

Edit: As for the other problem, it might be related to the gradiant stuff in your saved variables, try replacing it to the new and improved gradient :)

Whoops. That goes to proof that one should never proofread addons at 5am, or 20 minutes before work.

As for the big error, nuking SVs got it to work. Replacing 'gradiant' in SVs didn't, for some reason. *shrug*

Just need to tweak a couple things and it'll be ready.