• 0

    posted a message on QuickHealth
    LQH might be somewhat time sensitive, but it's not a spacecraft. :> I'll profile it in ZA today, but I don't expect CBH to be a problem. And as far as I can tell from the code, one function is loadstring'ed, but only the first time it is used (the loadstring result is cached).

    Btw UNIT_HEALTH throttling is ~300ms, but that doesn't mean UH fires every 300ms. It just means UH doesn't fire more often than every 300ms. Also, damage is laggier than heals (don't ask me why). I see UH lag of 600-1000ms quite often. So even if CBH:Fire() would take 2ms per call (which it doesn't), it wouldn't matter.
    Posted in: General AddOns
  • 0

    posted a message on QuickHealth
    Well I can profile it tomorrow. If I bump the major version of CBH locally, LQH should get its own private CBH. Are you saying that CBH:Fire() is too slow?
    Posted in: General AddOns
  • 0

    posted a message on QuickHealth
    I added the new library to the SVN as LibQuickHealth-2.0. I'm probably going to add another event to the library which provides health updates for unitIDs instead of GUIDs. This should make it trivially easy to use the library in a unitframe addon.

    LibQuickHealth-2.0 is a library that provides more up to date health data than the default Blizz events and functions.
    In addition to the standard UNIT_HEALTH event, the library listens to combat log events (CLEU) to update health values. CLEU events fire more often than UNIT_HEALTH, and allow the library to get around the ~300ms throttling of UNIT_HEALTH updates.
    The interesting CLEU events are those containing health differences (damage and heals). Normally, when UNIT_HEALTH fires, those differences add up to the value reported by Blizz's UnitHealth. But sometimes, when a unit takes damage according to the CLEU, that damage is processed *after* the next UNIT_HEALTH event. This is called "pending damage". One of the features of LibQuickHealth-2.0 (and an improvement over 1.0) is to detect pending damage, and incorporate it into the health values that are presented to players.

    1.) Sometimes there are combat log entries like this: -6000 (damage), +5000 (heal). But what really happened on the server was that the heal occured first. If at least part of this heal was overheal, the prediction (-6000+5000 = -1000) is way off, because what happened is for example +50 heal first(4950 overheal), and then 6000 damage, for a total of +50-6000 = -5950. No AddOn could possibly prevent or predict this, but luckily these cases are very rare.
    However, if you see something like this happening (tank at ~100%, then takes damage instantly followed by a heal), you should know that this heal might have been overheal. So don't cancel your heal. ;)

    2.) If the maximum health changes, pending damage is completely ignored. Example: The tank is at 11001/18000, takes 9001 damage and uses Last Stand at the same time. Your client might tell you now that the tank health is 16401/23400 (+30% health and max health), because that 9k hit was not yet processed (pending damage). What the library does is: Show the tank at 11001/18000, then at 11001-9001 = 2000/18000, then at 16401/23400, because pending damage is ignored. But on the server, the tank has only 16401-9001 = 7400/23400 health!
    This looks very similar to the case before: The tank takes damage, but shortly afterwards that damage is (magically) undone. Again, if you see this, don't cancel your heal!

    3.) Bloodrush. There's no combat log entry for the health lost. I believe the health cost depends on the caster level and race, but I don't know the exact formula.

    4.) Exceptionally large HP5 values. There are no combat log entries for HP5 ticks, which occur every 2 seconds. The library assumes that the health regen in combat is between 0 and 50 HP5, i.e. HP5 ticks between 0 and 20.
    Common HP5 values: Demon skin/armor <=18 (24 talented?), Elixir of Major Fortitude 10, Enchant Boots - Vitality 4. Less common: Dreaming Glory 30 (buff from herbalism), and a few level 60 items.
    So the library might get confused by two things: Small amounts of pending damage (20 or less), and Warlocks with herbalism...

    To start listening to the event, do QuickHealth.RegisterCallback(YourAddonTableHere, "HealthUpdated", HandlerMethodHere);
    The callback triggers with 5 arguments: self, event, guid, health, healthMax (first two passed by the callbackhandler)
    Additionaly, QuickHealth:UnitHealth(unitID) can be called to get what QuickHealth thinks is the current health.

    local QuickHealth = LibStub("LibQuickHealth-2.0")
    local MyAddon = {}
    function MyAddon:Initialize()
    	-- Note: It's QuickHealth.RegisterCallback(), not QuickHealth:RegisterCallback().
    	QuickHealth.RegisterCallback(MyAddon, "HealthUpdated", "HealthUpdated")
    	-- Or:
    	-- QuickHealth.RegisterCallback(MyAddon, "HealthUpdated", MyAddon.HealthUpdated)
    function MyAddon:HealthUpdated(event, guid, health, healthMax)
    	if event == "HealthUpdated" then
    		ChatFrame1:AddMessage(format("%s HealthUpdated %i/%i", guid, health, healthMax))
    		if guid==UnitGUID("player") then
    Posted in: General AddOns
  • 0

    posted a message on QuickHealth
    The implementation is done so far, it's on http://code.google.com/p/wow-tifi. It works perfect now on my testing data for player (MT in a raid). But it still needs testing (and profiling) in a party or raid.
    I hope you're ok with a major version bump? LibQuickHealth-2.0 or LibQuickHealth-1.1?

    There's one thing I'm not sure about. When a unit frame addon uses the library, this addon needs to keep track of the GUID->unitIDs mapping. How about incorporating this into the library? The library could have two events, HealthUpdated(guid, ...) and UnitHealthUpdated(unitID, ...). Maintaining the GUID->unitIDs map would only be necessary if UnitHealthUpdated is registered.
    Posted in: General AddOns
  • 0

    posted a message on QuickHealth
    Ok this is just too awesome: I implemented a real-time replay feature for recorded logs. You'll be able to see both the value from Blizz's code (UnitHealth), and the predicted value (QuickHealth). If two events from the log are more than 2s apart, the gap is shortened to 2s, so it won't get too boring.

    Here's what you need to do to watch my health while tanking Azgalor from yesterday:
    1. Extract the file "YOURACCOUNTNAME\SavedVariables\QuickHealthTest.lua" to "WTF\Account\YOURACCOUNTNAME\SavedVariables\QuickHealthTest.lua".
    2. Extract the folders "QuickHealthTest" and "Ace3" to your AddOns directory. (Sorry, no embeds)
    3. When you start WoW, make sure you enable the addon. (disabled by default)
    3. In-game enter "/script qhtreplay(19,2644)". This tells the addon to load log #19, and start replaying at event #2644.
    4. Enjoy the demo of UnitHealth lags. Notice how well the addon predicts the health.
    5. Optional: Create a chat frame "QuickHealthTest" to see messages of what happens.
    6. To stop the replay enter "/script qhtstop()".

    Here's a little script I'm using in WoWLua, maybe you find it useful.
    local startreplay = 1
    if startreplay==1 then
      --qhtreplay(14) -- ??
      --qhtreplay(15,300) -- ZA?
      --qhtreplay(18) -- SH hero?
      --qhtreplay(19) -- azgalor trash
      --qhtreplay(19,1169) -- azgalor trash
      qhtreplay(19,2644) -- Azgalor mt
      --qhtreplay(20) -- archi shadow
      --qhtreplay(21) -- bt mother trash tank
      --qhtreplay(21,310) -- bt mother try 1 offtank
      --qhtreplay(21,720) -- bt mother try 2 offtank
      --qhtreplay(21,1231) -- bt mother kill offtank

    Quote from Nomad_Wanderer »


    What does that mean?
    Posted in: General AddOns
  • 0

    posted a message on QuickHealth
    I did some more tests, and enhanced my addon to gather UNIT_HEALTH and CLEU data (in raids), that I could use later for testing. I updated the addon accordingly, and I find it works very well now. Sometimes it still fails to predict the health correctly, but these cases are both very rare and not really important. Most of these special cases have to do with overheal, in other words the health is almost full anyways. You probably won't notice it.

    So here's the new version of the addon. It contains a mockup LibQuickHealth-2.0 implementation, and a small example addon using the new lib. Only the player's health/healthMax are tracked. The example addon displays two health bars, one for LQH2 values, one for UnitHealth. I'm pretty sure bumping the major version is appropriate, because listening to UNIT_HEALTH and UNIT_HEALTHMAX is discouraged now.

    Edit: Removed attachment, see below for the latest version. =)
    Posted in: General AddOns
  • 0

    posted a message on Undocumented COMBAT_LOG_EVENT arguments
    Could someone please explain the circumstances for powerType==-2 (health)? Couldn't find anything in my combat logs (ZA, BT, MH).
    Posted in: Lua Code Discussion
  • 0

    posted a message on OneHitWonder - Tank helper addon - Beta
    - Added bar which displays the time left until the player would die from melee attacks. The bar is only visible if the time left is less than x. This value can be changed with '/ohw time x'.
    - Instant update when the target's attack speed changes.
    - Bugfix: Don't interpret any miss as a parry, only parries...

    Quote from Astaldo »
    A real-time aspect to incoming damage analysis is a welcome addition.
    I'll keep an eye on it as it evolves :)

    Real-time, that's a buzzword I need to remember when I release it. ^^ Thanks.
    Posted in: General AddOns
  • 0

    posted a message on QuickHealth
    Ok I wrote a small addon for experiments. Not an elegant solution, possibly CPU intensive, but I it should be working.

    To understand what I'm doing take a look at the attached screen shot. The blue lines correspond to the HealthUpdated('player') events from LibQuickHealth-1.0. The green lines are UNIT_HEALTH('player') events. The addon listens to both, and tries to reconcile them (white lines). Every time HealthUpdated fires, the health difference is entered into a queue (in braces).

    At 0.455, UnitHealth returned 7417. However, this value doesn't contain the last health update (-165). At this time, LQH just uses the "wrong" value of 7417, until UNIT_HEALTH is fired the next time at 0.705. This results in one of those "jumps" Ironhand described earlier.
    The addon, however, looks at the queue, realizes that UnitHealth ignored the last value, and predicts a health value of 7252.

    Another interesting line is at 3.297. At this time, the values in the queue sum up to +272, but according to UnitHealth the health changed by +273. This is because I have a 4 HP5 enchant. In these cases, when there are health changes that cannot be explained from the combat log, the addon still uses the health updates from the queue, but tries to minimize the error. In other words it assumes that HP5 ticks are minimal.

    If you want to try it out, create a Chatframe called "QuickHealthTest" to see the debug messages. The addon requires Ace3 and LibQuickHealth-1.0 as stand-alone libs.


    Apparently I can insert an attached image. Is there some option do just display attached images automatically?

    Although most forums are likely be configured to display attached images as part of the post [...]
    Posted in: General AddOns
  • 0

    posted a message on QuickHealth
    Ironhand, I believe your explanation is correct. The problem is that there are two health values, one from QH, and one from UnitHealth(), but it's not obvious which one is "better". Just because UNIT_HEALTH fired doesn't mean UnitHealth() is exact.

    One suggestion I have is to use not only the current health from QH, but to also store the previous value. Then you could use the value from UnitHealth() only if it differs from both the current and the previous value.

    There's one more problem though: Not every health change can be explained by CLEU events. I'm talking about the HP5 ticks from buffs like Elixir of Major Fortitude or Demon Armor. Those HP5 ticks are not processed by QH, right? So in this case you'd just have to trust UnitHealth().
    Posted in: General AddOns
  • 0

    posted a message on OneHitWonder - Tank helper addon - Beta
    OneHitWonder is an addon that tries to predict how much longer you can survive without any heals. As a warrior MT, I wanted some help to decide when to use my oh-sh*t-buttons. Currently, the addon is of very little use for non-tanks.
    The GUI is not done yet. I'd like to add a bar that displays the time until the player dies, and have it pop up when there's less than 5s or so left.

    If you have feedback/bug reports/suggestions, please post them here. Keep in mind that this is a beta release, so don't hold me responsible for any wipes this might cause. :p

    Implemented features:
    - Records incoming raw melee damage.
    - Popup window displaying melee damage stats of your current target, given your current armor/stance/etc.
    - Countdown of how much longer you can survive consecutive hits w/o heals.
    - Parry mechanics and most Cleave spells.
    - Mob database browser, open with "/ohw mobs". Filter by name or level.
    - Localization independent.

    - Time left bar.
    - Player buffs: Shield Wall, Barkskin, Blessing of Sanctuary, Pain Suppression, ...
    - automatically inspect raid talents
    - discard hit when AP/AC change too close
    - dual wield -.-

    - Track damage on other players. (Not possible because their armor is unknown.)

    Big Wall of Text:
    The addon tracks min/max/avg raw melee damage. Whenever you take melee damage, the raw damage is "reverse engineered". For example when you're dealt 1000 physical damage, and you're a warrior in Defensive Stance, OneHitWonder would compute 1000/90% = 1111 damage. Let's say your armor reduces the damage by 60% vs the mob's level, then the raw damage would be 1111/(100%-60%) = 2777. So in this example, OneHitWonder would store a hit of 2777 raw damage. You can inspect a mob's raw damage in the mob DB browser (/ohw mobs).
    The addon also keeps track of AP modifying debuffs. As you can see from the attached screen shot, Anetheron hit me 7 times w/o any debuff, 17 times with an untalented CoW (-350 AP), 53 times with an untalented Demo Shout, and 15 times with Demo Shout+CoR.
    OHW uses two damage ranges. The first is just the [min, max] hits you received so far. The second estimates the variance, and deduces the range from both the variance and the average damage. You can think of it is an estimator that is more forgiving if - for whatever reason - errors occur while computing the raw damage.

    So, why is it a good idea to track the raw damage? Let's say you're tanking A'lar, phase 2. The damage you receive depends a lot on whether you have the armor debuff or not. Since the addon knows the raw damage, it can easily predict the damage you would take when you have the debuff.

    Currently, OHW estimates the time left as follows: It takes your current health, and assumes that from now on, you receive consecutive non-crushing hits (no misses/dodges/etc.). It further assumes that the one of those hits deals maximum damage, while the others deal average damage. All variables involved (your armor/stance, the target's debuffs/attack speed, etc) are assumed to remain constant.

    When someone in your raid applies a debuff like Demo Shout, the addon doesn't know whether that person has a talented Demo Shout or not. If you're courageous enough to try out OHW in a party/raid, use '/ohw scan' to start the talent scanner; the addon will inspect all Warriors, Druids and Warlocks, and use the gathered talent information in the current session. This information is not saved between sessions.

    I've yet to decide what to do about damage from spells.

    Some day I might add a way to send some information to healers, maybe as a Grid module.
    Posted in: General AddOns
  • 0

    posted a message on Event-driven notepad/reminder addon
    Quote from sylvanaar »


    actually, i'm glad i went and actually read the page, this looks cool

    While it might be an interesting subject, I don't think an FSM has any application here. The state space needs to be finite, and known in advance (at compile time).

    This notepad addon would just have to listen to certain events, evaluate conditions, and perform an action depending on the results. Brute force evaluation of all conditions would probably work well enough. But if you want to use a more advanced model, I suggest modeling the condition network as a DAG.
    Posted in: Addon Ideas
  • 0

    posted a message on VisualHeal - Official Thread
    The bar frames' position is reset when the addon was disabled. (Disable VH, reload, enable VH, reload -> Position is reset) This always happens when addons use the Blizzard code to save the frame position (IsUserPlaced). Could you please save the frame position in a SavedVar? Thanks.
    Posted in: General AddOns
  • 0

    posted a message on How much damage can I do w/o pulling aggro?
    Quote from Matrix110 »
    In the end the calculations are the same you have to do in your head

    Yea I know, it's just that computers are kind of better suited for calculations than my head...

    Quote from Matrix110 »
    Not to mention in the time you are doing that decission the Tank already built an additional 200Threat most likely :P

    Well I have to admit, that was funny. :D

    Anyway, since no one seems to care, I'm probably just gonna hack MyThreat for my spriest.
    Posted in: Addon Ideas
  • 0

    posted a message on How much damage can I do w/o pulling aggro?
    Omen's single target threat list is nice, but what DDs really need to know is how much damage they can do. To Mind Blast, or not to Mind Blast, that is the question. Probably even more important for Warlocks. So the interesting numbers are
    threat buffer = (tank threat)*130% - (my threat)
    damage buffer = (threat buffer)/(my current threat multipliers)

    What I'd like to see is just a numeric display of this "damage buffer". Most of the time, it would be more useful to me than Omen's threat list. I'm not sure exactly where to implement this. A stand alone addon? Or a new Omen module? A column in Omen's threat bars would be nice; especially for encounters where DDs have to stay below the second or third tank.

    And yes, I know this is not very general. Abilities with innate threat wouldn't be covered, or fancy stuff like the Prism of Inner Calm. However, most abilities of DDs don't have innate threat, most DDs don't wear that trinket, so providing a somewhat accurate estimate should be doable.
    Posted in: Addon Ideas
  • To post a comment, please or register a new account.