1. May 16, 2016  

    Health Bar Addon

    im looking to get a 2nd healthbar, like in the provided picture. plocks help :D

    http://s11.postimg.org/im532wi0z/image.jpg

  2. May 16, 2016  
    If you don't need the health bar to be click-able, you could just create a healthbar with WeakAuras.

    If you want the healthbar to be an actual UnitFrame, you'll need an UnitFrame AddOn like PitBull, ShadowedUF, AgUF or StUF.

  3. May 17, 2016  
    Doesnt really need full addon for extremely simple healthbar

    Code:
    local unit = "player" 
    CustomHealthBar=CreateFrame("Statusbar",nil,UIParent)
    local f =CustomHealthBar
    f.unit = unit
    f:SetMinMaxValues(0,100)
    f:SetPoint("CENTER",0,0)
    f:SetSize(150,20)
    f:Show()
    f:SetValue(100)
    f:SetStatusBarColor(0.3, 0.4,0.4)
    f:SetStatusBarTexture("Interface\\TARGETINGFRAME\\UI-StatusBar")
    f:SetScript("OnUpdate",function(self) self:SetValue(UnitHealth(self.unit)/UnitHealthMax(self.unit)*100) end)
    Adding border and text isnt very hard to do either. It's graphic options that usually make addons large.
    Edited: May 17, 2016

  4. May 17, 2016  
    Doesnt really need full addon for extremely simple healthbar
    The most basic difference is that creating the bar in WA doesn't require any LUA knowledge.

    The default statusbar can only handle left to right growth whereas the WA statusbar can grow in all 4 main directions.
    .

    And on a technical note:

    - You don't need to define the unit locally if you only use it once ;)

    - instead of creating a global (CustomHealthFrame) first and then add it locally, do it directly:
    Code:
    local f = CreateFrame("Statusbar","CustomHealthBar",UIParent)
    (or leave the second argument empty if the frame shouldn't have a name (which clutters the global space))

    - the most important thing:
    don't ever use OnUpdate like that!!!
    Either implement the correct event handling or use a delay.
    We don't want the statusbar updated on every CPU cycle.
    Edited: May 17, 2016

  5. May 17, 2016  
    Like houm said, don't use "OnUpdate" for this case. There are events for a reason.

    The event "UNIT_HEALTH" triggers everytime a unit's hp changes (units are "target", "player", "pet", "party2", etc).
    So, using your example:
    Code:
    ...
    f:SetScript("OnEvent", function(self, unit)
        if(unit == "player") then
            self:SetValue(UnitHealth(self.unit)/UnitHealthMax(self.unit)*100);
        end
    end);
    f:RegisterEvent("UNIT_HEALTH");
    If you want the frame to be clickable (i.e. whenever you click it, you target yourself), you need to use SecureTemplates.

  6. May 17, 2016  
    I usually handle most things with OnUpdate script because it doesn't affect my fps in any kind of way so I just don't really care.

    Otherwise you are right, events should be used if possible.

    Unitframes will almost always be in global namespace, because Secure Frames require using name (they won't work if you leave that parameter nil, or just cause weird issues). SIde note, you have to name the frame in second parameter even if you make it into global.

    I actually use unitframe addon I made myself, it's little bit crude but works perfectly fine. It's simple enough to be ported in any expansion also.

  7. May 17, 2016  
    I usually handle most things with OnUpdate script because it doesn't affect my fps in any kind of way so I just don't really care.
    Bad coding is bad coding ;)
    You won't carry 50kg of BS in your car around just because it doesn't really affect your driving ;)

    Unitframes will almost always be in global namespace, because Secure Frames require using name (they won't work if you leave that parameter nil, or just cause weird issues).
    UnitFrames don't require a name nor does any other frame type.
    They work just fine without it. Just won't be able to be targeted by the /click macro command.

    SIde note, you have to name the frame in second parameter even if you make it into global.
    ???
    I don't understand that sentence.

    You can either name a frame directly via the 2nd argument in the CreateFrame function (which is required for frames to be interactable by the /click macro command) or refere to a frame with a global (or local) variable (as you did in your code).
    But since that gVar isn't regarded as secure, it would not fully work with any SecureFrame (and easily causes taint).
    If the 2nd argument is a valid string, it is automatically added to the global name space (_G).
    Edited: May 17, 2016

  8. May 17, 2016  
    I usually handle most things with OnUpdate script because it doesn't affect my fps in any kind of way so I just don't really care.
    You will always lose fps if you start doing heavy stuff inside an "OnUpdate" script. That's why the more addons you have (TidyPlates, Bartender, Quartz, DBM, Grid, MSBT, etc), the more CPU-time will be wasted to process a frame, which means less frames per second.

    Usually, nameplates addons are one of the biggest fps-killers. Here is a test with an handful of them: https://youtu.be/KsJmeYUKyBg?t=33s

    If you leave a frame with "OnUpdate" running forever, make sure you throttle down the refresh rate, for example: instead of refreshing every frame (which 90% of the times is useless), refresh every 0.05 seconds. With this, your addon will cost 4x less if you are running at 60fps - and in the end the result will be practically the same.


    Also, when providing code or creating addons, don't think that everyone has a super-pc with 12cores, each one running at 4GHz, 2x Nvidia 980GTX, etc...

    So, to finish, even with the current time (i.e. PCs getting faster and faster every day), it's always better to choose something that is more cpu-friendly than something that is taking too much resources without the necessity to do so.

  9. May 17, 2016  
    Usually, nameplates addons are one of the biggest fps-killers. Here is a test with an handful of them: https://youtu.be/KsJmeYUKyBg?t=33s
    Fun fact:
    Anchoring the visuals to the specific nameplate actually costs more fps than updating their position via OnUpdate while they are hidden.

    Just having many objects on-screen causes a noticeable dip in the frame rate, but attempting to move the frame they are attached to practically freezes the game.
    (easily reproducible with bag addons)

    On nameplate fps:
    http://www.wowinterface.com/forums/s...ad.php?t=46740
    Especially:
    http://www.wowinterface.com/forums/s...49&postcount=6
    Edited: May 17, 2016

  10. May 18, 2016  
    Fun fact:
    Anchoring the visuals to the specific nameplate actually costs more fps than updating their position via OnUpdate while they are hidden.

    Just having many objects on-screen causes a noticeable dip in the frame rate, but attempting to move the frame they are attached to practically freezes the game.
    (easily reproducible with bag addons)

    On nameplate fps:
    http://www.wowinterface.com/forums/s...ad.php?t=46740
    Especially:
    http://www.wowinterface.com/forums/s...49&postcount=6
    So, I read the whole topic. Even though it was for 5.4, I decided to test this method in Cataclysm (4.3).
    Started with this snippet: http://www.wowinterface.com/forums/s...48&postcount=5, which was cool, hiding the frame before moving it didn't affect so drastically the fps.

    Then I downloaded the latest version of Zork's nameplates (rNameplates) which contains that trick and backported to Cataclysm.

    Unfortunately, I didn't got any increase of fps from his older version, rDiabloPlates2 (which was created in Cataclysm before implementing those changes).

    Then I tested this code-snippet: http://www.wowinterface.com/forums/s...4&postcount=17, and here I got a better performance, not better than Blizzard's nameplates, like the topic suggests, but very close (just a couple of FPS drops). But I guess the reason that isn't dropping too much fps is due to the fact that is super simple, i.e. it's just a basic StatusBar with a texture behind: http://i.imgur.com/nDUU4jx.jpg.

    So, I think this only affects in MoP's last patch and beyond.

  11. May 18, 2016  
    So, I read the whole topic. Even though it was for 5.4, I decided to test this method in Cataclysm (4.3).
    Started with this snippet: http://www.wowinterface.com/forums/s...48&postcount=5, which was cool, hiding the frame before moving it didn't affect so drastically the fps.

    Then I downloaded the latest version of Zork's nameplates (rNameplates) which contains that trick and backported to Cataclysm.

    Unfortunately, I didn't got any increase of fps from his older version, rDiabloPlates2 (which was created in Cataclysm before implementing those changes).

    Then I tested this code-snippet: http://www.wowinterface.com/forums/s...4&postcount=17, and here I got a better performance, not better than Blizzard's nameplates, like the topic suggests, but very close (just a couple of FPS drops). But I guess the reason that isn't dropping too much fps is due to the fact that is super simple, i.e. it's just a basic StatusBar with a texture behind: http://i.imgur.com/nDUU4jx.jpg.

    So, I think this only affects in MoP's last patch and beyond.
    The big difference is because of the GFX engine changes of Cata and MoP.

    WotLK is mainly about the amount of frames drawn (which also take a lot less power to be drawn than in Cata/MoP).
    They don't have as much of an impact in fps as in later builds but it is reproducible and noticable.

    Also take into consideration that most of the PCs are much stronger now than the original hardware during retail WotLK.

    btw: We moved quite far and deep from the actual topic ;)
    Edited: May 18, 2016

  12. May 18, 2016  
    btw: We moved quite far and deep from the actual topic ;)
    I guess so, but I don't think the OP is very interested because we haven't seen any answer from him/her yet.

    Anyway, to the topic: this depends on the addOns, most UnitFrames (e.g. ShadowUnitFrames) allows you to enable Blizzard's PlayerFrame, having 2 PlayerFrames in your screen. You can also do the other way around. Disable most addOn's features and just choose to show the addOn's PlayerFrame.

  13. May 20, 2016  
    Doesnt really need full addon for extremely simple healthbar

    Code:
    local unit = "player" 
    CustomHealthBar=CreateFrame("Statusbar",nil,UIParent)
    local f =CustomHealthBar
    f.unit = unit
    f:SetMinMaxValues(0,100)
    f:SetPoint("CENTER",0,0)
    f:SetSize(150,20)
    f:Show()
    f:SetValue(100)
    f:SetStatusBarColor(0.3, 0.4,0.4)
    f:SetStatusBarTexture("Interface\\TARGETINGFRAME\\UI-StatusBar")
    f:SetScript("OnUpdate",function(self) self:SetValue(UnitHealth(self.unit)/UnitHealthMax(self.unit)*100) end)
    Adding border and text isnt very hard to do either. It's graphic options that usually make addons large.
    How do I make this just for the Powerbar?(runic power bar)

  14. May 20, 2016  

  15. May 20, 2016  
    http://pastebin.com/StMXKkyL

    Contains code for creating statusbars, for both health or power. Didn't add arena support, but I'm sure if someone wants to he can add it easily.

    http://imgur.com/WyjOcsW

    Frames can be dragged via shift click. Dragging is enabled by double click on the frame.

    statusbar.classcolor = true

    to add classcolor for healthbars

    Examples to create bars like in screenshot are included in code. If you name the statusbar, blizzard UI remembers the spot without having to use savedvariables manually too.

    Might have few bugs but I'm not too interested in maintaining this one. Should get anyone started who wants to create full Unitframe addon with full click support etc.

12 Last

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •