Jump to content


Photo

Usage Calculator - A theory crafting tool


  • Please log in to reply
16 replies to this topic

#1 Rurahk

Rurahk

    Von Kaiser

  • Members
  • 43 posts

Posted 04 December 2010 - 02:35 AM

I have created a theory crafting tool for determining how various priorities, haste, hit, expertise, and mastery affect ability usage. The strengths of this tool is that it will provide exact numbers rather than estimates, but the downside to this is that calculating a fight can take a lot of time.

Basic Info
The basic design of the tool is to exhaustively test every branch for the number of abilities used and the probability of that specific branch. This will assign a firm number to a damage dealing ability according to the mechanics as they are currently understood. The tool is NOT a simulator and thus will not provide an estimate - it provides exact numbers. It does this by branching at every choice where the RNG will pick a specific outcome - e.g. one branch for a Hand of Light proc on weapon swing, a second branch for no Hand of Light proc. The probability of the branch is calculated based on the mechanics - e.g. the chance that a HoL proc will occur is 8% + mastery, Art of War is 20% (when fully talented), etc.

What this tool is not
To avoid duplicating the efforts of Redcape and Exemplar, this tool will NOT calculate dps. The intent is that the usage information can be multiplied by the average damage that each ability will do for a specific gear set (these numbers could be provided by Redcape's/Exemplar's spreadsheets or could be from a direct parse) to get the total dps. The numbers could then be compared for different priority systems and/or different levels of haste, hit, expertise, and/or mastery. These four stats, priority, and talents are the only things that will affect the rotation. Specific talents and any other stats that just modify damage done (Str, crit, Pursuit of Justice talent, etc) are not modeled.

If you're interested in some of the internal details, open up the spoiler below.
More Details
Spoiler


This tool is a work in progress
I am posting a link to this tool mainly to get feedback, in both the mechanics department and in the programming department. Mechanics need to be verified for accurate results, somewhat obviously. Therefore, until the mechanics have been reviewed, all numbers generated from this tool should be taken with a grain of salt. For programming help the main issue is run time. Currently, a 20 second fight will calculate for 3-20 minutes depending on options selected. A 25 second fight can calculate for hours. Currently the algorithm is depth-first recursive. If I can re-implement the inner loop to be a breadth-first recursive I may be able to prune certain branches (e.g. branch 1 has Judge-no DP + HW-DP, branch 2 has Judge-DP + HW-no DP so the end result is 1 Holy Power, Judge and HW on CD for both branches so prune one and double the probability or something similar). Another idea to help with the calculation speed is to re-implement the system in a faster language, such as C/C++. However a faster language (as opposed to improving the algorithm) might not necessarily help much in the long run, since, e.g. halving the time it takes to run the inner loop isn't going to amount to much when a 300 sec fight is currently estimated to take billions of years to complete.

Example of how the tool could be used
Times greater than about 25 seconds can take hours of calculation time, but by happy coincidence the duration of AW and Zealotry is 20 seconds. So, I was able to compile a table of AW vs Zealotry vs AW+Zealotry. The priority system used was TV (3 HP) -> CS -> TV (HoL) -> J -> HoW -> Exo -> HW -> Cons, with the two different priority systems. One model is where a filler is used only if there is enough time left for the GCD before CS comes off CD (filler_wait=TRUE). The filler_wait=FALSE model is where a filler is used whenever it is off CD regardless of how much time there is before the next CS.


Changelog
2010-12-16: removed out-dated data tables. Fixed a major bug where Hammer of Wrath effectively had no cooldown. Added several reporting options to the accumulator class. Added different priority systems. Added a ret_rot_no_comments.py to the bundle - this demonstrates iteration through priorities.
2010-12-09: another bugfix, uploaded new files (including accumulator.py) - results are now consistent. Docs need cleanup.
2010-12-07: bugfix, not uploaded (still some inconsistencies I need to track down)
2010-12-05: updated links & added info about AW
2010-12-03: original post

#2 Pdawg

Pdawg

    Von Kaiser

  • Members
  • 61 posts

Posted 04 December 2010 - 03:26 AM

[TABLE="head"]AW|Zealotry|filler_wait|TV|CS|Judge|Exo|HW|Cons|HoW
No |Yes |TRUE |6.402710856 |4.99641079 |0 |0 |0 |0 |0
Yes |Yes |TRUE |7.483253027 |5.995692948 |0 |0 |0 |0 |0
[/TABLE]

I believe the 7.48... should actually be 7.68...

#3 Rurahk

Rurahk

    Von Kaiser

  • Members
  • 43 posts

Posted 04 December 2010 - 09:38 AM

I believe the 7.48... should actually be 7.68...

I re-ran the numbers and I'm still getting 7.48... for filler_wait = True, with AW and Zealotry used.

What specifically did you do to get 7.68...? If you set filler_wait = False, the TV number is 7.69... - perhaps this is what you are seeing?

#4 sjogren

sjogren

    Piston Honda

  • Members
  • 168 posts

Posted 04 December 2010 - 12:05 PM

[TABLE="head"]AW|Zealotry|filler_wait|TV|CS|Judge|Exo|HW|Cons|HoW
No |No |TRUE |3.543947074 |4.974189406 |2.261222207 |0.464085927 |0.353091276 |0.047398601 |0
Yes |No |TRUE |4.138557748 |6.028350549 |2.256255382 |0 |0 |0 |1.032341551
No |Yes |TRUE |6.402710856 |4.99641079 |0 |0 |0 |0 |0
Yes |Yes |TRUE |7.483253027 |5.995692948 |0 |0 |0 |0 |0
No |No |FALSE |3.387333622 |4.689134518 |1.996955621 |0.993900373 |1.032163337 |0.865547704 |0
Yes |No |FALSE |4.873985085 |6.05808626 |2.090919698 |0 |0 |0 |4.928163558
No |Yes |FALSE |5.479996723 |4.98724096 |1.96541911 |0.802573755 |0.605817126 |0.158952325 |0
Yes |Yes| FALSE |7.696333592 |7.678973072 |2.076254446 |0 |0 |0 |2.608437849
[/TABLE]

I'm not sure I understand... This is number of usages in a 20s fight, yes? The last line shows over 20 ability usages, which would be 30s worth of fight time.

Also, with 0 haste and 0 latency, the CS cooldown would be 4.5s and filler_wait would be irrelevant, would it not? You'd always have time for a filler. Or are you taking raid buffs into account?

Edit: Also, I'm unable to download the python files, getting file not found errors.

#5 Rurahk

Rurahk

    Von Kaiser

  • Members
  • 43 posts

Posted 04 December 2010 - 06:02 PM

I'm not sure I understand... This is number of usages in a 20s fight, yes? The last line shows over 20 ability usages, which would be 30s worth of fight time.

Also, with 0 haste and 0 latency, the CS cooldown would be 4.5s and filler_wait would be irrelevant, would it not? You'd always have time for a filler. Or are you taking raid buffs into account?

Edit: Also, I'm unable to download the python files, getting file not found errors.


To simulate AW's increased damage, I increment the ability count by 1.2 instead of 1 when AW is active - otherwise I would have to maintain a separate list of abilities when AW is up, for those cases when AW is not active for the entire duration. Also, since a standard 85 build has Judgements of the Pure, there is a 3/6/9% melee and spell haste buff every time a judgement hits (depending on talent points). For the 20s fight, I manually added the JotP buff because I wanted to start out with a TV instead of a judge.

These two factors should account for the "extra" abilities. If not, there could very well be a bug in the program, but I cannot find it - part of the reason why I need feedback.

As far as filler_wait goes, if the variable is set to False, then potentially there could be 2 fillers during the ~4.13 CS cooldown. Using a spell gcd after CS would leave ~1.25 seconds left until CS cooled down which is not enough for a second hasted GCD. Thus if filler_wait is True, then at most one filler should be used between Crusader Strikes.

When downloading the files make sure you right click and "save link as..." instead of left-clicking on the link on the google docs page. If you left click, depending on your browser, your computer may try to run ret_rot.py, which requires abilities.py to run. Alternatively, you can download the .zip file.

#6 Daler

Daler

    Bald Bull

  • Members
  • 1216 posts

Posted 06 December 2010 - 07:12 PM

These two factors should account for the "extra" abilities. If not, there could very well be a bug in the program, but I cannot find it - part of the reason why I need feedback.


It doesn't, at least by my napkin math. After reducing the HoW usage by 20%, you're still at almost 30 seconds worth of GCD usage. My guess is that you're applying haste to the GCD reduction, not just the CD reduction from JOTP, but I haven't checked. Note that only HW and Exo have their GCD reduced by haste.

Also, not to be a wet blanket, but I'm not sure the purpose of this tool is anything superior to what we have in Redcape's spreadsheet, as Redcape's spits out the ability usage totals for each pass. It also allows us to test priority changes, etc. over a much longer period of time. So since we already have to use a spreadsheet to determine average damage for the abilities to extrapolate DPS changes, which also gives us the resulting ability usage totals, why would we then come to your tool to get the (almost) exact same information, especially since there's such a prohibitive time limitation to your program?

Just my two cents, by all means continue developing this program. I'm just not sure its worth the effort to construct such a limited tool. It seems to me like you're re-inventing the wheel for no appreciable gain in value.

#7 Exemplar

Exemplar

    The One-Eyed Man

  • • Guide Author
  • 1824 posts

Posted 06 December 2010 - 08:03 PM

Once this program is refined and assuredly accurate, it could be used directly with my spreadsheet, if desired. You could simply plug the number of attacks (within and outside of AW) generated by Rurahk's program into the DPS Calc tab of my spreadsheet (beta version just released) and override the simulation-derived values.

Looks like you could do the same with Redcape's, just fill in J28 through K30 on Main and it would give you a "true" DPS value.

Unfortunately, due to the nature of a true RNG, in game results will wildly vary from Rurahk's numbers just as much as from Redcape's or mine. Ret has a huge RNG shift, with Mastery, Divine Purpose, and Art of War all hinging off it (not to mention the normal issue with crits).
Rock: "We're sub-standard DPS. Nerf Paper, Scissors are fine."
Paper: "OMG, WTF, Scissors!"
Scissors: "Rock is OP and Paper are QQers. We need PvP buffs."

#8 Daler

Daler

    Bald Bull

  • Members
  • 1216 posts

Posted 06 December 2010 - 08:46 PM

edit: This will quickly devolve into yet another take on the simulation vs. modeling argument, so I'll just bow out now. No need to rehash that old chestnut yet again.

#9 Rurahk

Rurahk

    Von Kaiser

  • Members
  • 43 posts

Posted 07 December 2010 - 12:45 AM

It doesn't, at least by my napkin math. After reducing the HoW usage by 20%, you're still at almost 30 seconds worth of GCD usage. My guess is that you're applying haste to the GCD reduction, not just the CD reduction from JOTP, but I haven't checked. Note that only HW and Exo have their GCD reduced by haste.

You are correct - even with everything set to a hasted GCD of 1.25 there should only be at most 17 abilities used (with one being used at time 0 and the last being used at time 20). Keep in mind that since Zealotry and AW are active with no waiting for fillers, most branches should have 100% GCD usage. 17*1.2 = 20.4, while my program calculated 20.06. I am absolutely certain that the melee GCD is 1.5 (there is no funny stuff about this, the ability.melee_gcd function consists of "return 1.5") but I am not 100% certain that the melee GCD function is called for the correct abilities, since during optimization I may have incorrectly swapped functions. I will verify this tomorrow.

edit: This will quickly devolve into yet another take on the simulation vs. modeling argument, so I'll just bow out now. No need to rehash that old chestnut yet again.


The largest issue that this tool is intended to solve is to nail down a relative value for haste, especially with regards to varying priority systems, which is the only major weakness (in my eyes) of the various spreadsheets. This is my (possibly misguided) attempt to cover that gap.

Today it occurred to me that mastery, hit, and expertise only vary the relative probabilities of branches, e.g. make it slightly less/more likely for a specific branch to be taken. The order of abilities does not change. Haste and priority change the order itself, which is why it's so difficult to model these. I'm hoping to generate a table with various haste values for each priority system, which can then just be a look up that can be plugged into a dps tool, be it a spreadsheet or a full blown program such as Rawr.

I have been notified that the links to the program are not working - I believe I have fixed the issue but I need someone to test.

I've fixed a couple of bugs with the way char.reset() works, which shouldn't change any posted numbers since they were one-off runs. However, when a loop is run to calculate incremental changes (e.g. for mastery values of 100, 200, 300, etc), the numbers were not resetting to zero correctly. This has been fixed and I have uploaded a new version the files. This version also demonstrates looping, with haste being calculated from 100 to 2000 rating. I have not thoroughly reviewed the comment structure since applying the loop, so I will shortly upload the original version.
EDIT: original ret_rot.py

EDIT2: I have found and fixed the bug - GCDs were correct, but the end conditional was incorrectly allowing abilities to be used after the time had expired. I need to clean up the comments and double check a few things before posting. I also fixed a bug where Judgements and Consecration were not correctly modified for the AW 20% increase. I will update the original post probably some time tomorrow with better numbers.

EDIT3: Another bug found and fixed - this one was providing inconsistent results because of buff/debuff priority ordering. I've also split accumulate_results() into a different file because I want to experiment with different types of accumulators. I may have some time tomorrow to fix up docs - for now they are a bit chaotic in the most recent versions. The reaction to this tool being lukewarm, I won't worry too much about updating regularly until everything is in more of a finished state. The newest file is here.

EDIT4: Been out of the loop for a couple of days because someone decided to travel the wrong way in the lane I was using - no one was hurt but the car is a loss.

Added several more options to various things - it is now possible to model 1 or 2 filler abilities before the TV(3) > CS > TV(HoL) part (e.g. HoW > Exo > TV(3) > CS > TV(HoL) > HW > Cons). After all the edits, I will need another day or so to make sure the obvious bugs are squashed and that the comments still make sense, so I will most likely update new versions of the files tomorrow.

I have also been having the calculator running several series of priorities - the results are not complete yet, but the gist is HoW > Exo > HW > Cons for nearly every series. In addition, for all series without exception (so far), 2 fillers are better than one wait for CS at 0 haste and mastery. I'm running a calculation with 2000 haste to see if/how that changes things but it's estimated to take 12-20 hours - if the machine doesn't reboot then I'll hopefully have numbers tomorrow.

I'm making little progress on breadth first calculations - I think I've figured how to iterate over the various sequences, but I'm not sure how to store state.

#10 Rurahk

Rurahk

    Von Kaiser

  • Members
  • 43 posts

Posted 17 December 2010 - 12:13 AM

Some interesting results came out of the runs I did today. I did 17 second runs because 20 second runs for some priorities were going to take ~70-80 hours to complete and I will be unable to post for a week or so after tomorrow.

Below is a table of the top 5 priorities ranked by dps, for each the TV(3) > CS > TV(HoL), P1 > TV(3) > CS > TV(Hol), and P1 > P2 > TV(3) > CS > TV(HoL) systems (henceforth called P0, P1, and P2, respectively). I didn't model Consecration for any priority except dead last place because of mana constraints.

[TABLE="head"]P0 Rotation|Normal|AW|Zeal|Total
HoW<Exo<HW<J<Cons|15920.4940621289|21969.020753112|18793.9617487054|17407.4931250555
Exo<HoW<HW<J<Cons|15920.4940621289|21990.620751154|18793.9617487054|17411.0931247292
Exo<J<HoW<HW<Cons|16118.1845534783|21399.8886702027|18829.7645766578|17450.3985767955
HoW<Exo<J<HW<Cons|16118.1845534783|22052.5367595128|18829.7645766578|17559.1732583473
Exo<HoW<J<HW<Cons|16118.1845534783|22071.8150789871|18829.7645766578|17562.386311593
[/TABLE]

[TABLE="head"]P1 Rotation|Normal|AW|Zeal|Total
HoW<HW<Exo<J<Cons|15857.1986658194|22321.5720383252|18686.7255709215|17406.1820454207
HoW<J<Exo<HW<Cons|16023.1533840669|22154.3314876307|18523.2491328708|17461.6990261282
Exo<HoW<J<HW<Cons|16052.8013787547|22080.23367709|18582.7911908627|17479.0383971619
HoW<Exo<HW<J<Cons|15920.4940621289|22415.0576465726|18793.9617487054|17481.832607299
HoW<Exo<J<HW<Cons|16118.1845534783|22485.6448395454|18829.7645766578|17631.3579383527
[/TABLE]

[TABLE="head"]P2 Rotation|Normal|AW|Zeal|Total
HoW<HW<Exo<J<Cons|15595.5567128963|21767.205458502|17878.3499249258|17004.6303725022
Exo<HoW<HW<J<Cons|15860.4258577455|22375.0341345271|18546.0638259139|17393.8002319038
HoW<Exo<HW<J<Cons|15860.4258577455|22484.5464292686|18546.0638259139|17412.0522810274
Exo<HoW<J<HW<Cons|16052.8013787547|22368.5485416818|18582.7911908627|17527.0908745939
HoW<Exo<J<HW<Cons|16052.8013787547|22489.3664652642|18582.7911908627|17547.2271951909
[/TABLE]

Highest damage for normal is underlined, highest damage for AW is bolded, highest damage for Zeal is italicized.
The TL;DR version is that prioritizing HoW and Exo over TV/CS is apparently a dps loss except under Avenging Wrath (assuming that my tool is correct, of course).

Latency was set to .2 (add 200 ms to the end of cooldowns) and reaction was set to .2 (add 200 ms to AoW and HoL proc times). Consecration was modeled as a single cast (no ticks) but Censure was modeled as ticks. Haste and mastery were 0, hit and expertise were capped.

I used Redcape's spreadsheet (verson 5.12) for the raw damage data - I have numbers for Exemplar's spreadsheet but the default values are T10 BIS plus I had to massage the numbers a bit and I don't trust that I did that error free. Exemplar's data show essentially the same thing except slightly higher P0 and P2 numbers for HoW<Exo<J<HW<Cons under AW.

I realize that several dps numbers are exactly the same - the reason is that HoW is only utilized during AW. Part of this shows in P1 calculations: when HoW is in the #1 priority slot then non-AW calculations behave as if it were P0, again since HoW is unavailable.

#11 Redcape

Redcape

    King Hippo

  • Members
  • 543 posts

Posted 17 December 2010 - 04:11 PM

I should point out that the HOW/Exo being above TV in priority were initially based on my spreadsheet's simulations but those simulations were weakly conclusive. Swapping the ordering around between Exo/TV/HOW generated changes in dps in the 100-200 ballpark when the overall dps was 18k+. This means that your exact ordering of abilities is not very impactful at all and that very slight changes in simulation details could easily tip the balance.

The same was true with refreshing Inq early, pushing back Consecration, Judgement, and HW for CS/HOW casts and other reasonable alterations. As long as you use the obviously better attacks (HOW, CS, TV, Exo) before the obviously inferior ones and refresh Inq in some reasonable fashion your dps is going to be within a tiny fraction of the 'ideal'. Of course hitting the ideal is our goal but we should be reasonable in saying that when our spreadsheet's simulations for various choices come within 1% of one another that we are well within the margin of error and should consider the data in that light.
My Ret paladin spreadsheet: ->here<-

For questions regarding my spreadsheet or otherwise please contact me via PM on the EJ boards and not in game. Thanks.

Philosophy, Psychology and other fun stuff:

WOW and gaming in general:

#12 Exemplar

Exemplar

    The One-Eyed Man

  • • Guide Author
  • 1824 posts

Posted 17 December 2010 - 05:32 PM

Wouldn't these numbers vary based on crit rate, haste (# of eligible Exo/HoL), base weapon damage and AP?

A higher or lower base weapon damage would significantly alter TV and CS compared to HoW and Exo. Enough so that there would be inflection points for base weapon and AP where you could have TV/CS before HoW/Exo change to HoW/Exo before TV/CS. Haste generating more autoattacks, thus more procs, would drive towards higher possibility of lost procs in the lower priority sequence.

Reaction is also most likely far too high. The majority of HoL and AoW procs will be early enough during a GCD that your reaction would be over and you could pre-queue them during that same GCD with no lost time. Only when it procs very late during a GCD could your reaction cause an active delay, and then rather than a delay you're likely to have another ability pre-queued and automatically go off (assuming you have one off CD).

My spreadsheet is figuring out priority "on the fly" based on comparative damages (including HP generation of attacks) and I'm continually seeing HoW and Exo ahead.

Bottom line, though, I believe Redcape is correct - priority in either direction is sub-1% damage change.
Rock: "We're sub-standard DPS. Nerf Paper, Scissors are fine."
Paper: "OMG, WTF, Scissors!"
Scissors: "Rock is OP and Paper are QQers. We need PvP buffs."

#13 Rurahk

Rurahk

    Von Kaiser

  • Members
  • 43 posts

Posted 17 December 2010 - 10:46 PM

I should point out that the HOW/Exo being above TV in priority were initially based on my spreadsheet's simulations but those simulations were weakly conclusive. Swapping the ordering around between Exo/TV/HOW generated changes in dps in the 100-200 ballpark when the overall dps was 18k+. This means that your exact ordering of abilities is not very impactful at all and that very slight changes in simulation details could easily tip the balance.


Indeed - in fact, the numbers in the table are all within 1-3% of each other. I view this more as confirmation that my model is working well rather than as a problem with anyone's spreadsheet. I am by no means arguing that the spreadsheets are wrong, but I'd like to eliminate the uncertainty factor that currently exists.

Wouldn't these numbers vary based on crit rate, haste (# of eligible Exo/HoL), base weapon damage and AP?

A higher or lower base weapon damage would significantly alter TV and CS compared to HoW and Exo. Enough so that there would be inflection points for base weapon and AP where you could have TV/CS before HoW/Exo change to HoW/Exo before TV/CS. Haste generating more autoattacks, thus more procs, would drive towards higher possibility of lost procs in the lower priority sequence.

Reaction is also most likely far too high. The majority of HoL and AoW procs will be early enough during a GCD that your reaction would be over and you could pre-queue them during that same GCD with no lost time. Only when it procs very late during a GCD could your reaction cause an active delay, and then rather than a delay you're likely to have another ability pre-queued and automatically go off (assuming you have one off CD).

My spreadsheet is figuring out priority "on the fly" based on comparative damages (including HP generation of attacks) and I'm continually seeing HoW and Exo ahead.

Bottom line, though, I believe Redcape is correct - priority in either direction is sub-1% damage change.


Exactly, this is why I have plugged in numbers from the spreadsheets. Crit, weapon damage, and AP would not change the order in which buttons are pressed and this order is what my tool determines. In fact, if you were to change the numbers on your spreadsheet, plug those numbers into my results, then you would see the values of various priorites change. For instance, setting HW to do 50,000 damage per hit shows HW as the first priority being top dps without having to re-run any calculations.

Only hit, expertise, mastery, weapon speed, and haste change ability usage, the other stats change damage numbers. It would be different if any of our abilities procced from crits, like Conviction for instance. Even mastery, hit, and expertise don't change the order of abilites pressed except at 0% and 100% - they just alter the chance of a specific sequence happening.

Mastery example:
8% mastery (base)
branch 1: J > Weapon Hit > HoL proc > TV 8%
branch 2: J > Weapon Hit > CS 92%

20% mastery
branch 1: J > Weapon Hit > HoL proc > TV 20%
branch 2: J > Weapon Hit > CS 80%

Mastery just changes the percents (8%->20% and 92%->80%) but you would still hit TV after a HoL proc, and CS if it didn't proc (based on your priority system of course). The same logic applies to hit and expertise, with the simplest example being if you missed a TV, you would hit the TV button again. Being hit and expertise capped merely sets the probability of an enormus number of branches to 0. (Incidentally, being mastery capped would do the same, but for obvious reasons I don't have provisions for this in my tool). Haste and weapon speed alter the timing of procs and thus need seperate calculations. Prioirty changes also change which buttons you press and so the value of these three variables is what I hope to nail down. The effects of latency and reaction time can also be definitively used to support arguments (totally made up and rediculous example: hey blizzard, right now the the difference between 100 ms latency and 200 ms is 2k dps, but if you remove the CD on CS it would only be 200dps).

Part of what I hope my tool will evenutally be able to do is find things like the inflection point where it's better to prioritize HoW and Exo over TV and CS, or any other combination of priorities. Another, more immediate thing I'd like to prove is that mastery is one of the worst stats for paladins in the hopes that Blizzard will pay attention and fix it. They can even download my tool to try out various options (such as making HoL proc TV similar to Sudden Doom for DKs) without going through the trouble of implementing it in-game (since my tool is obviously superior to any existing tools they might have).

As far as reaction time, all the calculator does is add .2 seconds to when AoW or HoL is available to be used (proc time + .2) - the majority of the time (with a maximum of 1 - .2/1.5 = 87% of the time) the proc will occur early enough during a GCD to not matter. However, when a proc pops up when you're waiting for an ability to come off CD, then Exorcism (for instance) will not be pressed as soon as Art of War happens - it will happen some time later depending on your reaction time, or even a whole GCD later if you've been spamming CS and just prior to the cooldown ending, AoW pops. If the reaction time variable didn't exist, then AoW would be pressed before CS. In other words, I understand what you are saying and I believe I have appropriately accounted for it.

I understand that tweaking priorities can be extremely fine-grained (on the order of a few percent) but I was under the impression that this forum is dedicated to such detailed analysis. As a random example, swapping all my +40 str gems for +20 str/+20 haste gems might drop my dps by less than a percent too. Setting up clcinfo with a proper rotation to net the same type of increase as properly gemming my gear seems worth it to me.

#14 Redcape

Redcape

    King Hippo

  • Members
  • 543 posts

Posted 18 December 2010 - 03:39 PM

It is important to make the distinction between small improvements we can reliably measure and small improvements we cannot reliably measure.

I can tell you with extreme precision how much str is worth compared to crit. It is worthwhile figuring out the optimal gemming strategy in str vs. crit because we aren't guessing at all and if it shows a 1 dps increase using a particular strategy I can say with total confidence that strategy is strictly better. That is *not* the case when rotations and modelling become extremely relevant like when evaluating haste and mastery. Slight changes in fight conditions, reaction times, modelling styles and other factors introduce noticeable errors into our calculations, and when our known margins for error are larger than an observable difference between various setups we simply cannot say that we know which setup is superior. Of course we have to take our best guess and try to maximize our use of the data we have but we should not conceal the fact that nobody has data that conclusively shows the best rotation, nor the exact value of haste or mastery. If my spreadsheet showed a particular rotation at 1k dps above the others I would say for sure it is the best - that is far greater than my margin of error. None of them approach that value though.

We need to make best guesses for guides but when really theorycrafting it is critical to acknowledge what we know for sure and what is just a best estimate.
My Ret paladin spreadsheet: ->here<-

For questions regarding my spreadsheet or otherwise please contact me via PM on the EJ boards and not in game. Thanks.

Philosophy, Psychology and other fun stuff:

WOW and gaming in general:

#15 Exemplar

Exemplar

    The One-Eyed Man

  • • Guide Author
  • 1824 posts

Posted 18 December 2010 - 09:18 PM

Exactly, this is why I have plugged in numbers from the spreadsheets. Crit, weapon damage, and AP would not change the order in which buttons are pressed and this order is what my tool determines. In fact, if you were to change the numbers on your spreadsheet, plug those numbers into my results, then you would see the values of various priorites change. For instance, setting HW to do 50,000 damage per hit shows HW as the first priority being top dps without having to re-run any calculations.


Why would crit, weapon damage, and AP not change the order? They would affect the raw damage of abilities input into your tool and thus provide different endpoints of "best damage."

Examples:
CS and TV crit at 200% while Exo Crits at 150%. As crit rises it will grants CS and TV more than it does Exo. There would thus be an inflection point (albeit possibly far beyond gearing possibilities).
AP scales all your attacks. Weapon damage again would only scale CS and TV compared to HoW and Exo.

Since the values of the priorities change the priority which earns the label "best" also changes.

I'm not arguing against the tool's usefulness. It produces valid results. You've simply posted the equivalent of a single data point - one precise set of gear. If someone wants to use this tool to decide their own priority sequence they should input the numbers from their specific gear then run the sequences you have already outlined.
Rock: "We're sub-standard DPS. Nerf Paper, Scissors are fine."
Paper: "OMG, WTF, Scissors!"
Scissors: "Rock is OP and Paper are QQers. We need PvP buffs."

#16 Rurahk

Rurahk

    Von Kaiser

  • Members
  • 43 posts

Posted 20 December 2010 - 03:12 AM

It is important to make the distinction between small improvements we can reliably measure and small improvements we cannot reliably measure.
...
We need to make best guesses for guides but when really theorycrafting it is critical to acknowledge what we know for sure and what is just a best estimate.


I had never thought of it that way, and I agree wholeheartedly. One of the ideas I have been considering is something similar to "error bars" where the highs and lows can be calculated and weighted somehow - to give an idea of how variable a setup could be and thus how much RNG can "blamed" for variations. Another derivative could possible discover the relative "bursty-ness" of a setup. I don't quite know how to go about this however.

I understand that there are many, many variables that cannot be modeled with any degree of accuracy. Some of these things are what separate bad players from good players - others are just the nature of the game. Hopefully we can eliminate or narrow down some of the variables that can be modeled.

Hopefully the tool will be flexible enough to help decide on things such as when the best time to use consecrate is (any time above 80% mana? only during AW?) or if a P0, P1, or P2 rotation is best when CC prevents the use of Cons and HW, or whether swapping seals to dps adds is a waste of a gcd for specific fights.

Why would crit, weapon damage, and AP not change the order? They would affect the raw damage of abilities input into your tool and thus provide different endpoints of "best damage."
...
I'm not arguing against the tool's usefulness. It produces valid results. You've simply posted the equivalent of a single data point - one precise set of gear. If someone wants to use this tool to decide their own priority sequence they should input the numbers from their specific gear then run the sequences you have already outlined.

But I don't input raw damage totals into my tool. I have cobbled together a spreadsheet that multiplies the usage info spit out from my program with the info provided from the spreadsheets. Once the user decides on a priority, haste, and weapon speed, the values of crit, weapon dps, AP, etc would not affect the outcome of button presses. The damage various abilities produce might alter the user's selection of priority, don't get me wrong, but once set, the priority wouldn't change for that calculation.

I hope to reduce each (priority/haste/weapon speed) triplet down to a formula that has as terms mastery, hit, and expertise. These formulae could then be plugged into a spreadsheet which would provide the AP/crit/weapon damage range/trinket procs/etc to give a final damage number.

Another way to say it is the program doesn't try to come up with a priority - this is input into the program before a calculation. It's up to the user to interpret the data to pick the best rotation. Your spreadsheet, from how I understand it, goes a step further and sets priorities based on damage done. This requires the user to press a button to re-calculate when haste values and weapon speeds change - imagine how much more convenient it would be if this could be done by lookup. I'll need to implement several more things before this becomes a reality - including Inquisition and mana usage, but also some way to reduce the current usage info in to a formula. I am aware that the numbers I posted are from one specific gear set - perhaps I could have made this clearer in my post - but the end result will be to make analyses of different gearing options quicker and more accurate.

#17 Rurahk

Rurahk

    Von Kaiser

  • Members
  • 43 posts

Posted 11 January 2011 - 05:42 AM

Re-implemented for 4.0.6 changes. Calculation times improved with the change, only 2 RNG branches (AoW and DP) instead of 3. I ran a bunch of numbers with old values for ability damage, then discovered a bug where only haste rating was applied to Censure (no JotP for instance) so I am re-calculating. Preliminary results indicate that the changes are a dps gain. My crude modeling of 20 seconds worth of fight show that using AW + Zeal is a dps loss over using them separate. I use the following formula:

separate:
(AW_dps + Zeal_dps + 4*Normal_dps)/6

synchronized:
(AW_and_Zeal_dps + 5*Normal_dps)/6

The numbers do not include GoAK or Inquisition so those might tip the balance in favor of synchronized CDs. Dps values are within 2% between separate and synced.

I will post numbers soonish, as well as updated files.

UPDATE: 1/18/2011 - Life crit me in the face so I have had minimal time to work on this. I have managed to get a breadth-first calculator running, the gains are not as much as I'd hoped but I still have some optimization tricks I can try. On the up side, a 30 second run can now be calculated in less than a day - less than an hour in fact. I have not had time to run numbers, but since time frames are currently too short to model Inquisition fully the numbers are not accurate anyhow.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users