WoWInterface

WoWInterface (https://www.wowinterface.com/forums/index.php)
-   Lua/XML Help (https://www.wowinterface.com/forums/forumdisplay.php?f=16)
-   -   split statusbars (https://www.wowinterface.com/forums/showthread.php?t=56030)

Coldkil 02-09-18 08:07 AM

split statusbars
 
Hi, it's been a long time from the last i made something for wow. Now i'm back at it with a new(?) thing (at least for me)

The idea was to make customized split statusbars. Example: you have the HP bar divided in 3 smaller ones that are updated accordingly, which each one representing the 0-33, 33-66, 66-100 portions.

Idea was to either used masks/textures, but with me being inept at photoshop i opted towards another solution, to actually manually create the smaller statusbars and use the SetMinMaxValues() methods.

pseudocode here (function/events names may be incorrect, just going with memory).
Code:

-- created 3 frames as containers
-- created 3 statusbars

hp1:SetMinMaxValues(0,maxhp/3)
hp2:SetMinMaxValues(maxhp/3, maxhp/3*2)
hp3:SetMinMaxValues(maxhp/3*2, maxhp)

local function UpdateHP(bar)
    cur = UnitHealth("player")
    if cur then bar:SetValue(cur) end
end

local function UpdateAll()
    UpdateHP(hp1)
    UpdateHP(hp2)
    UpdateHP(hp3)
end

-- create a frame to hold a script
frame:RegisterEvent("PLAYER_HEALTH_FREQUENT")
frame:SetScript('OnEvent', UpdateAll())

If there are errors in code like variables scope, it's not a problem and it's fixable - what i wanted to know is if there are any logical fallacies with this approach like "you cannot update too many bars together for a game limitation" or similar.

I know already that i could simply design a texture the size of a bar made by how many shapes i want and use a transparent statusbar that overlaps the same texture on background with a different color to obtain a very similar if not equal effect. however this way evry single doodad is an element of its own, letting me to experiment with positioning and designs different from a standard | | | | | | | | | or - - - - - - - -

Hope i've benn clear, and thanks to anyone wants to dedicate its spare time to help me.

Aftermathhqt 02-09-18 05:34 PM

Quote:

Originally Posted by Coldkil (Post 326781)
Snip

Can you link full code?

Kakjens 02-09-18 07:07 PM

Is there need for UpdateHP(bar)? For me more natural would be checks which status-bars need to be updated.
I sense a bug and possible fix for it, though.
But, leaving scoping aside, most of my objections to this pseudo-code would be gone by calculation of current hp (and verification that it's not nil?) in UpdateAll() instead of UpdateHP(bar).

lightspark 02-10-18 12:43 AM

So you're finally here :D

Take a look at oUF's classpower code, destrolock's soul shards behave exactly the same way.

In your case mod will be maxhp/3, max will be 3 because it's just a number of elements, health bars.

The rest is almost the same, you can even leave bars' min/max values as 0 and 1 and never touch them again, because cur value is adjusted anyway, you obv don't need that 0 check.

It's one update function to update all 3 or more status bars, it's perfectly scalable.

Coldkil 02-10-18 01:36 AM

I remebered that THERE WAS something already working on this template. Thanks for pointers everyone, i'll go check and see if i can put something together to show you.

If i'm able to put it all together, it may lead to interesting setups.

EDIT: i think i'll need to override the Health.OnUpdate method in oUF, or can i use PostUpdateHealth instead to avoid messing with the default library code?

lightspark 02-10-18 01:53 AM

Quote:

Originally Posted by Coldkil (Post 326799)
EDIT: i think i'll need to override the Health.OnUpdate method in oUF, or can i use PostUpdateHealth instead to avoid messing with the default library code?

You really don't need to mess w/ oUF code because pretty much everything is overridable.

Override health's Update func by defining .Health.Override in your layout, colour handling is now a separate method that can be overridden as well, so it's as PITA-less as possible.

Coldkil 02-12-18 01:36 AM

Ok, i did it. Don't have a video/gif right now but ji'm going to provide one for sure. Nice how even if the value you want to set the statusbar at is lower than minValue, that doesn't trigger errors and the bar is automatically set at 0 (at least visually); so i can set all segments with the same value and nhave no issues whatsoever.

It makes things definitely interesting. Also: since you can work with percentages, you don't really need an actual value but you can set the segments with a 0-100 scale and the bar will behave accordingly, making eveything much less of a pain.

I think i can even make a function that creates automatically the split bars by just passing the number of actual segments i need. I need to make more tests and see how i can do it.

Bottom line: it's working!!!!! Now i can start creating my new oUF layout.

Thanks everyone for the help.

zork 02-12-18 02:29 AM

Gogo, show it! :-)

Coldkil 02-12-18 01:08 PM

Ok, disclaimer all images suck, first time trying to record a video and convert it to gifs, add to it i have a shitty 4mb (actually 3.5) connection and you get the full picture. (hell i'll have to finish downloading wow at work because of this).

What i'm working on right now is to make a function that given a container/anchor frame, an index (how many splits you want), size of the split, bar orientation and growth direction/s that creates everything in a single whiff, and i'm pretty near doing it (basically i need to manage anchor points).

The good part is that it's all managed by a single 0-100 scale, meaning you can use it for whatever value you want to display this way because you just need to convert the actual value into a percentage. It solves so many issues at managing variables.

However, here's what i did.

- first try to set up stuff. trying both horizontal and vertical.




- adding some doodads


- what do you mean i can mix things up?



- but wait, there's more!!


Hope you enjoy. Feel free to point eventual errors, but it's working :P

lightspark 02-12-18 01:28 PM

Quote:

Originally Posted by Coldkil (Post 326848)

That's exactly what I expected, I was going to ask you if you're going to make SAO-inspired health bars, lol :D

Something like this may actually be somewhat useful for classes w/ execute abilities.

And you made a slider, I usually create a timer w/ math.rand, lazy~ :rolleyes:

Quote:

Originally Posted by Coldkil (Post 326848)
Hope you enjoy. Feel free to point eventual errors, but it's working :P

Theoretically, there should be none, oUF classpower element has been running on this code for almost a year now.

Ammako 02-12-18 01:31 PM

That looks pretty good, I don't know why I expected just one long bar except with splits throughout it.

(you might be interested in checking out gfycat)

zork 02-12-18 04:46 PM

Nice work buddy.

JDoubleU00 02-12-18 07:22 PM

Wow (no pun intended).

Coldkil 02-13-18 02:00 AM

Ok, some questions for an actual implementation. Does the execute phase change between classes? IIRC warrior and rogue have 35% but i don't remeber all of them.

It would be nice to have the last red bar defining the execute phase, but i need to know if i'll have to manage it on a per-class basis. It may change also the style of the bars, so it's kinda important.

EDIT: i'll also need a refresh on how to make things pixelperfect, since playing on a 2k resolution means no easy script to run - i manually scaled down UIParent, but when i did the bar on the last gif (the small squares) i started having issues with borders being randomly 1 or 2 pixels and it's just horrible.

EDIT2: i just realized i can make with the same system an "old arcade boss" hp bar style with multiple bars on each other with different colors. I'll try tonight.

lightspark 02-13-18 02:41 AM

Quote:

Originally Posted by Coldkil (Post 326869)
Ok, some questions for an actual implementation. Does the execute phase change between classes? IIRC warrior and rogue have 35% but i don't remeber all of them.

It would be nice to have the last red bar defining the execute phase, but i need to know if i'll have to manage it on a per-class basis. It may change also the style of the bars, so it's kinda important.

I think only warriors have execute now. They removed execute-like abilities from others in 7.0 because of class fantasy, I might be wrong though.

Quote:

Originally Posted by Coldkil (Post 326869)
EDIT: i'll also need a refresh on how to make things pixelperfect, since playing on a 2k resolution means no easy script to run - i manually scaled down UIParent, but when i did the bar on the last gif (the small squares) i started having issues with borders being randomly 1 or 2 pixels and it's just horrible.

It's all about positioning your frames correctly, in general, you should use frames corners (TOPLEFT, TOPRIGHT, etc), and if your frame's height and width are even numbers you may also use edges (TOP, BOTTOM, etc). Using CENTER point may place your frame on half-pixels, so don't use it o_O

You should also use proper UI scale, which is 768 / screen height, stuff gets tricky when it comes to HiDPI monitors though.

Coldkil 02-13-18 06:53 AM

Didn't know that - then that's why the small squares are fuzzy, theyr'e both 25px and use the LEFT/RIGHT anchors. Good to know.

Anyway, scaling UIParent and parenting everything to it should be fine. Layout will be extremely minimal, i wanted to make vertical bars, so i'll have to work a little on a readable yet non-intrusive setup.

wondering if stuff like combo/secondary resources will be better in a similar vertical layout or creating an L shape for player/target. pets/focus usually get waaaaay too much space when you only need an hp bar for both (or even just the name, you just need to know it exists). This PvE speaking, PvP is a completely different beast.

lightspark 02-13-18 07:11 AM

Quote:

Originally Posted by Coldkil (Post 326877)
Didn't know that - then that's why the small squares are fuzzy, theyr'e both 25px and use the LEFT/RIGHT anchors. Good to know.

Well, if you chain them then using LEFT, RIGHT, etc is fine, the placement of your first element is the most important in this case, for example, if it's on a half-pixel then the rest will be affected as well.

zork 02-13-18 07:58 AM

Lol I just had an idea.

https://imgur.com/a/bA78e

If you have a texture mask in form of a pie slice you can have a circular texture that is masked by that slice.
Now all you need to do is to scale the texture from 0 to 1 and it will fill the slice from inside out.

You could even overlay it and make it look like a ring.

You would need one slice texture per mask. The mask texture itself can be rotated but the width is fixed. If you need different slice sizes I would generate different mask textures. One for each size.

Coldkil 02-13-18 08:27 AM

Another thing that came out of my mind: if i want to be actually able to manage the bars, i need to provide some way to refer to those elements outside of the function code, right?

So, the idea was this (pseudocode again):
Code:

function createSplitBar (containerframe, [rest of arguments])
  local splittable ={}
  for i = 1, # do
      -- create bars code here
      splittable[i] = bar
  end
  containerframe.splittable = splittable
end

-- now i should be able to call it this way
playerframe.splittable[2]:SetStatusBarColor(.3,.4,.5)
-- or whatever other operation i want to do on bars

Is there something wrong (again, logic wise, code is just thrown there)?

lightspark 02-13-18 08:41 AM

Quote:

Originally Posted by Coldkil (Post 326880)
Another thing that came out of my mind: if i want to be actually able to manage the bars, i need to provide some way to refer to those elements outside of the function code, right?

So, the idea was this (pseudocode again):
Code:

function createSplitBar (containerframe, [rest of arguments])
  local splittable ={}
  for i = 1, # do
      -- create bars code here
      splittable[i] = bar
  end
  containerframe.splittable = splittable
end

-- now i should be able to call it this way
playerframe.splittable[2]:SetStatusBarColor(.3,.4,.5)
-- or whatever other operation i want to do on bars

Is there something wrong (again, logic wise, code is just thrown there)?

Nah, everything is fine, I'd also create a method that allowed me to update all bars in that table at once and add it to containerframe:

Lua Code:
  1. local function updateBars(self, method, ...)
  2.     for _, bar in next, self.splittable do
  3.         if bar[method] then
  4.             bar[method](bar, ...)
  5.         end
  6.     end
  7. end
  8.  
  9. local function createSplitBar(containerFrame, ...)
  10.     -- stuff here
  11.     containerFrame.UpdateBars = updateBars
  12. end
  13.  
  14. -- containerFrame:UpdateBars("SetStatusBarColor", 0.3, 0.4, 0.5)
  15. -- instead of
  16. -- containerFrame.splittable[1]:SetStatusBarColor(0.3, 0.4, 0.5)
  17. -- containerFrame.splittable[2]:SetStatusBarColor(0.3, 0.4, 0.5)
  18. -- containerFrame.splittable[3]:SetStatusBarColor(0.3, 0.4, 0.5)
  19. -- ...


All times are GMT -6. The time now is 11:03 PM.

vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI