# Simulationcraft v530-7

Simcraft version 530-7 was released this week, and contains a bunch of bugfixes and updates.  You can download your copy here.  As usual, here’s a list of the major changes:

General

• 5.4 PTR now includes the new Vengeance formulas, including diminishing returns
• TMI calculation now normalizes against health on-the-fly to account for temporary health buffs (e.g. Last Stand)
• New “T16Q” boss to challenge well-geared tanks
• TMI bosses reclassified according to content type:
• T15H25 (translates to old T15H)
• T15N25 (translates to old T15N)
• T15H10 (translates to old T15N)
• T15N10 (translates to old T15LFR)
• Bosses have gained a new “melee_nuke” attack.  This is much like spell_nuke, but does physical damage and cannot be dodged, parried, or miss.  It can be blocked.
• Boss attacks now do variable damage rather than fixed damage
• Melee attacks default to a range of +/- 20% of the base damage
• spell_nuke and melee_nuke attacks default to a range of +/- 10% base damage
• the APL option “range” now lets you specify a custom damage range.  For example, if you wanted an auto attack that did 50k to 150k damage, you could use:
/auto_attack,damage=100000,range=50000
• Fluffy_Pillow has been re-calibrated to be much more melee-heavy. He still performs spell_nuke, but now also uses melee_nuke and uses both much less frequently.
• Ability reporting has changed slightly. When clicking on an ability to open up the detailed report, there will no longer be a separate “Block results” sub-table to summarize the results of the block roll.  Instead, attacks are broken down by their full type – i.e. miss, dodge, parry, hit, hit (blocked), hit (crit-blocked), crit, crit (blocked), crit (crit-blocked), and so on.
• Minor corrections to mitigation ordering (i.e. armor before block, shouldn’t have a noticeable effect for paladins, matters for warrior set bonuses).

• SotR no longer mitigates magical damage (oops?).
• Blocked attacks now do less damage than full hits (oops?).
• PTR changes updated to b17331
• T16H/N Protection profiles implemented
• T16H/N Retribution profiles implemented (but not optimized)
• Fixed an import bug for Retribution that was causing L90 talents to be ignored

Warrior

• Shield Barrier bugfix
• Lots of other changes that I haven’t been keeping careful notes on

As you can see, those are some pretty big bugfixes for paladins.  SotR was unintentionally mitigating magical damage, and blocking wasn’t always working quite correctly.  Together, these two should cause mastery’s value to jump around a bit (positive from the block change, negative from the SotR change).  I don’t think it will suddenly be a strong stat, but it may be able to keep up with dodge and parry now.

In addition, SimC should be fully up-to-date for the latest PTR, so we can do some testing to see how certain talents stack up to one another.  I’ve already done a little work with SS and EF over at maintankadin which I may write up as a blog post for next week.  I’m working on re-building all of my various MATLAB simulations as simc files, but now that the semester’s started things have gotten busy and I can’t guarantee I’ll have them done in time for 5.4’s release.

You may notice your TMI go up fairly significantly if you’re simming with “ptr=1″ enabled.  That’s to be expected, partly due to the SS nerf, partly due to the fact that you’re getting less Vengeance.  I don’t *think* there are any other bugs that could be causing TMI inflation, but as usual if you see something fishy don’t hesitate to post a comment so we can double-check it.

If you’re new to Simulationcraft, you may want to check out my Getting Started Guide.

This entry was posted in Simcraft, Tanking, Theck's Pounding Headaches and tagged , , , , , , , , , , . Bookmark the permalink.

### 45 Responses to Simulationcraft v530-7

1. Wrathblood says:

Thanks, Theck!

I was just fiddling with the new version of Simcraft, trying to model EF vs SS (I put in a command that made it prioritize recasting EF if there was less than 5 seconds left on the EF buff but otherwise use ShoR. Just using my current gear results weren’t terribly positive, but I don’t think I ever told it to hold off and wait for 3 HoPo before casting so that might have been the issue). While reading the results I noticed that dtps was a lot lower with SS while hps was only modestly higher with EF.

I could think of two possible explanations for this. First, is there an OH% built into EF, pushing down the EF casts and HoTs? Alternatively, are SS absorbs being both subtracted from dtps as well as added into hps?

If its #2, it presumably doesn’t affect the more detailed numbers but essentially double-counting SS absorbs might be confusing for someone looking at the top numbers.

• Theck says:

You might want to check out this thread regarding SS vs. EF:

There’s no OH% built into EF, so it should be essentially 0% overheal, barring incidental overheal that occurs during the first few seconds, i.e. if you cast EF on yourself but avoided the first melee. That incidental overheal could probably be eliminated with a simple health

• Wrathblood says:

Ok, thanks.

Indeed, its not exactly as though the absorbs are being double counted for TMI (at least, as far as I can tell), it just appears to be counted into two different, related but not the same metrics (dtps and hps) making SS appear stronger than it actually is. Feels like that would be confusing.

Separating HPS and APS would be a good step, but they’d still be confusing compared to DTPS.

• Theck says:

I’m sure it’s not being double-counted for TMI. An absorb isn’t stored in the code as a heal at all, so it doesn’t show up directly in the TMI calculations (it does indirectly, of course, since the damage registered will be smaller).

But the accounting for DTPS and HPS is done with slightly different bits of code, ironically enough, specifically so we *can* include absorbs in with HPS.

The problem is that, e.g., a Disc priest probably would want their absorbs included in their HPS, because they don’t get a DTPS value on their report (after all, they’re not tanking). Tanks are in the weird position that our self-absorbs affect two metrics we care about: DTPS and HPS.

I don’t think we’d want to mess with DTPS, because that value is still an accurate reflection of our DTPS. If anything, we might want to modify HPS to discriminate between “true” HPS and absorbs. Maybe something like:

DTPS: X HPS: Y (Z)

Where Z is the APS contribution within Y? Or perhaps Y is true HPS and Z is APS? Would love to hear suggestions on what would be clearest in this department.

• Wrathblood says:

IMO, splitting HPS and APS is fine, perhaps with APS displayed with DTPS instead of HPS to make it clear there isn’t double counting.

2. Çapncrunch says:

Nice, I do find it encouraging that there were bugs found (and corrected) affecting mastery’s performance. I still need to play a little with some setups to see for myself just how the sim is treating mastery now. In my initial sim on the new version, and comparing it to my sim on the 530-6 in the same gear I did see a significant jump in mastery’s value (from 0.30 to 0.56) though I also saw similar jumps in dodge and parry as well (from 0.28 and 0.27 to 0.47 and 0.51 respectively) as well as a jump for armor (from 0.37 to 0.63). Haste and strength also went up a little too, though not by as much (within what I would expect between one sim and another).

I would hope that after playing with some other setups that mastery will consistently stay above avoidance, and by a somewhat clearer margin than this first result, just as mastery was consistently ahead of avoidance in the MATLAB sims.

I do have 2 questions: First you mentioned a reclassification of TMI bosses, however I still only see “custom”, T16Q, T15H25, T15N25 and T15LFR, neither of the 10m versions are there. Was this just an unclear explanation in your post (it seems to imply that the 4 bulleted listings are the new settings and the parenthetic listings are just the old ones, but it appears the opposite seems to be the case. Second, you mentioned the addition of a melee_nuke ability added to the boss ability list, but I don’t see it in my results, the boss’s action list appears to just be auto_attack and spell_dot.

• Theck says:

In my quick testing on my character, I was getting mastery outperforming dodge/parry by a decent bit.

The 10m bosses are command-line options (i.e. tmi_boss=T15H10) but they’re no different from the 25-man bosses. The T15H10 boss is just the T15N25 boss, and likewise T15N10 is the T15LFR boss.

I added the melee_nuke ability to the code so that players can use it, but it’s not used by the TMI standard bosses (neither is spell_nuke). It’s just there so players who want to experiment with large predictable spikes can do so.

• Çapncrunch says:

I see. So how exactly would I go about adding these abilities to the boss’ action list, every time I do I keep getting errors regarding unexpected parameters, for example I tried putting the following on the Overrides tab (not sure where else to put it):

enemy=My_Boss
tmi_boss=T15H10
actions=auto_attack
actions+=/melee_nuke,first=20,cooldown=30,cast_time=2

At first I left out the first line, but the sim gave an error that it thought I was trying to add the abilities to my character’s action list. Now obviously my intent was to make the boss use melee_nuke 20 seconds into the fight and every 30 seconds after that, and to give it a 2 second cast time in order to be able to add a condition to use SotR for it. First the sim threw a red flag at the first= parameter (apparently I confused the raidevents options with the action list, though I would imagine there should be a way to prevent the boss from using his nukes immediately on the pull). So I removed that and just left the cooldown and cast_time settings, but the sim again threw a red flag at the cast_time parameter, which I don’t understand because the simC wiki uses this in the one and only example of changing boss abilities:

down in the simulationcraft as a tank section, though after doing a search this is apparently the ONLY time that “cast_time” is used anywhere in any of the wiki pages (did a search for it with “all wiki pages” and this page was the only result and this is the only place it appears on the page) so I don’t know if it’s an actual valid parameter or not or if it’s deprecated or what.

And without the ability to set a cast time on the ability it seems nearly useless because you can’t simulate the ability to plan for and react to these abilities the way we would do in reality.

Though if it is/was possible to give it a cast time would the following be the correct syntax to set SotR to react to it in my paladin’s action list:

actions+=/shield_of_the_righteous,if=(target.buff.casting.react)

I left out the other conditions to increase readability, I would of course add back in the 5hp condition, as well as the divine purpose, though I’m not sure if the shifting que condition would conflict with trying to “save” sotr for the nuke or not. Though is that the correct syntax, to use target.buff to access the boss’s buff list instead of my character’s?

• Theck says:

I think that “cast_time” is deprecated. If you run a quick test sim with Fluffy Pillow, you’ll see the correct syntax for all four potential boss abilities:

enemy=”Fluffy_Pillow”
level=93
race=humanoid
role=tank
position=front
spec=unknown

actions.precombat=snapshot_stats

actions=auto_attack,damage=700000,attack_speed=2,aoe_tanks=1
actions+=/spell_dot,damage=50000,tick_time=2,num_ticks=10,cooldown=40,aoe_tanks=1,if=!ticking
actions+=/spell_nuke,damage=500000,cooldown=35,attack_speed=3,aoe_tanks=1
actions+=/melee_nuke,damage=1000000,cooldown=27,attack_speed=3,aoe_tanks=1

attack_speed is your cast_time equivalent. I’m not sure offhand if there’s an equivalent for the “first” option; if not that shouldn’t be too hard to implement in a future version.

I don’t think you can define a TMI boss and just append a melee_nuke to actions, you’ll have to write out each ability individually. In other words:

enemy=”TMI_Standard_Boss_T15H25″
level=93
race=humanoid
role=tank
position=front
spec=unknown

actions.precombat=snapshot_stats

actions=auto_attack,damage=900000,attack_speed=1.5
actions+=/spell_dot,damage=30000,tick_time=2,num_ticks=15,aoe_tanks=1,if=!ticking
actions+=/melee_nuke,damage=1000000,cooldown=27,attack_speed=3,aoe_tanks=1

Your SotR syntax looks right to me, but be aware that “buff.casting.react” will be true for both spell_dot and melee_nuke (and spell_nuke if it’s on the APL). If you want to be able to intelligently use SotR only for melee_nukes, you’d want to set attack_speed=0 for spell_dot.

• Çapncrunch says:

Ok, so attack_speed instead of cast_time and I’d need to completely define all of the boss’ information as well as all the details of its attacks (damage sizes, etc). I don’t see a particular problem with making the spell_dot instant cast, bosses don’t typically have cast times on those types of abilities anyways (they don’t always have cast times on their nukes too, but we typically have dbm or something else as a prewarning that we’d react to the same as we’d react to a castbar). Though I don’t suppose there’s a way to check which ability the boss is casting so that the action priority list would be able to differentiate them (can’t think of a reason that this would be necessary that couldn’t be fixed by making all but one ability attack_speed=0, but seems like an unusual limitation, like it’d be a property stored in the “casting” buff).

I do have 2 final questions, first what exactly does the aoe_tanks parameter do (again from what I can find it’s only shows up in that same entry as cast_time and nowhere else) I had assumed it was used to set the ability to be aoe rather than targetted so that it would affect all characters in the sim instead of just the tank, but your use of it along with the melee_nuke seems to imply I was wrong.

Second, is there a place that’s better than others to put all this stuff? Such as the Overrides tab, or should there be a separate profile in the simulate tab? Part of why I ask is that in 530-7 the overrides tab seems to erase itself every time I close simc, whereas in 530-6 the contents stayed there as long as I ran a sim after adding something.

• Çapncrunch says:

Ok, so this morning I decided to start messing with this. First thing is I found 2 problems with your advice: first is that the “spec=unknown” threw up an error that actually crashed simc on me, said that it was an invalid value for “spec”. I was able to resolve this by simply removing that line. Second was I tried adding attack_speed=0 to the spell_dot options but again I got errors claiming that it was an “unexpected parameter” for that ability. So I ran the sim without that (I just used the ability list you gave as a sample, so just auto_attack, spell_dot and melee_nuke) and given the weight that mastery wound up with it seemed to be fine (so either spell_dot was already being treated as instant, or I was lucky enough not to have it catch many of the SotRs that were meant for the melee_nuke).

Oh, also I found that when adding a custom boss you want to set the TMI Standard Boss option on the options tab to “custom”, my first (non-crashing) sim gave me really really disturbing results as well as had both bosses present (by “really really disturbing” these were some of the weights I received: haste -0.29, mastery 0.05, parry 1.0, strength -54.16, the sim was only done with 500 iterations so I assume that with 2 heroic caliber bosses beating on me 1000 extra of any stat had virtually no impact on the results so I basically got nothing but statistical noise).

Once I removed the extra boss I got much more normal results. Though again only did 500 iterations so mostly just noise noise noise. Gonna run one with a more respectable number of iterations and see how things shake out.

• Theck says:

Yeah, looking at it again I think spell_dot is automatically instant-cast, so the simple SotR syntax should work. For some reason I thought it had a cast time.

You’d definitely want to set the TMI Boss to “custom” for this, otherwise you’ll be juggling multiple bosses. That drop-down is a hack-y workaround so that people don’t have to mess with action priority lists, so it just force-spawns a TMI boss in addition to any other bosses or adds you specify in the Simulate tab. When set to “custom,” it will spawn a Fluffy_Pillow if the user doesn’t specify any other bosses or adds. Not super intuitive, but necessary as a work-around for now due to the way the GUI communicates with the rest of the text-based stuff.

The “overrides” tab is new, and I haven’t used it much yet. I’d suggest just adding the boss on the Simulate tab, since that always persists between runs (and opening/closing the application).

aoe_tanks just forces that ability to hit all tanks in the sim. It doesn’t split damage, so each tank takes the full amount of the attack. It’s just there so that you can simulate two tanks side-by-side for comparison against the same boss (i.e. for the raid sims).

• Çapncrunch says:

Yeah, with what you gave me yesterday I was able to get it mostly working after a little trial and error (it didn’t take much to notice there were 2 bosses in the results tab and that “custom” was the appropriate setting for defining a custom boss :P)

And I did run some decent iteration sims (thought I posted about them, apparently not?). Did a 15k iteration sim using the casting.react condition but not the incoming_damage condition since I wasn’t sure how they would get along. The results seemed pretty much what would be expected: mastery was in a clear 2nd place behind haste (haste was 0.89 and mastery was 0.61, while the avoidance stats were sporting 0.42 and 0.06). My TMI was higher than I expected (~116k), but I’m pretty sure that it’s because I was using 25H damage numbers while my tank is only 531 geared (so I’d already be undergearing the standard 25H boss), and the addition of the melee_nuke essentially more damage on top of what the standard tmi boss would do (since casting melee_nuke every 30 seconds wouldn’t interfere much with the boss’ autoattacks or dot ticks), and melee_nuke was about 26% of my damage taken so that’s basically 20% additional damage and that would obviously have a negative impact on TMI.

The odd thing was after that sim I decided to see how the casting.react condition would get along with the incoming_damage condition, so I did a 10k iteration sim with both on, and while my TMI dropped by over half to about 58k, mastery’s weight PLUMMETED to -0.80 which doesn’t exactly make sense. When I looked at things like dtps, boss dps, damage composition, health timeline and health change timelines they were nearly identical between the 2 sims, yet somehow the first was deemed twice as spiky as the second (in terms of tmi) and adding 1000 mastery to the first improved performance while adding 1000 mastery to the second reduced performance. Needless to say I find/found it odd.

• Theck says:

My guess is that you made some error, as mastery’s value should never be negative. Or who knows, maybe you’ve found a new break point. If you share the results, I’ll try and verify.

With only 10k iterations, you’re probably getting really large error bars on those results as well, so be careful how much faith you put in them. Note also that if you’re running on a multi-core system, you can increase the number of threads the sim uses on the Global Options page. Bumping it up from 1 to 4 or 8 will have a large effect on runtime.

• Çapncrunch says:

Yeah, I’ve been typically running 10k~15k iterations because I only have a dual-core processor. I’m trying it again with both conditions on at 20k iterations, though to increase time I’m only calculating scale factors for stam, haste and mastery. Afterwards I’ll try to share what results I get.

• Çapncrunch says:

Ok, I just finished my 20k iteration sim, and this time again all the other data (tmi, dtps, boss dps, damage distribution, sotr uptime, health/healthchange timelines) look the same/similar to my previous odd result using both SotR conditions, but this time I got a normal mastery weight of 0.54, and haste was up at 1.31 (again I only simmed haste mastery and stam). So I guess my earlier very negative results for mastery were just an unlikely case of statistical error/noise even at 10k.

Also, I’m getting consistently large error bars, and I believe I know why, it’s my massive TMI values that I’m getting by adding the melee_nuke on top of the boss’ regular damage. Larger TMI means spikier performance which means a larger potential range of results. For example, even though I didn’t save the results, how I said I accidentally did a sim with 2 bosses up, and most of my stat weights came up negative, because the combined boss damage was enough to render my stats irrelevant and drowning my results in rng noise. From looking at some of my saved reports, the error range definitely seems to support this, the reports with small tmi values always have small error ranges and ones with larger than normal tmi tend to have larger error ranges. So I guess as TMI scales exponentially it probably requires an exponential number of iterations to hammer the error range down to more comfortable levels.

Right now I’m in the process of repeating this 20k iteration sim with both “smart” SotR conditions separate as well as together to compare the results. After I’ll change to some more gear-appropriate damage levels and confirm that that’ll reduce the error more efficiently than trying to run a 200k iteration sim 😛

3. Thiron says:

I was wondering – does Simcraft handle effective mastery snapshots for SoTR that extends duration? Haven’t seen info on this.

• Theck says:

Yes, it does. SotR’s value isn’t recalculated when the buff duration is extended.

4. Thiron says:

Hm, weird.
When I looked at DTPS scaling, stamina was on top. TMI I get, but how does stamina affect DTPS? I don’t have set bonus.

Also, what should I sim for T16N10? Is T15N25 close enough, or should I go with T15H25?

• Theck says:

The DTPS plots and stat weights use a similar normalization technique to the TMI calculation. Essentially, the stamina weight is generated by comparing DTPS normalized to health (i.e. 10k DTPS with 20k health is 50%) to the same result after adding 1000 stamina. I think it’s a little misleading, but that’s how they’ve done it in SimC for years, and it’s arguably a reasonable way to compare stamina to the other stats for a metric it has identically zero impact on.

Since I don’t know how hard T16 bosses hit yet, it’s hard to say. T15N25 seems like a fair guess, though probably a slight underestimate. T15H25 is probably an over-estimate, though.

5. Bearsack says:

My new TMI for the T16Q boss on the PTR setting is 669.5k, that can’t be right can it? With the Live setting I’m sitting at 3k which seems like a perfectly accurate number. http://us.battle.net/wow/en/character/kalecgos/Bearsack/advanced

6. Schroom says:

same here Live I’m on 100TMI vs T15H – 25 and >200k vs T16Q I don’t know what T16Q does exactly but it seems unreal.

7. Tseng says:

Remember that TMI is on an exponential scale, so differences of 10k vs 100k vs 1m are not as extreme as they look.

Using the latest source build with my warrior (lvl 550, avoidance geared for 5.4) I get a TMI of 171k with live mechanics and 30k with PTR mechanics against T16Q – seems reasonable since the buffed rage income will allow way more Sblocks and also some more occasional barriers.

8. Qaajn says:

You may or may not remember me from a bit earlier this year. Anyhow, taking a second look at SimC from a Blood perspective again too see how it looks. Perhaps this isn’t the best place to ask questions about simming my DK, but I’ll try to keep my questions quite general in their nature.

Simming my Character: http://eu.battle.net/wow/en/character/defias-brotherhood/Arrak/simple
Avarage item level 525 (got legendary meta)

For a LFR boss I get 460 TMI, which seems at a reasonable range. The T1525N however gives almost 22k TMI.. This sounds a bit high to me, so I wonder how this compare to the other classes. The minimum show as 562 TMI and the maximum TMI show at 311k and a range of 56k (!).

But what’s more interesting, for both of the situations, I get more HPS then DTPS, yet my health timeline end up at -15M for 25N and -7.8M for LFR. This is with the health change timeline avaraging to 30k and 18k respectively. For 25N my personal HPS is 100k with DTPS at 85k and LFR have 78k HPS and 64k DTPS. What’s going on here…?

• Qaajn says:

This is with external healing turned on. Will try one with it turned of after my stat plot simulation is complete.

• Qaajn says:

There are also something very interesting happening with my health at periodic times, estimating them to about every 100 seconds, and I’m not sure what it is. Sorry for the fat link:

• Qaajn says:

Woo spam, link doesn’t seem to work… You can find it in the sim anyhow.

• Theck says:

Is it a spike or a dip? It’s probably correlated to a major 90-second cooldown. Or perhaps more than one, all being used simultaneously.

• Qaajn says:

Well, it gets “lower”, moving from ~30k avarage down to negative values. Though when I think about it, perhaps a negative health change would signify gaining health? If so it makes sense, and it’s probably connected to Dancing Rune Weapon which have a 90 sec cooldown. If negative health change does mean that you lose health, then I have no idea what it is. Here should be a working link:

• Theck says:

Yeah, that “health changes” timeline is essentially a (DTPS-HPS) timeline. If that goes negative, it means you’re HPS is exceeding DTPS. Same sort of thing happens with paladins and Holy Avenger in 120-second intervals.

• Qaajn says:

That makes much more sense then, thanks

• Qaajn says:

I know we were through this in another reply with the absorb deal… But my displayed DTPS were lower then my HPS for the fight. That should then give a negative health change. It does not however, and what we learned from absorbs doubledipping the meters it shouldn’t. The thing is, the Health Change plot seem to be made in another way then DTPS-HPS. I don’t remember exactly how you simulated absorbs, but either having them as damage reduction and not include them in the at all for the healing done calculation in the plot, or counting them as healing but receiving full damage would give the correct results. What puzzles me is that this somehow isn’t consistent with the (later?) DTPS/HPS calculations, where it occur in both rather then only one.

• Theck says:

Think of it this way:
Every time you take damage, SimC records how much damage was taken (literally taken, meaning after absorbs are subtracted out). It also stores the amount absorbed in a separate variable.
Every time you receive healing, SimC records the healing taken.

The health_changes timeline is generated from the damage and healing results – thus absorbs aren’t being double-counted in the health_changes timeline.

The only place they’re being double-counted is the aggregate values on the first line of the report, because the absorbs are being added back in to the HPS value.

• Qaajn says:

That’s quite interesting. I did not expect absorbs to be ignored there. As a DK, that sounds like a quite flawed way to display your health changes. Our self absorbs are often in the region of 25% of the total “healing” we take from all sources.

• Theck says:

I think you misunderstood. They are not being ignored.

• Qaajn says:

Yes, I had just woken up and had a logic fail in my brain. I even mentioned that option in my earlier post: ” having them as damage reduction and not include them in the at all for the healing done calculation in the plot”.

Adding absorbs to healing done for the HPS display does however give you the funky results of DTPS and HPS being inconsistent with what occurs, as the damage taken is already “corrected” for the HPS. It should be simple to just add the absorbs back to DTPS. Does give some extra unnecessary calculations in the code, but only require that change.

It should be easier never subtracting out absorbs from damage taken in the first place, and add them to healing done from the start. It would also be consistent with WoL.

• Theck says:

For live, it’s roughly calibrated such that a paladin in boss-appropriate gear should get a value between 1k and 10k. So for example, a 522-ilvl paladin against the T1525N boss should be in the ~4-5k range, though obviously talent choices, rotation tweaks, etc. can cause a lot of variation there.

DKs are a little spikier by nature, so it doesn’t surprise me that you’re getting values of 22k against the T15N25 boss. That seems reasonable, and there might be some tweaks you can make to the APL to bring it lower (like chaining cooldowns together, if the module doesn’t already do that).

As to the HPS/DTPS question, it’s probably a matter of fuzzy accounting. When SimC adds up your HPS totals for the HTML report, it includes absorption effects (because, for example, if a Disc Priest is simming themselves, they’d want those included in HPS). But for tanks that makes the results a little odd, because those absorbs obviously decrease DTPS. In the future, I’m hoping to split out the absorption numbers from HPS to make that a little clearer.

• Qaajn says:

Thanks for the reply! Yes, I figured it might be something like that after reading the “EF & You?” post. Perhaps it would make sense to not have absorb reduce the DTPS, if that is possible? Mainly because I’d personally would like my Blood Shield to show up on HPS too. And absorption doesn’t reduce the damage you take, in a sense, though it negate the healthbar from moving.

• Qaajn says:

In a sense, absorbing is just pooling up more health. Only absorbing physical/magical makes the concept feel odd, but that’s pretty much what it does still.

• Theck says:

On the other hand, utilities like WoL report DTPS after absorbs, so the way we’re doing it now syncs up better with WoL reports (and what your healers see).

• Qaajn says:

WoL includes absorbs in healing done. And if you compare the damage taken with healing taken, they are very similar too. For example, on my last Twin Consorts kill I had 50.8k Healing Taken (36% of which was my blood shield) and 50k DTPS. I’m not sure how I can have more HT then DTPS, might have something to do with using Vampiric Blood at low health and temporary increasing health that gets healed, and if you then have higher health when it fades, you get can get “healed” more damage then you take. I suppose…

Anyhow, the DTPS and HT should be very close if you do not die and end the fight with full health. Basically, the damage taken must also include what’s absorbed, or things would start to look very weird very fast.

• Theck says:

I wasn’t sure, so I tested it. It turns out, World of Logs completely fucks up absorbs.

http://www.worldoflogs.com/reports/gdsgozwxvetwgotk/log/

It’s clear from the log browser that all damage I took was absorbed:
[19:06:20.036] White Crane hits Theck Absorb (2950)
[19:06:22.070] White Crane hits Theck Absorb (2848)
[19:06:24.096] White Crane hits Theck Absorb (952)
[19:06:25.863] White Crane Crane’s Song Theck Absorb (1514)
[19:06:26.784] White Crane Crane’s Song Theck Absorb (2525)
[19:06:27.854] White Crane Crane’s Song Theck Absorb (3441)

Yet if you go to the individual breakdown, it shows up as 3 hits and 3 absorbs for each ability.
http://www.worldoflogs.com/reports/gdsgozwxvetwgotk/details/0/

If you look at the Damage Taken rankings, it shows up as around 400 damage taken per second rather than zero (higher if you zoom in to the part where the crane was alive). However all of the data points on the plot are identically zero.

So I’m not sure what makes more sense. It makes more sense to *me* if DTPS doesn’t include absorbs, because you don’t actually “take” absorbed damage, so it stands to reason that it shouldn’t be included in “damage taken per second.” But I may just be a literalist.

• Qaajn says:

I know what you mean… But if you do want to contribute absorbs to healers you get odd results if you don’t count absorbs in damage taken. Take this quick example:

You’re at full 600/900k health with a 300k shield. You take a 300k hit and consume the shield.

The log would show 300k healing taken, and you end up with the same health as before the hit. If you displayed it as 0 damage taken, then you would now appear to be at full health, which would be very odd and makes you essentially to “take” double the absorbed amount before being in the same situation again.

Let’s continue the example: After the 300k hit you are hit twice again for 300k each, and die. If we include a previous 300k hit before the absorb too, we would have this:

WoL show 300k healing taken and 1200k damage taken. As your health is only 900k, you end up dead.

The other way would still show 300k healing taken but only 900k damage taken. Logically this would put you at 300k health and still live.

I can’t think of another way where you could take damage during a fight, some of it getting absorbed, and if ending at 100% health would give you the same damage and healing taken.

Maybe it would make more sense to call it “damage soaked” rather then “damage taken”. I try to think of it as a temporary health boost. It kind of works conceptually with damage taken then…

• Theck says:

The log does not show 300k healing taken when you consume a 300k absorb. It shows 0 damage taken with (A:300k) appended to it.

There’s no confusion as to what happens in the sim. It’s just that in post-processing we add all of the absorbed damage events to the number we display as “HPS.”

There are a number of ways to make that clearer, it’s just a question of which one makes the most sense. Something like “DTPS:X (APS:Y) HPS:Z” would probably be enough, and wouldn’t affect healer results.

9. Qaajn says:

Yes, I know that the log just show how much damage is absorbed, just as the combatlog does ingame. I would guess that the mod does account for the “healing” added to healing done from the absorb as the hit takes place however. This makes sense as putting on an absorb that fades before being fully consumed is (partly) wasted, so accounting for the virtual “healing” at the application would sometimes not give the correct results.

Maybe it’s only to me, but it’s confusing when you take more healing then damage, yet end up losing health. I do think it would be easiest to have SimC show damage taken in the same way as WoL, that is, with the absorbed amount added. It would make it easier to look at the results, even if for some situations it’s useful to know how much of the total damage taken are covered by absorbs.

Perhaps I overly complicate what I’m trying to say, but to me it makes sense to not think of absorbs as heals or “avoidance” (no damage taken) but as virtual health. Your current and maximum health simply increases by the shield size rather then healing you. Both of those are then reduced again as you take damage. To me this way of thinking move me away from the thought of not taking any damage. This really have no practical use other then being a philosophy that make me better able to consider the interactions that take place.

Once again I use too many words for trivial things… 😛