Style registration separate from unit creation?

[Folji]

So this is mostly a question regarding good coding habits more than anything else, though I'm still trying to learn my way around addon development in general.

As far as I understand, Lua is a language in which you can't just straight-forward call a function before it has been defined. My development habits has be liking a top-to-bottom coding, having a constructor at the top that calls all the heavier chunks of code written further down. But that's not really an option out of the box in Lua, as far as I understand?

So for the sake of code simplicity when working with it, would it be a good habit to write the actual constructor code for each of the UI elements separate from the Lua file containing the style registration for oUF? I learned recently how functions and variables specific to an addon can be passed around within the addon through its namespace, so I could have a core file in which I create a frame and save it as a variable to the namespace, write all the constructor functions to that frame, then in the style file make that frame a local variable and call the constructor functions with the individual frames passed as a parameter?

Hopefully that wasn't too much a garble of a way to put it! But essentially, trying to figure good ways to not write too much repeated code and wind up with an oUF layout in which each frame has its own Lua file that essentially does everything on its own. Though I'm guessing the runtime difference wouldn't be too much difference, other than just lots of needlessly repeated code and one style registered for each type of frame.

[Seerah]

I always put my main code at the bottom of the file, referencing what is above it. Though you could certainly split things into different files.

[Tim]

Originally Posted by Folji As far as I understand, Lua is a language in which you can't just straight-forward call a function before it has been defined. My development habits has be liking a top-to-bottom coding, having a constructor at the top that calls all the heavier chunks of code written further down. But that's not really an option out of the box in Lua, as far as I understand?

Correct, you have to create the function before you call it unless you store it in the namespace in another file in which you still have to create it before calling it later in the other file as well.

Originally Posted by Folji So for the sake of code simplicity when working with it, would it be a good habit to write the actual constructor code for each of the UI elements separate from the Lua file containing the style registration for oUF? I learned recently how functions and variables specific to an addon can be passed around within the addon through its namespace, so I could have a core file in which I create a frame and save it as a variable to the namespace, write all the constructor functions to that frame, then in the style file make that frame a local variable and call the constructor functions with the individual frames passed as a parameter?

Assuming no gui/in game options. The way you code your ouf layout is entirely up to you. I'm not sure of the runtimes but, splitting stuff up does make editing easier instead of sifting through 1 file. Generally it's good to at least have a config file as well as a tags file if you plan to use them as well. Some people have a seperate file with most of their functions while others just include them within their layout file. If you have plans on releasing your styles you will want to consider coding to make things easier for the user to edit if they want which generally means splitting up your code. In the end it's once again entirely up to you how you want to lay your code out.

Haste has a few layouts that are good for learning from and so does zork.

[Folji]

So I managed to figure things out, and I've been making pretty nice progress with it!



But, now, what'd be the easy way to go about trimming that health bar? Would I have to create a suitable statusbar texture and SetStatusBarTexture() to do this, or is there an easy way to just use the backdrop frame I've already created beind the statusbars as a mask of sorts?

Also, is there any reference anywhere for the various colour tables oUF uses and overriding it globally? I found some code changing up metatables, but I couldn't get any of it to work, so instead I wrote a function out of the self.colors.power[power] stuff on the Github wiki

lib.SetColors = function(self)
    self.colors.power['MANA'] = {50/255, 140/255, 230/255}
    self.colors.power['RAGE'] = {255/255, 148/255, 148/255}
    self.colors.power['ENERGY'] = {255/255, 255/255, 30/255}
    self.colors.power['FOCUS'] = {255/255, 115/255, 60/255}
end

And then I just call that function in the frame constructor to apply the colour values. But are there any more efficient ways to go about this?

And any reference out there for additional colour values, such as for reaction colouring?

[Seerah]

Yes, just create a statusbar texture with the shape you want.

[Folji]

Properly horizontally mirroring statusbars, wound up resorting to just having an actual mirrored texture for the target frame until I can find a better solution.

But, having applied a texture with a particular shape like this, how can I now force the status bar to keep the texture static? Seems the standard behaviour is to anchor the texture to the "head" of the bar, so that it follows along with it as it shortens down.

[syncrow]

Originally Posted by Folji How can I now force the status bar to keep the texture static? Seems the standard behaviour is to anchor the texture to the "head" of the bar, so that it follows along with it as it shortens down.

This would be the easiest way but results in a stretched texture which you want to avoid (especially with your nice and shapy texture)

I'm assuming that the bar fill texture fits the size of the border?! If so, you should use the resize & crop method to handle the bar texture every time the health changes. Doing so doesn't stretch the texture only cut it.


Example:

local fileWidth, fileHeight = 256, 64
local originWidth = 180
local originHeight = 64
local left, top, bottom = 0, 0, 1
local barTex = <StatusBarFillTexture>
 
-- right anchor, cause the texture grows from right to left  <--
barTex:SetPoint("RIGHT",statusBar)  
 
-- cropping and resizing function (used health percentage value here)
local function UpdateBarTexture(perc)
    local width = originWidth / 100 * perc
    local right = width * 100 / fileWidth
    
    barTex:SetWidth(width)
    barTex:SetTexCoord(left, right, top, bottom)
end

Btw: nice diablo 3 console like of border texture <3

[Folji]

Originally Posted by syncrow Btw: nice diablo 3 console like of border texture <3

Hehe, thanks a lot! I did a number of iterations on the frame design to figure out what I wanted with them. The console unit frames for Diablo 3 felt like good inspiration for being a closely related art style, so I tried a few mockups with the WoW unit frame layout with the diablo look and feel, with a colour palette from the base WoW interface frame layout, and the result actually came out looking pretty good!

snip

And thanks a lot for the code. I'll try my way with it tomorrow, see what I can make happen. By the way you've written it, I guess I'd need to try and hook the PostUpdate script for the statusbar and run the function through there?

Curious observation I made was that when I took the player health bar and threw in hp:GetStatusBarTexture():SetTexCoord(1,0,0,1) it actually works as it should. But then the target frame has hp:SetReverseFill(true) and that somehow seems to break it? The texture coords given to the player and target status bars are as specified in the code when the frames are created, though not sure about after that point. But even so, changing the texture coords seems to have no actual effect on the bars, beyond keeping a non-reversed frame from resizing the texture.

[syncrow]

This might be helpful!

[Folji]

Trying to set the point of a statusbar texture really doesn't seem to want to stick. No matter what, it always pops back to TOPLEFT the next moment. For now it'd definitely be way easier to just alter the shape of the frame to fit a square health bar behind the artwork.

[syncrow]

Originally Posted by Folji Trying to set the point of a statusbar texture really doesn't seem to want to stick. No matter what, it always pops back to TOPLEFT the next moment. For now it'd definitely be way easier to just alter the shape of the frame to fit a square health bar behind the artwork.

you have to create a texture on top of the statusbar instead of using :SetStatusBarTexture()

[Folji]

Originally Posted by syncrow you have to create a texture on top of the statusbar instead of using :SetStatusBarTexture()

How so, exactly? I'm hunching that the way I've done it here is not quite how you mean with that, because this just seems to create a white texture frame underneath the bar.

lib.CreateHealth = function(frame,unit,width,height,point,x,y)
 
    local hp = CreateFrame('StatusBar', nil, frame)
    hp:SetSize(width,height)
    hp:SetPoint(point,frame,x,y)
    hp:SetFrameLevel(2)
 
    local bar = hp:CreateTexture(nil, 'ARTWORK')
    bar:SetAllPoints(hp)
    bar:SetTexture('Interface\\TargetingFrame\\UI-StatusBar')
 
    if (unit == 'target') then
        hp:SetReverseFill(true)
    end
 
    -- Register it with oUF
    frame.Health = hp
 
end

[syncrow]

use this instead:

lib.CreateHealth = function(frame,unit,width,height,point,x,y)
    local hp = CreateFrame('StatusBar', nil, frame)
    hp:SetSize(width,height)
    hp:SetPoint(point,frame,x,y)
    hp:SetFrameLevel(2)
 
    local bar = hp:CreateTexture(nil, 'ARTWORK')
    bar:SetSize(width,height)
    bar:SetTexture('Interface\\TargetingFrame\\UI-StatusBar')
 
    if (unit == 'target') then
        hp:SetReverseFill(true)
        bar:SetPoint("RIGHT")
    else
        bar:SetPoint("LEFT")
    end
 
    -- Register it with oUF
    frame.Health = hp
end

to mirror the texture for player and target you have to exchange 'left' value with the 'right' one

• player -> :SetTexCoord(left, right, top, bottom)
• target -> :SetTexCoord(right, left, top, bottom)

[Folji]

Oh, I see!

To be honest though, I wound up going way from trying to wrangle with statusbar textures in the end. What I've basically done now is an untextured statusbar and then a texture frame on top of it that essentially acts as the cover for the bar. Kind of a roundabout way of doing it, but I like the effect. Like the health and power bars are essentially contained behind a dirty glass cover, similarly to how they did it in Diablo 3. Might do a little surface glare over the portrait, too!

Just messing around with text tags right now. Thanks a lot for the help so far, feeling like I've got things figured way better than I did just a week ago, haha.