dipstik Posted April 11, 2015 Share Posted April 11, 2015 it takes frequency (probability) and strength (squish) into account. for commanders, for shadow. decreasing defense, shield and absorb by 100 points increases spike by the following amounts: a base spike: 0.022021301 -100 shield spike 0.022244571 -100 absorb spike: 0.022120985 -100 defense spike: 0.02208923 spike difference for 100 shield : 0.000223271 spike difference for 100 absorb : 9.96843E-05 spike difference for 100 defense: 6.7929E-05 Link to comment Share on other sites More sharing options...
KeyboardNinja Posted April 11, 2015 Share Posted April 11, 2015 spike= sum(probability[ij]*(squish[ij] - squish)^2) where i runs over kw_named, kw_bland, kf and ef (i thought there was ew damage, but i guess not) and j runs over defended, resisted, shielded and full hit. (see my thread for variables) Wouldn't the following make spike slightly more useful? spike= sum(probability[ij]*sqrt(squish[ij]^2 - squish^2)) Basically using RMS rather than straight variance. The results of this calculation would be a direct standard deviation calculation on mitigation, piecewise-weighted by the disjoint probability of each case. The result would (I believe) be a value that we could use as a conventional standard deviation, which is less biased than a variance. (in particular, I think this will exhibit less pronounced skew against defense. Defense will still be less exciting than shield for spike optimization, but I believe RMS will penalize it less than simply difference squared. Another thing to think about with these sorts of calculations… I've never been particularly happy with how our best efforts for spike calculation (and, to be clear, dipstik's math really is best-of-the-best here) fail to take into account split attacks and the like. The canonical example here of course being pre-nerf NiM Oasis with assassin tanks. Both RMS and difference squared spike calculations naturally predict the spikiness of pre-2.5 assassin tanks, but they fail to distinguish between the "coin flip death" of pre-nerf Oasis and the "generally survivable but still scary" of post-nerf. Here again, defense is unduly penalized by the fact that we do not take this variable into account. Link to comment Share on other sites More sharing options...
KeyboardNinja Posted April 11, 2015 Share Posted April 11, 2015 pray tell, what is the new swing timer? since im doing all per boss i guess i could use per boss swing timer info... if anyone has those... I'm using a swing timer of 1/(15/18). This is basically a cheap hack based on the very high-level observation that the vast majority of fights in the new content can and will exhaust all 18 Kinetic Ward stacks over the course of the 15 second duration. This swing timer does generate a value for Kinetic Bulwark which appears to be predictive, so I'm relatively happy using it. I'd love something more authoritative though. One thing to note here is that this swing timer represents a massive increase over previous content. Specifically, 35% faster attacks! This increase and rough order of magnitude also bears out well with what I see in combat and generally in my logs, so it represents a reasonable check on my cheater number from above. Still interesting. Link to comment Share on other sites More sharing options...
dipstik Posted April 12, 2015 Share Posted April 12, 2015 (edited) isnt it a 18 second duration with set bonus? and, am i suppose to take the real part if squish[ij] is less than squish? or the modulus? Edited April 12, 2015 by dipstik Link to comment Share on other sites More sharing options...
KeyboardNinja Posted April 12, 2015 Share Posted April 12, 2015 (edited) isnt it a 18 second duration with set bonus? It's a 23 second duration with the set bonus, but the cooldown is 15 seconds. I'm calibrating off of the fact that I will often lose all 18 stacks fast enough that just hitting Kinetic Ward on cooldown is actually optimal. And remember that shield chance is not 100% and defense chance is not 0%, thus the swing timer is going to be quite a bit higher than the value calculated from direct Kinetic Ward usage. This is why, despite the fact that losing all 18 stacks is not a consistent thing, I still feel justified in using 1.2/sec as the net K/E swing timer. and, am i suppose to take the real part if squish[ij] is less than squish? or the modulus? Ah… Yeah that was screwy. I basically distributed the squaring in the wrong direction. This might be more reasonable: spike= sqrt(sum(probability[ij]*(squish[ij] - squish)^2)) Basically I'm just trying to get the square root back in here, since squaring the variance and using that as an absolute coefficient strikes me as wrong. The quirky thing I see about the above proposal is that the probability scalar is distributed into the sum. I think I have to do this by definition, but it's a little weird. Edit: Upon some further reflect in between debugging an unrelated project, the probability[ij] term actually makes perfect sense where it is. Basically, we're computing the RMS of the different cases, but it's a weighted mean with the coefficients normalized to sum to 1 (I'm assuming sum(probability[ij]) = 1; if it doesn't, then…uh, I have no idea what you would be doing in that case). So yeah, I think this is the more accurate term. The original spike would be fine as a relative coefficient (i.e. optimizing for it will produce the same results as optimizing for my revised spike), but the new spike has more intuitive values and can be used in composition with other statistical metrics more directly. Edit 2: Consider spike' to be my rooted version of spike. Terminology note: spike is weighted sigma squared, so we're right in line with a reasonable statistical framework. Let's think about the following idea… As step one, rather than showing tank survivability in terms of absolute mitigation (i.e. squish), why don't we display in the following form: squish ± spike' This gives a direct notion of how much spikiness a tank can expect in terms of percentages that can be summed into their mitigation. I think most people with a decent statistical grounding should be able to understand that presentation and derive strictly more value out of it than our current "single number form". Furthermore, we can perform some interesting optimizations now that we have a real weighted sigma. For example, we could optimize for squish - spike' * k, where k is some reasonable coefficient. I would suggest that three standard deviations is probably sufficient for anyone, but I would also be fine with going closer to 2. This is an assumption on the part of the theory crafters (us) to be sure, in that we are making a hard assumption about how much variance is "acceptable", but thinking in terms of the standard deviation it seems perfectly reasonable. Another exciting thing that we can do here is scale the spike' value by DtPS to actually include a survivability value for endurance!! Every big heal in the game is between 2 and 2.5 seconds, so let's consider a "spike window" to be double that, at 5 seconds. 5 * dtps * (squish + spike' * k) is the absolute magnitude of the k standard deviations worst-case spike healing scenario. Divide that by total HP and you get the worst-case scenario as an easy-to-consume percentage. Now my very first thought upon deriving the above was to try to figure out how to compose it with squish, but notice that squish is already part of the derivation! In other words, this is basically a single, master statistic which tanks can use to optimize endurance and mitigation as a cohesive package, dependent on the value of k. I think we have yet to see exactly what sort of results this would churn out, but intuitively it seems very promising. Edited April 12, 2015 by KeyboardNinja Link to comment Share on other sites More sharing options...
dipstik Posted April 12, 2015 Share Posted April 12, 2015 (edited) i used to calc squish +/- spike, but the coverage factor k and applying to endurance i never thought about. note that choosing the k factor, is the same as choosing the weight of squish in the optimization. dtps*window*(squish+k*std) = dtps*window*k*(squish/k + std). everything outside the parenthesis is just a scalar. this is very much like taking 0.5*squish and 1 for std, and normalizing we get 0.333*squish+0.666*std... ill redo everything using the sqrt of spike and call that spike from now on. it is more useful. Edited April 12, 2015 by dipstik Link to comment Share on other sites More sharing options...
KeyboardNinja Posted April 12, 2015 Share Posted April 12, 2015 note that choosing the k factor, is the same as choosing the weight of squish in the optimization. Indeed it is. Though, I think that this form gives us scalars (namely k) which have more intuitive meaning. Since these are subjective tuning parameters, it's pretty important that we have them conceptually grounded in something that we can comprehend easily. In other news, I ran the survivability and stddev numbers for every tank in full mitigation Revanite, and the results are a little surprising. Assuming I didn't make any errors: {High-><|shadow->{0.699422,0.312593},guardian->{0.696596,0.336262},vanguard->{0.673705,0.363111}|>, Mid-><|shadow->{0.667891,0.297257},guardian->{0.678768,0.33094},vanguard->{0.647002,0.359878}|>, Low-><|shadow->{0.661643,0.281025},guardian->{0.662052,0.305025},vanguard->{0.653382,0.351558}|>, Average-><|shadow->{0.677605,0.296402},guardian->{0.679006,0.325637},vanguard->{0.660035,0.356973}|>} So…shadows have a lower weighted standard deviation than the other tanks across the board? That would completely flip all of our assumptions on end. Link to comment Share on other sites More sharing options...
dipstik Posted April 12, 2015 Share Posted April 12, 2015 (edited) it seems worst case scenario for 5 seconds of damage is typically not as bad as 5 seconds of damage taken at 2 sigma from base squish. still seeing PTs more spikey than shadows though... updated my numbers, had a HUGE bug in general, and fixed up the spike math. i kind of want to optimize such that spike and squish are even... but i think the best option would be, if people are having a hard time with a fight, and they think it is spike killing them, set the coefficient for spike to 1 and the coefficient for squish to zero in x*squish+y*spike, where x+y=1. Or, if they think its steady damage killing them, they do as we do now, and set x to 1 and y to zero. or if each fight had a "spike matters" term between 0 and 1 that is set for each fight... Edited April 13, 2015 by dipstik Link to comment Share on other sites More sharing options...
KeyboardNinja Posted April 13, 2015 Share Posted April 13, 2015 (edited) it seems worst case scenario for 5 seconds of damage is typically not as bad as 5 seconds of damage taken at 2 sigma from base squish. still seeing PTs more spikey than shadows though... I thought that was weird too, until I did this: http://imgur.com/qbynKYY.png What you're looking at is the probability density function for each tank, centered on their survivability and with the standard deviation computed with our spike function (note that the y axis isn't a probability, so the fact that it goes above 1 is not wrong). This looked suspicious to me for a while, and then I stared at it for a while. The narrowness of the shadow graph indicates that all of its mitigation cases are tightly clustered around the mean, so the probability of being outside that bound is very low. However, that doesn't mean that outliers don't exist. Outliers happen even in shadow mitigation, and they aren't captured by standard deviation. The outliers are what people remember though, and they contrast so strongly with the far-more-common cases near the mean that people notice them all the more. Vanguards have more evenly distributed. This means that they tend to have more mitigation cases that are further away from their mean (positive and negative). However, because these sorts of fluctuations are so common, perceptually they seem just like part of the package. Thus, when Vanguards hit their really crazy outliers, it's less of a contrast from their normal mode of operation. So by some definitions, Vanguards are more spiky than Shadows, but they aren't more spiky by the definition that most people subscribe to. The definition that most people subscribe to isn't captured by standard deviation, because the crazy outliers are just smoothed over. i kind of want to optimize such that spike and squish are even... but i think the best option would be, if people are having a hard time with a fight, and they think it is spike killing them, set the coefficient for spike to 1 and the coefficient for squish to zero in x*squish+y*spike, where x+y=1. Or, if they think its steady damage killing them, they do as we do now, and set x to 1 and y to zero. or if each fight had a "spike matters" term between 0 and 1 that is set for each fight... Interesting idea. Still thinking along those lines… Edited April 13, 2015 by KeyboardNinja Link to comment Share on other sites More sharing options...
dipstik Posted April 13, 2015 Share Posted April 13, 2015 (edited) here is a graph for commanders in fuill revanite gear. http://imgur.com/6taSF4A note how the pt goes out the furthest, largest 100% interval over squish. the pt has 2 points with lower squish compared to the sin, at the highest probabilities, while the sin takes less than the pt at the low probabilities. the jugg seems very smooth here. i think the psychological aspect you are speaking to would pertain to the variation in probability, or the height of the graph. note how there is a dramatic uptick of the sin taking more damage at the end of the curve. the other two tanks have a smoother profile where the tanks are most susceptible. there is also something about the average jump in squish between consecutive points. the sin seems to have a greater distance between consecutive squish values than the other tanks something else i noticed, looking at the numbers for x=0 to x=1 a few posts back, i noticed that the base squish starts to see less returns for letting spike matter, so to speak. one could look at the base squish, and see that at around x=.3 (which would be around 2 sigma cutoff) the squish gains begin to dwindle down heres one for the returned http://imgur.com/iRvEYZJ\ it seems that non internal/elemental damage is very predictable, but the peak at the end, if the healers are not anticipating it, will be very dramatic. high squish and high probability. Edited April 13, 2015 by dipstik Link to comment Share on other sites More sharing options...
Methoxa Posted April 13, 2015 Author Share Posted April 13, 2015 (edited) One thing i noticed is that in all 3 tankstats Juggernauts and pts have mostly an absorb rating egual to their shieldrating. Sometimes shieldrating is even higher than absorbrating. Assasin tanks however have an higher absorbrating than shieldrating not only in FT+KE fights but also in MR+KE fights. The first reason seems reasonable as there is a minimum shieldrating with 198 enhancements. The second reason is to decrease squishiness. Assasins need a higher absorb rating than Juggernauts to receive an equal squishiness because the Juggernaut has more armour. As you can't negate spikes because shieldrating can not reach 100% there is a certain DR when reducing squishines i.e. going for more absorb is more important than reducing spikiness i.e. increasing shield. The question is, does an Assasin die because he receives one large hit or does he die because he receives two little less large hits in a row? My guess would be the second scenario, which would imply that even going for shieldrating far into the DR would reduce the probability of receiving 2 little less large hits in a row i.e. probability of dying. That is exactly the formula we should find out. The lower the probability of suprisingly large hits which put healers under pressure, the better high dtps would be healable and the more healers can anticipate the dmg profile of the tank. Note however that this only occurs at bosses who have a low swing timer. One thing i noticed at Underlurker HM with my assasin tank was, that when adds spawned and the boss casted his rock smash? on me my hp went under 30%, which puts healers under pressure and might even make them use their cd's. If i'd shield it i would still sit at somewhat around 50%. With more absorb instead of shield i might shield 1 attack less but not fall to 50% with a shielded attack but to 55%. However i still received 1 unpredictable strike more than with prioritizing shield more than absorb which means there is a higher probability of death with more absorb. This theory basically means that in an FT+KE only fight every tank should use shield augments only and get absorb with mods, ear and implas to decrease spikiness. This however might hurt your dtps, but those are unimportant as long as the tank survives and the healers didnt went totally berserk. But does a healer feel the difference of 100-200 dtps or does he rather "feel" unpredictable and sudden health drops to a dangerous level? What is the level of hp healers do not panic but see that there is a need for heal? Personally i would say 50% is the treshold where they might feel a little uncomfortable. This treshold should be use to determine absorb. After that the most important thing would be decrease spikiness and not squishiness.This is however my personal view, other players might feel another way. So to determine it. You have to look into your logs and find the most damaging FT+KE attack. Lets say it was 30k not shielded. 30k would be 54% of your hp pool, meaning you would fall to 46% if your hp is around 55k.So you are underneath the treshold. Now you determine how much you need to be above the treshold. this would be 5%. So basically you would need to get absorb high enough to decrease the attacks dmg by 5% when shielded. This does not mean you would need 5% absorb in total but you would need more because absorb and dmg reduction are multiplicative not additive. This is individually per level of gear and class. If you determined the absorb value you need, the thing left to do is to stack shield as much as possible on the remaining slots. Now mods do not have shield which determines the minimum value of absorb which is mostly already high enough to offer enough absorb to never get underneath that treshold as long as you shield the attack. To further increase that treshold you can also get some more hp. In my theory the more hp you have the less important absorb becomes. However tanking is not as easy as i sample it here to show you my theory. First of all there are no bosses that only have FT+KE dmg. Even Brontes NM has certain attacks that are MR+KE <tentacles>. Furthermore there are situations where dtps still matter even though the healers are relaxed at first because their tank never get below 50% they still have to heal him like hell. So there again we have to find a mix of reducing probability of death and minimizing dtps. Edited April 13, 2015 by Methoxa Link to comment Share on other sites More sharing options...
dipstik Posted April 13, 2015 Share Posted April 13, 2015 (edited) i suppose if i put up non lettered squish calcs and bmod spike calcs people could figure out where they want to be for inbetween the extremes. but even the numbers i get for minimizing spike seem to be missing the point since the standard deviation doesnt capture what is killing the tanks. the apporach you speak to is very similar in some aspects to kbn's spike approach, which used a half health probability as an exponent, iirc. i feel like the best effort would take heals, tank and boss into account, but at that point all generality is lost. maybe for each boss a consensus is reached as to what spikes are killing people, and the damage types and frequency of those attacks are taken into account when minimizing damage from those attacks. for example, every time the boss uses ability a then b, by the time c happens, im about to die. most of the time a cooldown can be used here, but one could argue that the gear suggested be based on only damage weights for those attacks. i still like the idea of the end user deciding, with the aid of healers: on a scale from 0 to 10, how responsible are sudden spikes of damage responsible for your death? then that factor can be used in optimizing as a balance between squish and spike. the standard deviation approach leave much to be desired. here are graphs for the distributions for commanders and the returned, optimizing for squish and spike. http://imgur.com/ubmVmgF it looks like the spike optimization will increase your squish just to even out the probabilities. for the heavy i/e fight, this looks like it would serve the healers well in keeping the damage constant (but the big part that makes damage seem spikey would be the rotation of the boss and phases of the fight more than these probabilities). for the kinetic weapon fight, i dont see a huge benifit in gearing for spike. the distribution is still pretty wild. ps: putting methoxa and kbn's ideas together gives: 5*dps*(squish+k*spike)<0.5*health. 5* dps can be replaced with a known damage bundle of a fight. squish+k*spike can be replaced with (x*squish+y*spike) or even the maximum squish of the fight (typically i/e damage). 0.5*health can be replaced with whatever health level the healers suggest, or put the damage bundle on the right side of the equation (getting rid of the 5*dps altogether) and have a secondary constraint that health>=damage_bundle, or even health*0.7>=damage_bundle. again, that would be a healer thing to ask. all of these would be things we can optimize endurance and stats to! Edited April 14, 2015 by dipstik Link to comment Share on other sites More sharing options...
dipstik Posted April 14, 2015 Share Posted April 14, 2015 (edited) using window*dps*(squish+k*spike)>0.5*health, minimizing squish+k*spike , setting k=2, window=5 sin malphar jugg malphar PT malphar dps 3500 4500 5500 6500 dps 3500 4500 5500 6500 dps 3500 4500 5500 6500 d 1567 1567 582 185 d 2005 2005 356 356 d 1560 1560 1632 1632 s 1200 1200 1887 1928 s 1200 1200 1928 1928 s 1493 1493 1928 1928 a 1236 1236 1372 1728 a 798 798 1557 1557 a 950 950 281 281 base 0.43128 0.43128 0.43703 0.43943 base 0.43968 0.43968 0.45187 0.45187 base 0.45886 0.45886 0.46400 0.46400 D 0.42892 0.42892 0.43357 0.43545 D 0.43758 0.43758 0.44778 0.44778 D 0.45684 0.45684 0.46195 0.46195 A 0.42919 0.42919 0.43449 0.43716 A 0.43778 0.43778 0.44997 0.44997 A 0.45671 0.45671 0.46071 0.46071 S 0.42919 0.42919 0.43482 0.43725 S 0.43795 0.43795 0.45007 0.45007 S 0.45673 0.45673 0.46162 0.46162 relic WD WD WD WD relic WD WD WD WD relic WA #N/A #N/A #N/A =ward 18436 18436 15177 16944 =ward 20209 20209 20306 20306 =ward 18131 18131 16158 16158 spike 0.29622 0.29622 0.28759 0.28481 spike 0.29004 0.29004 0.27479 0.27479 spike 0.30496 0.30496 0.29942 0.29942 b-mods 0 0 9 9 b-mods 0 0 9 9 b-mods 0 0 9 9 0.5*health 26238 26238 27836 27836 0.5*health 25056 25056 26582 26582 0.5*health 25056 25056 26582 26582 pain 17915 23034 27836 32794 pain 17846 22945 27540 32547 pain 18704 24048 29228 34543 buffer 8322 3204 0 -4958 buffer 7210 2111 -958 -5965 buffer 6352 1008 -2646 -7960 sin Squad jugg Squad PT Squad dps 6500 7500 8500 dps 6500 7500 8500 dps 6500 7500 8500 d 185 185 185 d 356 356 356 d 185 185 1164 s 1928 1928 1928 s 1928 1928 1928 s 1200 1200 1928 a 1890 1890 1728 a 1719 1719 1557 a 2618 2618 853 base 0.26414 0.26414 0.26860 base 0.26213 0.26213 0.26552 base 0.24271 0.24271 0.24354 D 0.26033 0.26033 0.26472 D 0.25818 0.25818 0.26152 D 0.23925 0.23925 0.24122 A 0.25901 0.25901 0.26302 A 0.25823 0.25823 0.26128 A 0.24054 0.24054 0.23753 S 0.25895 0.25895 0.26324 S 0.25824 0.25824 0.26151 S 0.23788 0.23788 0.23844 relic WS WS AS relic WD WD WA relic WS WS AS =ward 7521 7521 7198 =ward 9887 9887 9610 =ward 11173 11173 7564 spike 0.21099 0.21099 0.20944 spike 0.18761 0.18761 0.18628 spike 0.20330 0.20330 0.18235 b-mods 0 0 9 b-mods 0 0 9 b-mods 0 0 3.179935731 0.5*health 26238 26238 27836 0.5*health 25056 25056 26582 0.5*health 25056 25056 25595 pain 22130 25535 28981 pain 20586 23753 26938 pain 20945 24168 25595 buffer 4108 703 -1145 buffer 4470 1303 -356 buffer 4110 888 0 for those who dont want to copy and paste: http://imgur.com/wBDCGtB something goofy is happening with the triple constraint (between squish, spike and health inequality). id like to max squish unless the spike damage (pain) exceeds half health (buffer). ps i am going to call spike sigma from now on. i would liek to use spike to refer to the amount of damage in question (formerly refered to as pain=5*dps*(squish+2*sigma) in these recent tables). also, i dont think i will use the coverage factor approach, only because the x*squish+y*sigma approach can easily be manipulated to give an optimization for squish only, or sigma only. using the minimum of (squish+k*sigma) will make squish 1 part in a million if i set k to 1mil. it is a nuisance in the calcs. i think i will dive into finding a good trade off point for spike and squish... i am going to need all the dtps numbers (and their average fight time, so i can calc the weighted damage distributions). once i have those i can find a critical sigma maters term for the dps, and a critical damage amount (critical as in special) for a given sigma count, where one would begin to trade in for b mods, given a k factor ( i guess i will use x-factor). note that x=1/(1+k). to summerize: minimize squish*x+(1-x)*sigma while keeping (health-spike)>buffer pps: i cant seem to find a way to get squish and sigma on equal footing. the problem is, if squish is more reactive to variable changes than sigma, the optimization will tend to play with squish instead of sigma, and vice versa. i have tried normalizing, but then i get squish and spike in the demoninator for both terms: sigma*x/(sigma+squish) + squish*y/(sigma+squish), where i solve so x/(squish+sigma)=spike_matters/10 and y/(squish+sigma)=(10-spike_matters)/10. this is making the coverage factor k method much more appealing. i am also getting increases in squish for the sake of reducing sigma... it would make healing more predictable, but more energy intensive. Edited April 15, 2015 by dipstik Link to comment Share on other sites More sharing options...
KeyboardNinja Posted April 15, 2015 Share Posted April 15, 2015 So I wasn't able to replicate your graphs, dipstik. I was playing around with things specifically with shadows and the average profile, and I got the following (note that this is plotting probability over 1-squish, but it's still the same idea): http://imgur.com/2xpoF6T.png This is defined in a few ways. First, I'm grouping based on squish, rounded to the nearest hundredth. I then compose the probability of being within a particular squish bucket (defined as 1 - product(1-probability)). Data points are treated as {x->s, y->p} and sorted by squish (well, 1-squish). I then interpolate the curves and plot the results. The exact set of data points can be seen here: {<|p -> 0.211701, s -> 0.281326|>, <|p -> 0.207476, s -> 0.3|>, <|p -> 0.31299, s -> 0.695432|>, <|p -> 0.205507, s -> 1|>} (remember this is grouped by rounded squish, so there are fewer cases than one might expect) If I remove the rounding, I get the following dataset: {<|p->0.211701,s->0.281326|>, <|p->0.207476,s->0.3|>, <|p->0.0501468,s->0.695432|>, <|p->0.27672,s->0.695798|>, <|p->0.205507,s->1|>} Which graphs as this: http://imgur.com/Cb4tUhq.png Link to comment Share on other sites More sharing options...
dipstik Posted April 15, 2015 Share Posted April 15, 2015 i would think you would get 6 points. defend/resist, kinetic weapon shielded, kinetic force shielded, kinetic weapon unshielded, kinetic force unshielded and internal. i like that first curve a lot. that looks like a guassian curve Link to comment Share on other sites More sharing options...
KeyboardNinja Posted April 15, 2015 Share Posted April 15, 2015 (edited) i would think you would get 6 points. defend/resist, kinetic weapon shielded, kinetic force shielded, kinetic weapon unshielded, kinetic force unshielded and internal. Kinetic Weapon and Kinetic Force shielded and unshielded are the same values, respectively. Different probabilities, but the same values. Since I'm grouping by squish, those values disappear. Incidentally, noob question here: should I just be summing these probabilities when I group? I'm pretty sure they're definitionally disjoint. i like that first curve a lot. that looks like a guassian curve Mathematica's interpolation gets all the credit there. :-) Unfortunately, due to grouping and interpolating, my curves are dramatically less interesting than yours. (insert innuendo of choice) Edit You may find this interesting: http://imgur.com/xTJcfIF.png :-) It's strange, because I would think that this graph would be a lot more useful pivoted to the side, with mitigation up-down and probability left-right. However, that particular data pivot produces an incredibly dense graph full of lots of ups and downs and no clear conclusion. This graph is deceptive, but seems to match the gut test on how each tank feels. Good call on the axes, dipstik. Edited April 15, 2015 by KeyboardNinja Link to comment Share on other sites More sharing options...
dipstik Posted April 15, 2015 Share Posted April 15, 2015 (edited) I have 16 disjoint cases that sum to one, kw_named, kw_bland, kf and ef each coupled with defended, resisted, shielded and full hit. It looks like you are summing all the probabilities associated with squish=0. The same should should be true for all of like squish. Also, thanks for the kudos, but you were the first one to graph the probability density graph. Funny, all this time I've been reporting spike, but never thought to graph it. ps: heres the numbers for all the bosses assuming 6k dps, k=2, using squish to optimize unless 5*dps*(squish (with relic) +k* sigma )>0.5*health, in which case i optimize squish+k*sigma. sin Malfar Squad Undrlrk Cmndrs Retrnd Sparky Bulo Torque Mstr Cortani d 185 185 997 605 185 185 823 582 185 1374 s 1928 1908 1574 1676 1928 1901 1558 1922 1908 1928 a 1728 1910 1432 1722 1728 1917 1622 1499 1910 539 base 0.4394 0.2641 0.2234 0.2825 0.4004 0.3471 0.2764 0.3391 0.3463 0.4513 D 0.4354 0.2603 0.2188 0.2780 0.3972 0.3431 0.2720 0.3349 0.3434 0.4497 A 0.4372 0.2591 0.2186 0.2785 0.3970 0.3436 0.2725 0.3354 0.3422 0.4455 S 0.4373 0.2589 0.2188 0.2784 0.3971 0.3435 0.2724 0.3358 0.3421 0.4473 relic WD WS WA WD WA WD WD WD WS WA =ward 16944 7621 8402 9545 11593 10616 9759 10296 9298 9556 sigma 0.2848 0.2115 0.2062 0.2446 0.2697 0.2634 0.2461 0.2698 0.2531 0.2576 b-mods 9.0 0.0 0.0 0.0 9.0 0.0 0.0 0.0 0.0 9.0 optimize 1.0051 0.2589 0.2186 0.2780 0.9364 0.3431 0.2720 0.3349 0.3421 0.9608 jugg Malfar Squad Undrlrk Cmndrs Retrnd Sparky Bulo Torque Mstr Cortani d 356 356 1644 1564 356 1388 1869 356 417 1548 s 1928 1838 1200 1200 1928 1200 1200 1765 1915 1928 a 1557 1809 1159 1239 1557 1322 934 1781 1671 365 base 0.4519 0.2620 0.2262 0.2852 0.4048 0.3510 0.2799 0.3526 0.3457 0.4459 D 0.4478 0.2581 0.2223 0.2819 0.4014 0.3482 0.2768 0.3476 0.3427 0.4443 A 0.4500 0.2584 0.2227 0.2822 0.4021 0.3483 0.2766 0.3501 0.3425 0.4415 S 0.4501 0.2582 0.2226 0.2820 0.4022 0.3480 0.2767 0.3499 0.3425 0.4429 relic WD WD WD WD WD WS WA WD WA WA =ward 20306 9963 10704 11897 14298 14030 11998 14648 12054 12918 sigma 0.2748 0.1891 0.2054 0.2426 0.2556 0.2582 0.2451 0.2597 0.2339 0.2456 b-mods 9.0 0.0 0.0 0.0 9.0 5.2 0.0 5.6 0.0 9.0 optimize 0.9974 0.2581 0.2223 0.2819 0.9126 0.3480 0.2766 0.3476 0.3425 0.9326 pt Malfar Squad Undrlrk Cmndrs Retrnd Sparky Bulo Torque Mstr Cortani d 185 185 920 568 1913 415 953 1304 185 1913 s 1928 1928 1730 1912 1928 1928 1713 1928 1928 1928 a 1728 1890 1353 1523 0 1515 1337 609 1864 0 base 0.4648 0.2318 0.2105 0.2755 0.4194 0.3461 0.2721 0.3495 0.3303 0.4579 D 0.4614 0.2285 0.2065 0.2716 0.4179 0.3429 0.2685 0.3467 0.3277 0.4568 A 0.4629 0.2281 0.2065 0.2720 0.4138 0.3428 0.2686 0.3452 0.3272 0.4525 S 0.4627 0.2274 0.2063 0.2718 0.4156 0.3427 0.2684 0.3461 0.3266 0.4542 relic WD WS WS WD WA WS WS WA WS WA =ward 18327 10363 9558 10339 10123 11917 10822 11131 12520 10447 sigma 0.2981 0.1904 0.1794 0.2381 0.2710 0.2690 0.2398 0.2743 0.2583 0.2644 b-mods 9.0 0.0 0.0 0.0 9.0 8.0 0.0 9.0 1.4 9.0 optimize 1.0576 0.2274 0.2063 0.2716 0.9558 0.3427 0.2684 0.8938 0.3266 0.9813 the numbers for 4500 dps: sin Malfar Squad Undrlrk Cmndrs Retrnd Sparky Bulo Torque Mstr Cortani d 1567 185 997 605 185 185 823 1142 185 185 s 1200 1908 1574 1676 1901 1901 1558 1496 1908 1908 a 1236 1910 1432 1722 1917 1917 1622 1366 1910 1910 base 0.4313 0.2641 0.2234 0.2825 0.3977 0.3471 0.2764 0.3376 0.3463 0.4328 D 0.4289 0.2603 0.2188 0.2780 0.3945 0.3431 0.2720 0.3343 0.3434 0.4305 A 0.4292 0.2591 0.2186 0.2785 0.3945 0.3436 0.2725 0.3341 0.3422 0.4298 S 0.4292 0.2589 0.2188 0.2784 0.3945 0.3435 0.2724 0.3343 0.3421 0.4297 relic WD WS WA WD WD WD WD WA WS WS =ward 18436 7621 8402 9545 12000 10616 9759 11406 9298 12642 sigma 0.2962 0.2115 0.2062 0.2446 0.2720 0.2634 0.2461 0.2753 0.2531 0.2686 b-mods 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 optimize 0.4289 0.2589 0.2186 0.2780 0.3945 0.3431 0.2720 0.3341 0.3421 0.4297 jugg Malfar Squad Undrlrk Cmndrs Retrnd Sparky Bulo Torque Mstr Cortani d 2005 356 1644 1564 1152 1353 1663 1707 421 356 s 1200 1838 1200 1200 1421 1314 1200 1200 1810 1838 a 798 1809 1159 1239 1430 1335 1140 1096 1772 1809 base 0.4397 0.2620 0.2262 0.2852 0.4008 0.3496 0.2799 0.3423 0.3456 0.4350 D 0.4376 0.2581 0.2223 0.2819 0.3984 0.3469 0.2765 0.3394 0.3426 0.4326 A 0.4378 0.2584 0.2227 0.2822 0.3984 0.3469 0.2769 0.3397 0.3426 0.4328 S 0.4379 0.2582 0.2226 0.2820 0.3983 0.3467 0.2767 0.3396 0.3424 0.4327 relic WD WD WD WD WS WS WD WD WS WD =ward 20209 9963 10704 11897 15910 13938 12145 14472 12770 16498 sigma 0.2900 0.1891 0.2054 0.2426 0.2626 0.2580 0.2443 0.2711 0.2350 0.2520 b-mods 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 optimize 0.4376 0.2581 0.2223 0.2819 0.3983 0.3467 0.2765 0.3394 0.3424 0.4326 pt Malfar Squad Undrlrk Cmndrs Retrnd Sparky Bulo Torque Mstr Cortani d 1352 185 920 568 371 470 953 1032 185 185 s 1495 1928 1730 1912 1928 1928 1713 1671 1928 1928 a 1157 1890 1353 1523 1704 1605 1337 1300 1890 1890 base 0.4588 0.2318 0.2105 0.2755 0.4009 0.3437 0.2721 0.3439 0.3299 0.4362 D 0.4567 0.2285 0.2065 0.2716 0.3983 0.3407 0.2685 0.3409 0.3273 0.4342 A 0.4569 0.2281 0.2065 0.2720 0.3983 0.3407 0.2686 0.3410 0.3268 0.4340 S 0.4567 0.2274 0.2063 0.2718 0.3980 0.3404 0.2684 0.3408 0.3263 0.4336 relic WD WS WS WD WS WS WS WS WS WS =ward 18350 10363 9558 10339 14909 12523 10822 12835 12688 17149 sigma 0.3050 0.1904 0.1794 0.2381 0.2849 0.2707 0.2398 0.2793 0.2587 0.2849 b-mods 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 0.0000 optimize 0.4567 0.2274 0.2063 0.2716 0.3980 0.3404 0.2684 0.3408 0.3263 0.4336 Edited April 19, 2015 by dipstik Link to comment Share on other sites More sharing options...
KeyboardNinja Posted April 15, 2015 Share Posted April 15, 2015 Here is the full set of mitigation cases, plotted over all mitigation profiles: http://imgur.com/jGlkh92.png I think I actually have a pretty good intuition for why this graph represents spikiness now. Notice how Vanguards (and to a lesser extent Guardians) basically "sit' in the higher probabilities. Their mitigation may not be quite as good overall, but their cases are all in nearly the same "probability stratum", and that stratum is quite elevated. Thus, Vanguards will, with roughly equal probability, mitigate varying percentages of hits. Because it is roughly equal probability, a healer (or anyone else looking at the health bar over time) is just going to "get used" to seeing the fluctuations in mitigation. Nothing unusual happens, because nothing is unusual! Since everything is nearly the same probability, nothing is out of the ordinary. Shadows are the opposite. They have some really awesome mitigation cases, and it's easy to see looking at the graph how their mitigation can average out to be higher than a Vanguard. However, their probabilities are all over the map. There are some low probability cases which look very different from the high probability cases. Contrary to what the intuitive reading might imply, the two points in the center are not a good example of this (since the casual observer wouldn't ever see a difference between these points). A better example is the cluster pair of points on the far left compared to the apex of the curve in the middle. The apex is high probability and quite good mitigation. Off to the right is almost as much of a contrast, with consistently one of the highest probability max-mitigation cases (Guardians are nearly even, but slightly ahead). Anyway, this is basically the same intuition that we can derive for why shadows have the lowest standard deviation. In both cases, the "sharpness" of the graph is more interesting than the precise magnitudes, and I think that both graphs (but especially the cases one) do a pretty good job of reflecting player intuition on how the tanks feel. Link to comment Share on other sites More sharing options...
dipstik Posted April 15, 2015 Share Posted April 15, 2015 (edited) i agree. i think the spikiness of a tank pertains to the probability variance, and psychology thereof, more than the squish variance. gearing to reduce sigma does serve to reduce the variance in probabilities it seems. this should give healers a better health flux of the tank to respond to, even though they are taking more damage. Edited April 15, 2015 by dipstik Link to comment Share on other sites More sharing options...
Recommended Posts