I'm working on tools to better visualize stat weights, since just knowing the instantaneous weights (ie change with +1) can be a bit counter-intuitive, especially with Alacrity which fluctuates a lot in the simulator due to how it changes the rotations around.

My stats used for these plots:

Stat weights are interdependent, so these curves will differ with your stats. These values are true only for this set of stats, and should not be used to define your gearing.

My plan is to add the button for quickly making these plots to the next release.

So the question: Which of these is most useful/intuitive/confusing? Should I simply put in a button to make both?

Option 1: This display shows the change in HPS with a change in a rating, from your current stats -200 to your current stats + 200. Above zero, the highest curve is the stat you want to stack. Below zero, the highest curve is the one you want to reduce. This curve shows the benefit from changing stats, but not explicitly when they hit strong DR (although that should be implicit in a small change).

Option 2: This one shows each stat in a range of 0-2000. Your current stats are not visible on the chart, but you can see where DR kicks in hard, and it does put the stats in a sort of over-all perspective. While interesting, I'm not sure if this is important for gearing decisions. Presumably, if you are approaching the flat top of a curve for a stat, that should produce a minimal improvement in the Option 1 plot. And, in fact, we see that in my current plot as my Surge rating is high enough to cause it to start seeing some real DR.

Do you see a reason to include the second one? On the one hand I think it is an interesting data point, but on the other, adding more buttons quickly makes my already simplistic and low-quality UI even more cluttered.

I've been using the graphs at Jedilace in order to visualize DR curves. I feel that's pretty much all I need to make reasonable gear decisions along with some head math regarding Power.

http://www.jedilace.com/2012/02/01/when-is-too-much-surge-bad-for-digestion/

I just don't necessarily like how impossible it seems to be to get to that ideal given the current gearing mechanics. For me the second option is a bit redundant, though I obviously think it works as a format. Specific to your implementation, cut it down to displaying 0-1,000 so the graph is easier to read.

For option one, I think it might make sense to place the Primary/Secondary stats on separate graphs. That way it would be clearer that while Power is ahead at +200 (by 2HPS), the Surge you'll hopefully get (because you want to dump Alacrity) may push the favor just barely towards Crit. The idea being to emphasize that primary and secondary stats aren't competing each other for attention.

I've been using the graphs at Jedilace in order to visualize DR curves. I feel that's pretty much all I need to make reasonable gear decisions along with some head math regarding Power.

 

http://www.jedilace.com/2012/02/01/when-is-too-much-surge-bad-for-digestion/

I like the site, thanks for sharing it.

That said, the value of stats is inter-related. Yes, the DR points are set in stone, but that just tells you a value where you might want to stop stacking it, it doesn't tell you anything in terms of whether Power is better than Crit.

I just don't necessarily like how impossible it seems to be to get to that ideal given the current gearing mechanics. For me the second option is a bit redundant, though I obviously think it works as a format. Specific to your implementation, cut it down to displaying 0-1,000 so the graph is easier to read.

By impossible are you referring to the lack of Power/Crit mods, forcing you to take the lesser of the two evils of Alacrity or post-nerf Surge?

As for 0-1000 vs 0-2000, I was thinking the same. The relevant features appear to be in that half of the plot. I didn't know where they would appear when I first made it.

For option one, I think it might make sense to place the Primary/Secondary stats on separate graphs. That way it would be clearer that while Power is ahead at +200 (by 2HPS), the Surge you'll hopefully get (because you want to dump Alacrity) may push the favor just barely towards Crit. The idea being to emphasize that primary and secondary stats aren't competing each other for attention.

What do you mean by Primary and Secondary? To me, Aim is my Primary stat, and Cunning is Secondary. On the site you linked, they treat Aim as Primary and call Power Secondary. On items in game, one might call Crit/Power/Defense Primary, and Alacrity/Surge/Accuracy Secondary, as those appear to be how itemization is done and you are generally forced to choose Power vs Crit and Surge vs Alacrity, but not Alacrity vs Power.

first for primary/secondary/etc.

i just use the item generator priority:

primary stats: Main stat (p.e. for trooper is aim), Endurance

secondary stats: power, crit, defence

tertiary stats: surge, alacrity, accurancy, shield, absorbtion

i use those cause all items seem to come with 1+2+3, i.e. there isn't in this game a +surge +alacrity enchantment.

usually, you can only cut stats from the same category to boost another stat, p.e. you can't cut power to increase surge, you either have to cut alacrity or something from the "tertiary" category.

as far as visualization, in a spreadsheet that i have made for myself and for my rotations i just use both +1/-1 values for "pure" stat weights (but use them only as an indicator, that is if p.e. 1 surge gives me 0,016%heal increase and 1 power gives me 0,02%heal increase, i try to find more power) but i also use static "equip" changes (p.e. if i put +20cunning, -30power, +15crit -etc +etc it says my healing will be +/- X%)

since the stats are interconnected like that (increasing crit increases surge weight, increasing alacrity messes things up, and etc) it is really hard to find a graphical representation for the 5 different stats you need. Imo the only way to do something "like" that would be to create 2-3 3d charts that use (healing) as one column and the better connected stats as y and z axis (grouping p.e. crit+surge+healing, alacrity+power+healing, and etc) but i dont think it's so easy as it sounds, esp since alacrity messes up rotations.

so using +/-1 and +/-mass seems the most easy way to find the correct weights, even if it requires a bit of research from the user.

first for primary/secondary/etc.

 

i just use the item generator priority:

 

primary stats: Main stat (p.e. for trooper is aim), Endurance

secondary stats: power, crit, defence

tertiary stats: surge, alacrity, accurancy, shield, absorbtion

 

i use those cause all items seem to come with 1+2+3, i.e. there isn't in this game a +surge +alacrity enchantment.

 

usually, you can only cut stats from the same category to boost another stat, p.e. you can't cut power to increase surge, you either have to cut alacrity or something from the "tertiary" category.

 

as far as visualization, in a spreadsheet that i have made for myself and for my rotations i just use both +1/-1 values for "pure" stat weights (but use them only as an indicator, that is if p.e. 1 surge gives me 0,016%heal increase and 1 power gives me 0,02%heal increase, i try to find more power) but i also use static "equip" changes (p.e. if i put +20cunning, -30power, +15crit -etc +etc it says my healing will be +/- X%)

 

since the stats are interconnected like that (increasing crit increases surge weight, increasing alacrity messes things up, and etc) it is really hard to find a graphical representation for the 5 different stats you need. Imo the only way to do something "like" that would be to create 2-3 3d charts that use (healing) as one column and the better connected stats as y and z axis (grouping p.e. crit+surge+healing, alacrity+power+healing, and etc) but i dont think it's so easy as it sounds, esp since alacrity messes up rotations.

 

so using +/-1 and +/-mass seems the most easy way to find the correct weights, even if it requires a bit of research from the user.

Well currently the Stat Weights section of my calculator does +1 of each stat, and then normalizes them. The Upgrade Calculator is the static comparison you refer to, so I already have those bases covered. I get a lot of questions, primarily about Alacrity, so I was thinking something that showed a range might make it clearer why 1 point was a large HPS increase, but 10 points was a small decrease, for example.

Well currently the Stat Weights section of my calculator does +1 of each stat, and then normalizes them. The Upgrade Calculator is the static comparison you refer to, so I already have those bases covered. I get a lot of questions, primarily about Alacrity, so I was thinking something that showed a range might make it clearer why 1 point was a large HPS increase, but 10 points was a small decrease, for example.

yes i know you have them on your tool, it was quite handy till i made my spreadsheet for my own reasons ^^.

for the thing you want have you considered finding an equation that calculates the xtra fillers (be it ds or hammer shot) based on alacrity gains?

the rotations are just like equations

your restrictions are just like equations

so if you solve them in a single one, while using power, main, crit, surge as statics and using (alacrity rating) and (number of fillers) as variables you should get in theory a graph that shows the increase in fillers over a static amount of time based on increase of alacrity rating (obviously use ..er i dont know the english word since english is not my main language.. but use 1,2,3,4,5 and not 1.32132132 as acceptable numbers (like quantums).

DONT use healing cause in reality healing isn't hps but hp/cast.

then just put healing = hps (for all the abilities excluding fillers) +(number of fillers)*(average filler healing)

yes i know you have them on your tool, it was quite handy till i made my spreadsheet for my own reasons ^^.

 

for the thing you want have you considered finding an equation that calculates the xtra fillers (be it ds or hammer shot) based on alacrity gains?

 

the rotations are just like equations

your restrictions are just like equations

 

so if you solve them in a single one, while using power, main, crit, surge as statics and using (alacrity rating) and (number of fillers) as variables you should get in theory a graph that shows the increase in fillers over a static amount of time based on increase of alacrity rating (obviously use ..er i dont know the english word since english is not my main language.. but use 1,2,3,4,5 and not 1.32132132 as acceptable numbers (like quantums).

 

DONT use healing cause in reality healing isn't hps but hp/cast.

 

then just put healing = hps (for all the abilities excluding fillers) +(number of fillers)*(average filler healing)

I actually use that metric a lot. If you click "Compute Alacrity Stats" the output window will show cast counts as well as HPS for the various Alacrity %s. You can then sum the non-fillers and compare those counts to the filler counts. If you copy and paste that output into a file and save it as a .csv file, you can easily make all sorts of analysis in Excel, OpenOffice, or GoogleDocs.

The problem with your equation, if I am interpreting your intentions correctly, is that there are a lot of variables that are ability specific. If you use the 4pc Scoundrel set, Kolto Pack has a +15% Crit chance, for instance. So I need to know how often every ability is used. Plus, for Scoundrels, I need to constantly check for procs for UH from SRMP and energy return from DS.

I actually use that metric a lot. If you click "Compute Alacrity Stats" the output window will show cast counts as well as HPS for the various Alacrity %s. You can then sum the non-fillers and compare those counts to the filler counts. If you copy and paste that output into a file and save it as a .csv file, you can easily make all sorts of analysis in Excel, OpenOffice, or GoogleDocs.

 

The problem with your equation, if I am interpreting your intentions correctly, is that there are a lot of variables that are ability specific. If you use the 4pc Scoundrel set, Kolto Pack has a +15% Crit chance, for instance. So I need to know how often every ability is used. Plus, for Scoundrels, I need to constantly check for procs for UH from SRMP and energy return from DS.

that doesn't change the fact that if you use a static crit/surge/power/main the healing/cast is the same.

as far as procs from srmp they are static, alacrity doesn't affect hot tick rate and thus the amount of procs should be the same regardless of alacrity

as far as energy return for DS it is 6*3*(1-alacrity%)+2*3*crit%. if you use crit as static you have again 1 equation based on only one variable (alacrity)

the only thing that alacrity changes is the number of casts in a certain amount of time.

so lets say that instead of calculating hps for the abilities you calculate number of abilities used in a rotation (your calc does that already if i remember correctly)

then do a

abilityXhealing*(number of times ability X is used)+abilityYhealing*(number of times ability Y is used)+...+abilityNhealing*(number of times ability N is used)

and divide by the static amount of time those abilities were used. Number of abilities should be round down always.

Now, in order to visualize this you need those statics and variables:

variables: number of casts for each ability, alacrity, total hps

statics: actual heal amount for each ability, totaltime

then an equation that is the "relative" healing of each ability:

you want to know how the number of casts actually affect the total hps, for more abilities with lower hps than your totalhps the totalhps should drop, and for more abilities with higher hps than the totalhps the totalhps should rise. something like:

newtotalhpsX=(oldtotalhps*(totaltime-casttimeX*(1-alacrity%))+abilityXhealing*casttimeX*(1-alacrity%))/(totaltime)

totalhpsDX= newtotalhpsX-oldtotalhps (D stands for differance:P)

the above equation shows how a single ability X should affect the total hps of your rotation.

since with different alacrity numbers you can already calculate the differance in the number of casts for all abilities:

i.e. +50alacrity is +1ability x and +2ability y

you can then do a :

newtotalhpsD= x'*totalhpsDX+y'*totalhpsDY+...+n'*totalhpsDN

where x',y',...,n' are the number of casts of abilities X,Y,...,N for alacrity rating B minus the number of casts of abilities X,Y,...,N for alacrity rating A

now the programming stuff should be something like "show me the next alacrity rating that newtotalhpsD =/= 0"

if newtotalhpsD is >0 then the next alacrity "step" is a gain and if it is <0 a loss of hps.

sorry if actual math is wrong, i type this at work, but you should get a feeling of what i try to say at least and if this is possible with the tool.

That said, the value of stats is inter-related. Yes, the DR points are set in stone, but that just tells you a value where you might want to stop stacking it, it doesn't tell you anything in terms of whether Power is better than Crit.

 

By impossible are you referring to the lack of Power/Crit mods, forcing you to take the lesser of the two evils of Alacrity or post-nerf Surge?

 

 

What do you mean by Primary and Secondary? To me, Aim is my Primary stat, and Cunning is Secondary. On the site you linked, they treat Aim as Primary and call Power Secondary. On items in game, one might call Crit/Power/Defense Primary, and Alacrity/Surge/Accuracy Secondary, as those appear to be how itemization is done and you are generally forced to choose Power vs Crit and Surge vs Alacrity, but not Alacrity vs Power.

By Primary and Secondary I mean what the other poster called Secondary and Tertiary. Crit/Power on one graph and Surge/Alacrity on the other. Would it be impossible to include real time editing of stats, so you can see how the Surge you want to have affects the stat weight of Crit?

I've largely been using head math to deal with Power.

that doesn't change the fact that if you use a static crit/surge/power/main the healing/cast is the same.

as far as procs from srmp they are static, alacrity doesn't affect hot tick rate and thus the amount of procs should be the same regardless of alacrity

as far as energy return for DS it is 6*3*(1-alacrity%)+2*3*crit%. if you use crit as static you have again 1 equation based on only one variable (alacrity)

 

the only thing that alacrity changes is the number of casts in a certain amount of time.

This would be correct if the procs were simply a damage buff of some sort. You could calculate the average proc rate per minute, then apply that fractional boost to the ability in question.

However, in this case the procs change the decision tree. Let's say you just cast EMP and now you are at 80 Energy and 1 UH, you would be about to cast UWM. But if, during the 1.5s GCD of EMP, SRMP procced and now you are suddenly at 2UH? You don't want to cast UWM now, since that will waste an UH, so you cast EMP instead. During that GCD you regen 7.5 Energy, and now you are 87.5 Energy and 1 UH. You now continue with your previously scheduled rotation, but you are 7.5 Energy higher, which might change further things down the line.

DS Energy regen procs do the same. You could be low enough that you want to cast DS, but just barely. A DS with no procs would leave you doing a second DS. A DS with 3 procs would have you casting UWM. A DS with any number of procs that has SRMP proc during it, would have you cast EMP next.

So we see the actual rotations changing based on the procs, not just a static multiplier we can average in based on a proc per minute estimate. Even a 0 Alacrity Scoundrel build will see variance from one rotation run to the next. I mask this in my calculator by seeding the RNG with the same number at the start of every calculation, so the first run always procs the same, second is always different from the first but the same as the second in any other run, etc. This makes the average of the runs stable for a given set of settings for the user, while continuing to keep the RNG from run to run realized in the background.

so lets say that instead of calculating hps for the abilities you calculate number of abilities used in a rotation (your calc does that already if i remember correctly)

 

then do a

abilityXhealing*(number of times ability X is used)+abilityYhealing*(number of times ability Y is used)+...+abilityNhealing*(number of times ability N is used)

 

and divide by the static amount of time those abilities were used. Number of abilities should be round down always.

 

Now, in order to visualize this you need those statics and variables:

variables: number of casts for each ability, alacrity, total hps

statics: actual heal amount for each ability, totaltime

 

then an equation that is the "relative" healing of each ability:

 

you want to know how the number of casts actually affect the total hps, for more abilities with lower hps than your totalhps the totalhps should drop, and for more abilities with higher hps than the totalhps the totalhps should rise. something like:

 

newtotalhpsX=(oldtotalhps*(totaltime-casttimeX*(1-alacrity%))+abilityXhealing*casttimeX*(1-alacrity%))/(totaltime)

 

totalhpsDX= newtotalhpsX-oldtotalhps (D stands for differance:P)

 

the above equation shows how a single ability X should affect the total hps of your rotation.

 

since with different alacrity numbers you can already calculate the differance in the number of casts for all abilities:

i.e. +50alacrity is +1ability x and +2ability y

 

you can then do a :

 

newtotalhpsD= x'*totalhpsDX+y'*totalhpsDY+...+n'*totalhpsDN

 

where x',y',...,n' are the number of casts of abilities X,Y,...,N for alacrity rating B minus the number of casts of abilities X,Y,...,N for alacrity rating A

 

 

now the programming stuff should be something like "show me the next alacrity rating that newtotalhpsD =/= 0"

if newtotalhpsD is >0 then the next alacrity "step" is a gain and if it is <0 a loss of hps.

 

sorry if actual math is wrong, i type this at work, but you should get a feeling of what i try to say at least and if this is possible with the tool.

Took me a couple of reads, but I think I see what you are trying to say.

I don't think that works with the way Alacrity works, though. It isn't enough to just speed everything up, that has effects on the resources, which changes the decisions you make along the way. In a more static environment, though, it would probably be a more efficient way to estimate things than my current implementation.

Now, some people have tried to argue that it should be impossible for Alacrity to decrease the HPS, so I was thinking your final bit there might help with coding it so that you checked the rotation to see if it was an improvement from the one used with a previous value of Alacrity, and then use whichever rotation has higher HPS, but I think that would be falsifying the results. Here's what I'm saying:

Assume you have an ability X that takes 2s, and has a net cost of 10% of your resources. You don't want to drop below 70% resources, and you are starting at 90% (to avoid a little strangeness in how resources work when at 100%). You also have a filler ability Y that restores 5% of your resources and takes 1.5s.

Now, at 0 Alacrity how would this look:

Start 90% Resources

X 80%

X 70%

Y 75%

Y 80%

X 70%

Y 75%

Y 80%

X 70%

Y 75%

Y 80%

X 70%

repeat YYX ad nauseum

Now, let's add some Alacrity such that the net cost of X increases to 11%. Y remains a net 5% because it is instant and not affected by Alacrity.

Start with 90% resources

X 79%

Y 84%

X 73%

Y 78%

Y 82%

X 71%

Y 76%

Y 81%

X 70%

Y 75%

Y 80%

Y 85%

The number of fillers needed before you can recast will vary a bit, but you could establish a new average ratio. The problem comes when you are actually forced below that resource limit. Let's look at real numbers for a second:

Medical Probe costs 1 Ammo if used after Adv Med Probe. It takes 2s base to cast. With 0 Alacrity that means it costs -0.2 Ammo (a gain in Ammo) in the max regen zone, and costs 0.28 Ammo in the medium zone. With MP sped up to a 1.6 second cast, it now costs 0.04 Ammo in high regen, but costs 0.424 Ammo in the medium zone. For every 0.5 second you shave off of your cast time, you have to wait an extra 0.5 second of not doing anything. These 0.5 seconds can't be banked until you have enough for a filler cast (1.5s HS for instance), since, if you drop below a threshold you would not otherwise drop below, your regen will take a hit that the non-hasted rotation would not see, and in the long run that will add up to decreased non-filler casts. This is mostly a problem for Commandos because not going below 67% is tougher than not going below 60% (Mercs and Agents/Smugglers) when all of our classes abilities cost 25%.

I think I drifted a little off topic there, but what I was trying to show throughout this long post was how both procs and alacrity change the decision tree, and so, therefore, I don't think formulation works for them, you have to do simulation.

By Primary and Secondary I mean what the other poster called Secondary and Tertiary. Crit/Power on one graph and Surge/Alacrity on the other. Would it be impossible to include real time editing of stats, so you can see how the Surge you want to have affects the stat weight of Crit?

 

I've largely been using head math to deal with Power.

Well, the output of my tool is just Comma-Separated text. I don't have the means to produce the graphs myself, and there are very few Qt graphing tools out there. The only really developed one I've found is not a free library, and it isn't cheap, so for now I'm sticking with the plan of "I'll give you CSV data, you plot it however you want."

The output for this comes in columns of Rating, Power, Crit, Surge, Alacrity. You could just as easily make a plot with Rating on the bottom and Power/Crit on the side, and then another with Rating vs Surge/Alacrity.

Personally, its a little faster to just make the one, and then know (for my results above) that I am comparing the Power line to Crit, the Surge to Alacrity, and wishing I could ditch the second two for the first two.

This would be correct if the procs were simply a damage buff of some sort. You could calculate the average proc rate per minute, then apply that fractional boost to the ability in question.

 

 

DS Energy regen procs do the same. You could be low enough that you want to cast DS, but just barely. A DS with no procs would leave you doing a second DS. A DS with 3 procs would have you casting UWM. A DS with any number of procs that has SRMP proc during it, would have you cast EMP next.

 

So we see the actual rotations changing based on the procs, not just a static multiplier we can average in based on a proc per minute estimate. Even a 0 Alacrity Scoundrel build will see variance from one rotation run to the next. I mask this in my calculator by seeding the RNG with the same number at the start of every calculation, so the first run always procs the same, second is always different from the first but the same as the second in any other run, etc. This makes the average of the runs stable for a given set of settings for the user, while continuing to keep the RNG from run to run realized in the background.

 

 

 

 

Took me a couple of reads, but I think I see what you are trying to say.

 

I don't think that works with the way Alacrity works, though. It isn't enough to just speed everything up, that has effects on the resources, which changes the decisions you make along the way. In a more static environment, though, it would probably be a more efficient way to estimate things than my current implementation.

 

but your calculator already counts the number of casts for each ability for different amounts of alacrity (in the cast count section)

just use this data to count the differance.

if p.e. i input 1000alacrity i get :

UWM casts: 66

EMP casts: 71

SRMP casts: 20

DS casts: 29

Total casts: 186

if i put 500alacrity i get:

UWM casts: 67

EMP casts: 59

SRMP casts: 20

DS casts: 29

Total casts: 175

you use same cunning/surge/crit/power so the only thing affecting number of casts is alacrity, REGARDLESS of the change in the actual rotation you can count how many times each ability is used.

for 1000alacrity hps should be:

[(healing amount of UMW)*66+(healing amount of EMP)*71+(healing amount of SRMP)*20+(healing amount of DS)*29]/(total casting time)

for 500 alacrity hps would be

[(healing amount of UMW)*67+(healing amount of EMP)*59+(healing amount of SRMP)*20+(healing amount of DS)*29]/(total casting time)

since total casting time is the same (a constant), healing amount of X is the same for all abilities (since alacrity doesn't affect the actual healing number), then the only thing that changes is the number of casts.

lets say equation 1 is named newHPS and equation 2 is oldHPS. then newHPS-oldHPS is =

[(healing amount of UMW)*(66-67)+(healing amount of EMP)*(71-59)+(healing amount of SRMP)*(20-20)+(healing amount of DS)*(29-29)]/(total casting time)=

[(healing amount of UMW)*(-2)+(healing amount of EMP)*(12)]/(total casting time)= DHPS

and this is the differance of 500alacrity in your total healing output.

lets use some actual stats now: i am using 1800cunning, 400crit, 400power, 250surge and 300alacrity:

i get :

UWM casts: 66

EMP casts: 58

SRMP casts: 20

DS casts: 27

Total casts: 171

in your calc if i raise alacrity by 1 to 301 i get:

UWM casts: 66

EMP casts: 58

SRMP casts: 20

DS casts: 27

Total casts: 171

AGAIN.

that means that 1 alacrity is actually contributing 0 to hps at 300alacrity with those stats. in fact, the next "change" is at 319alacrity where the rotation changes to:

UWM casts: 63

EMP casts: 73

SRMP casts: 21

DS casts: 20

Total casts: 177

substract the casts and you get:

UWM casts: -3

EMP casts: +15

SRMP casts: +1

DS casts: -7

Total casts: 177

healing for each ability should be the same since in the healing amount equation nothing was changed. so DHPS now is:

[(healing amount of UMW)*(-3)+(healing amount of EMP)*(15)+(healing amount of SRMP)*(1)+(healing amount of DS)*(-7)]/(total casting time)

if the above number is positive you gain hps, if it is negative you lose hps.

as you see, with the rotation change it is actually quite possible to have +/- values on the different heals, and this is what leads to hps loss from alacrity gains in some steps.

since your calculator automatically counts number of casts for each ability, i think it may be possible to actually tell it to "count" those casts and tell you the exact number of alacrity that those change, so it can automatically calculate the alacrity "steps" and by changing to that value calculate if it is a gain or a loss.

edit:

the count seems to stuck sometimes though, p.e. for same alacrity and same everything it sometimes bug ot aand shows different casts until you hit it to calculate again, dont know why

The cast time isn't exactly the same, though.

The loop says "While Elapsed Time is less than Rotation Time" where rotation time defaults to 300s but can be changed.

So it lets you get in a final cast if you are at 299s, even if that means ending at 300.5 or 301s. The elapsed healing over the whole thing is then divided by the elapsed time.

So if 1 point doesn't change the cast counts, it will still cause any cast time or channeled abilities to go off slightly faster. Since the healing done will be the same, this will result in slightly higher HPS, even with an identical cast count.

There is no way to force a rotation to fit 300s exactly (and do you know how long a boss will live before starting? If not, that would be an odd way to simulate a rotation), so the options are to let it end early (ie 298.6-299.9s no instants or faster cast abilities) or let it go slightly over, which is the option I chose. Either way you need to divide by the real elapsed time. I guess for DPS this assumes you get the killing blow, when the (298.6-299.9) option and dividing by 300 would suggest the boss died before your cast went off, but that seems like it would just be adding in a strange artifact for no reason.

I think this is why, if you look at the plot, there are flat regions that have a slope to them. The HPS is increasing, but only as the abilities speed up from 301+s to 300, and then once it drops to 299.9 again, the cast count will increase as a new ability slips in.

This is partly why I kept the original fixed Cast Count button. It will always be 300 casts (or whatever you set) so then you can examine the makeup of those 300 to see what abilities are getting used in what ratio at different levels of Alacrity. The HPS will still increase, as the 300 take less time to cast.

Also, why not simply subtract the HPS numbers? Currently I was dividing them, to see the % increase, but you could subtract instead to see the raw change. The HPS is displayed in its own box when you hit that button, or for each Alacrity % when you click to compute that.

The cast time isn't exactly the same, though.

 

The loop says "While Elapsed Time is less than Rotation Time" where rotation time defaults to 300s but can be changed.

 

So it lets you get in a final cast if you are at 299s, even if that means ending at 300.5 or 301s. The elapsed healing over the whole thing is then divided by the elapsed time.

 

So if 1 point doesn't change the cast counts, it will still cause any cast time or channeled abilities to go off slightly faster. Since the healing done will be the same, this will result in slightly higher HPS, even with an identical cast count.

 

There is no way to force a rotation to fit 300s exactly (and do you know how long a boss will live before starting? If not, that would be an odd way to simulate a rotation), so the options are to let it end early (ie 298.6-299.9s no instants or faster cast abilities) or let it go slightly over, which is the option I chose. Either way you need to divide by the real elapsed time. I guess for DPS this assumes you get the killing blow, when the (298.6-299.9) option and dividing by 300 would suggest the boss died before your cast went off, but that seems like it would just be adding in a strange artifact for no reason.

 

I think this is why, if you look at the plot, there are flat regions that have a slope to them. The HPS is increasing, but only as the abilities speed up from 301+s to 300, and then once it drops to 299.9 again, the cast count will increase as a new ability slips in.

 

This is partly why I kept the original fixed Cast Count button. It will always be 300 casts (or whatever you set) so then you can examine the makeup of those 300 to see what abilities are getting used in what ratio at different levels of Alacrity. The HPS will still increase, as the 300 take less time to cast.

 

Also, why not simply subtract the HPS numbers? Currently I was dividing them, to see the % increase, but you could subtract instead to see the raw change. The HPS is displayed in its own box when you hit that button, or for each Alacrity % when you click to compute that.

make it to always go under 300s.

then (since you know the number of casts) estimate "real total casting time" by multipling the number of each abilities usage with their modifired casting time:

p.e. in my above examples:

lets use some actual stats now: i am using 1800cunning, 400crit, 400power, 250surge and 300alacrity:

 

i get :

UWM casts: 66

EMP casts: 58

SRMP casts: 20

DS casts: 27

Total casts: 171

 

in your calc if i raise alacrity by 1 to 301 i get:

 

UWM casts: 66

EMP casts: 58

SRMP casts: 20

DS casts: 27

Total casts: 171

 

AGAIN.

 

that means that 1 alacrity is actually contributing 0 to hps at 300alacrity with those stats. in fact, the next "change" is at 319alacrity where the rotation changes to:

UWM casts: 63

EMP casts: 73

SRMP casts: 21

DS casts: 20

Total casts: 177

 

substract the casts and you get:

UWM casts: -3

EMP casts: +15

SRMP casts: +1

DS casts: -7

Total casts: 177

 

healing for each ability should be the same since in the healing amount equation nothing was changed. so DHPS now is:

[(healing amount of UMW)*(-3)+(healing amount of EMP)*(15)+(healing amount of SRMP)*(1)+(healing amount of DS)*(-7)]/(total casting time)

 

if the above number is positive you gain hps, if it is negative you lose hps.

 

the real DHPS can be calculated as:

[(healing amount of UMW)*(63)+(healing amount of EMP)*(73)+(healing amount of SRMP)*(21)+(healing amount of DS)*(20)]/(total casting time NEW)

MINUS

[(healing amount of UMW)*(66)+(healing amount of EMP)*(58)+(healing amount of SRMP)*(20)+(healing amount of DS)*(27)]/(total casting time OLD)

where

(total casting time NEW)= (63)*(2-2*NEWalacrity%) + (73)*1.5 + (21)* 1.5 + (20)* (3-3*NEWalacrity%)

and

(total casting time OLD)= (66)*(2-2*NEWalacrity%) + (58)*1.5 + (20)* 1.5 + (27)* (3-3*NEWalacrity%)

this way you have a 100%accurate HPS but it gets a bit more messy calculation wise, it is still a 1st degree equation with only 2 variables (hps and alacrity) but a bit messier than assuming that all healing comes in a 300sec window with a +/- 0,1 error margin.

what i am trying to say, is that your calculator already does the hard job, which is counting the exact number of casts and the differance in rotations as alacrity changes, the ONLY thing you have to change is the actual formula for HPS to count actual casts and not fictional margins of casts and to be able to recognise when the rotation change (i guess if you put a parameter like "if x1-x2=/=0 then calculate, else alacrity=alacrity+1" or something similar. Where x1,x2 are new and old number of casts for each ability, then you will have the perfect visualization:

one can put his numbers and the calc will say:

alacrity 300, next step alacrity=319, your HPS will be +/- X and etc.

this way you have a 100%accurate HPS but it gets a bit more messy calculation wise, it is still a 1st degree equation with only 2 variables (hps and alacrity) but a bit messier than assuming that all healing comes in a 300sec window with a +/- 0,1 error margin.

 

what i am trying to say, is that your calculator already does the hard job, which is counting the exact number of casts and the differance in rotations as alacrity changes, the ONLY thing you have to change is the actual formula for HPS to count actual casts and not fictional margins of casts and to be able to recognise when the rotation change (i guess if you put a parameter like "if x1-x2=/=0 then calculate, else alacrity=alacrity+1" or something similar. Where x1,x2 are new and old number of casts for each ability, then you will have the perfect visualization:

 

one can put his numbers and the calc will say:

 

alacrity 300, next step alacrity=319, your HPS will be +/- X and etc.

I think before this conversation continues, we should do something we never did at the start: identify what we are trying to find.

Do you just want to know the change in HPS?

As far as I can tell, you are saying to run the simulation to get the ability counts and then find the HPS by : (abilityHealing*abilityCount)/(abilityCastTime*abilityCount), summed for all abilities in the rotation. Do this for two rotations and difference them and you will have the change in HPS.

I am saying: Determine the ability, add its healing and cast time to running totals, then divide the totals at the end. Do this for two rotations and difference them, and you will have the change in HPS.

As far as I can see, those two are identical, except that you wait to do the summation until the end and I do it as I go. Is that what you are looking for? Am I misunderstanding your intentions?

I don't know what you mean by

change is the actual formula for HPS to count actual casts and not fictional margins of casts

My rotation only uses full casts. If you are at 299 seconds, and the logic says cast Medical Probe (which takes 2s), it doesn't cast half of a MP and then divide by 300, it casts the whole thing and divides the total by 301. If you then speed it up so MP takes 1.6 seconds, and you get to 299 seconds and the conditions say cast MP, it will cast the full thing, and end at 300.6 seconds. The total healing would be the same (all else equal), but the slightly shorter elapsed time (0.4s) would result in a very small HPS gain. That's a real effect, but smoothed out by dividing by the real cast time?

But I really don't know what you mean by that, so I may be arguing the wrong thing entirely. So what do you mean by "fictional margins of casts" and what value are you trying to identify?

i didn't know if your formula used number of casts (real casts) or made a theoritical hps of each ability*time allotment and then multiplied and procced to fill 300sec of abilites.

so, if you already use full casts for your formula then it shouldn't be hard to understnad what i say:

from my pov, what you want as a visualization is a clear margin that says something similar to "1 alacrity may seem like a 1,452545 hps increase, but due to costs/change of rotation 10alacrity may be -1,12321312 hps" correct me if i am wrong.

the very first formula i enetered here, (if it is correct since i was at work at that moment) uses your system of calculating each ability seperatly while the last ones they calculate them all toghether and divide by total time.

as an effect they are the same, it is just that the second is more "clean" so as to say what i want better.

now, about visualization, your calculator shows something like this:

you have 300alacrity, you do 1600hps

you have 301alacrity, you do 1601hps

your calc already does that, the problem arises when you change rotations, like when you go from 318alacrity to 319 alacrity

those are steps that alacrity messes up the rotation by either lowering your regen, or allowing a free extra filler or whatever. what confuses most people is that exactly because of those changes there can be hps loss from increasing a stat by a certain amount.

to add to that, there is fictional hps gain:

you use a 300sec window but put a parameter that limits the time (you have to, no way around that). So, p.e. imo 300alacrity and 301alacrity should show up as same HPS but different time, NOT different HPS. Theoritically doing 16000healing in 10secs is lower than doing 16000healing in 9.99secs, but when in the first occasion you can use a big heal after the 10secs, while in the second you need to use a filler, in reality it is a HPS loss.

so, my suggestion would be for the claculator to show if the next "step" in alacrity is a gain or a loss of hps. If it is a loss, it means that there is HPS loss all the way till the step, your restrictions on the time is what is blocking them to appear.

so if p.e. you have X alacrity and the next step is X+11 and you have a gain, then it means that all those 11points are a slight gain of HPS, equal to the +1you already show BUT if you have Y alacrity and the next step is Y+13 and you have a loss there, then it means that ALL those 13points were a slight loss despite what the +1is saying:

so, instead of having alacrity appear as:

alacrity 300, weight 0,017 (uses alacrity+1to calculate)

make it appear as:

alacrity 300, alacrity 319= +/- Z HPS (uses alacrity steps to calculate)

this will make it more clear if it is wise to add alacrity and how much it is helping.

as far as the math go, it is really easy to apply them, just do a x1-x2=/=0 and in the first number this is true then it is a step. use the new alacrity to calculate hps and substract form old.

In a discussion with someone who is convinced that any negative HPS change is evidence that the rotations are wrong, I just had what might amount to a breakthrough revelation on this issue.

I am pretty certain my rotations and decision logic are correct. Healing doesn't involve many abilities, and it isn't that complex. There isn't a lot of room where you could make a mistake on those grounds.

However, I think I have been chasing the wrong metric.

There is no point to increasing your HPS, because a boss has a fixed DPS. If you attempt a boss, then gear up and come back, he will still do the same damage. If he does 1500DPS, and you do 1500 HPS, you are casting 100% of the time. If you gear up to be able to do 2000HPS, you will simply cast 75% of the time and stand around or DPS the rest. You can't heal for 500HPS*fight_length more, because that would all be over-healing and wasted.

So what I should be doing is modeling incoming boss damage. Perhaps as settings the user can choose: Boss attack damage, boss swing time interval. If a boss hits for 5k every 10s, that's 2000DPS, but it comes in a single chunk, and you then have 10s to refill it based on your abilities and cooldowns.

At low levels of gear where you exactly match the boss DPS, you should have a fairly high cast count. At higher levels of gear, for the same fight length, you should have a lower cast count, corresponding to filling the tank up and then waiting. For a Commando, I would fill that downtime with some Hammer Shots just to keep up CSC, so I will need to track 100% heal HS casts separately so they don't inflate the cast counts.

I would then divide the healing done by the cast time of the heals used to top off the tank, and find the Healing per Cast Time (HPCT) for that simulation. If your gear is better, you would do the same amount of healing, but cast for less time, so this value would increase, even though your total fight time and total healing done and effective HPS were all identical.

Opinions?

So what I should be doing is modeling incoming boss damage. Perhaps as settings the user can choose: Boss attack damage, boss swing time interval. If a boss hits for 5k every 10s, that's 2000DPS, but it comes in a single chunk, and you then have 10s to refill it based on your abilities and cooldowns.

 

At low levels of gear where you exactly match the boss DPS, you should have a fairly high cast count. At higher levels of gear, for the same fight length, you should have a lower cast count, corresponding to filling the tank up and then waiting. For a Commando, I would fill that downtime with some Hammer Shots just to keep up CSC, so I will need to track 100% heal HS casts separately so they don't inflate the cast counts.

 

I would then divide the healing done by the cast time of the heals used to top off the tank, and find the Healing per Cast Time (HPCT) for that simulation. If your gear is better, you would do the same amount of healing, but cast for less time, so this value would increase, even though your total fight time and total healing done and effective HPS were all identical.

 

Opinions?

I believe I tried to hint at this in one of your earlier posts about your modeling and its lack of Kolto Bomb. You'd have to figure in swing timers, tank defense chance, etc. This would be a large undertaking and should change the numbers on a few abilities.

I believe I tried to hint at this in one of your earlier posts about your modeling and its lack of Kolto Bomb. You'd have to figure in swing timers, tank defense chance, etc. This would be a large undertaking and should change the numbers on a few abilities.

I think you could simplify it by using a swing timer and the damage received. You don't need to model the boss base damage and then mitigate it, you can simply say "on average, the tank gets hit for 5k damage, every 5 seconds." It is overkill to say "The tank gets hit for 12.7k, but avoids 22% and mitigates 57.6% of the damage and therefore only receives X damage that you now need to heal."

With combat logs in 1.2, it should be possible to get some very good estimates to put in that field. For now I can simply use various dummy numbers and plot curves based on them.

I think these new charts demonstrate what I'm getting at.

This is a chart showing the HPCT when the boss DPS exceeds the possible HPS for your gear. This assumes a boss is doing 8.6k every 5s, and the healing does not keep up. Chain casting ensues, using the best ability possible by the logic I posted before, and the assumption that it is needed to heal now, because the damageToHeal variable is > 0.

Note that this looks very, very similar to the earlier plots I posted of HPS with stats.

This chart shows the same curves, but when the boss does 5k damage every 5s. This damage is heal-able with downtime, and the curves look very different from before. The stair-stepping that is seen in a few places is likely caused by when you have a just a little damage left to heal, but it takes at least 1.5s to do so, then you increase your stat and now that previous heal covered it and no 1.5s extra heal is needed. This decreases your cast time by at least 1.5s per attack period, and causes a positive jump in the HPCT.

There is still an odd dip at 740-905 Alacrity, but in general it is much smoother than before and shows a positive trend with Alacrity.

This could all probably be cleaned up even more if I add in checks to not cast a 2k Heal if only 100 HP needs healing. I think I am also adding the over-healing in right now. If I switch to trying to not cast big heals when a small one will do I will certainly need to stop counting overhealing.

I think you could simplify it by using a swing timer and the damage received. You don't need to model the boss base damage and then mitigate it, you can simply say "on average, the tank gets hit for 5k damage, every 5 seconds." It is overkill to say "The tank gets hit for 12.7k, but avoids 22% and mitigates 57.6% of the damage and therefore only receives X damage that you now need to heal."

 

With combat logs in 1.2, it should be possible to get some very good estimates to put in that field. For now I can simply use various dummy numbers and plot curves based on them.

Wouldn't it be important to model defense chance in order to accurately model time spent at max HP? If your tank gets healed up, then dodges two attacks in a row, you're just sitting there waiting for the next attack.

Wouldn't it be important to model defense chance in order to accurately model time spent at max HP? If your tank gets healed up, then dodges two attacks in a row, you're just sitting there waiting for the next attack.

That just adds RNG that isn't needed.

You can model that into the mitigation for the tank:

Expected Damage Taken = (1-avoidChance)*(1-armorDR)*[(1-bossCritChance - shieldChance)+bossCritChance*(1+bossSurge)+shieldChance*(1-absorb)]

In practice you need some min and max values you in there for if shield+bossCrit chances total more than one, but that would just clutter the above.

There is some additional estimation you can do of the "spikyness" of the damage, to compare a mitigation tank to an avoidance tank. In general if your HPS exceeds the expected DPS, you are fine, but if it is too spiky, the tank might still die. If you have a boss with 1k DPS, but the boss hits once every 30s for 30k and your tank only has 20k life...nothing you could do there. Similarly a tank with 99% avoidance who dies to a single hit is worthless, but tanks aren't actually designed like that so its not a concern. For our purposes tank expected DRPS (Damage Received Per Second) should be sufficient.

This is what I'm starting to move to, what I'm calling Healing per Required Cast Time (HPRCT) for lack of a better name.

In short, I have a boss doing X DPS. I put in checks so I don't over-heal, and then I run the traditional rotation logic to heal if there is damage that needs it. Otherwise I cast HS to build up CSC charges. If there is only a little damage, I will cast HS as well, but I don't count that time...because I'm luxury healing, not required healing. The tank doesn't need to be at 100%, and with our cooldowns and resources it doesn't make sense to burn a 10% heal to restore 5% health. But, if you have nothing else to do but stand around and /clubdance, you might as well fire off some free fillers and edge that health pool up from 95-96%, right?

So what does this look like? Well, it depends on the chosen DPS and if you can keep up with a given gear set.

At 1000DPS, with the stats I had saved, I can easily heal it no problem and we get this odd graph.

However, if we set the DPS to 1350, which is a value I found through trial and error for that gear set, such that if I drop to 0 Power the tank dies, but he lives with the actual power value...we get this graph. Note that it looks a lot like the actual DR curves for the stats themselves, and we see that Alacrity is actually of good value here. This is when the healing is non-trivial, but increasing Alacrity lets you increase your down-time to stand around, think, move, etc.

Then we get to the 2000 DPS plot...and suddenly Alacrity is far less valuable. This is a DPS level that the gear can't keep up with, and as a result it is chain casting like a champ...doing the old sustained HPS calculation essentially, and the benefits for Alacrity get offset by the fact that you are chain casting and can't afford to stop. In fact, at 2k DPS and a 10s swing timer the tank died around the second hit even in top end gear.

Opinions?

Created this one, which does runs of 100 DPS intervals from 1000-2000 boss DPS, from trivial to lethal, and averages the results.

It is interesting that, despite the variance in the ability selection, the result closely resembles the DR curves for the stats.