As such u base it on 12 seconds and then if its at least once per 12 seconds it will be up forever unless you are terribly unlucky? >.< Okay It wont be easy to calculate, perhaps even impossible.. Hmm let me give this some thought
You've hit upon the central issue. Once it's up, how long does it stay up? I mean, probabilistically speaking, it's guaranteed to drop eventually, but how long does it take? 30 seconds? A minute? 5 minutes? A little investigation is sufficient to show that the answer is *not* that it stays up indefinitely; by our continuous-case approximation, we're guessing that the answer is more like a minute or two. But figuring out exactly what that number is - and how quickly it stacks up in the first place - and thus what the overall average uptime is - is the hard part of this calculation.
As such , is it possible to obtain enough hit,haste,expertise to get the value of DP application to 2 per 12 seconds to gaurantee Its uptime to be unlimited? Instead of trying to figure out what its uptime would be which is completely based on chance, maybe we can reach a benchmark point to hit as rogues so to always keep DP up?
Pardon me i seem to have also left slice and dice in my post above.
1) You can never guarantee 100% uptime. It *always* drops eventually - with probability 1. With high haste, hit and expertise, you can put this off for a while, but it *will* happen sooner or later (unless you Shiv, but that's another story).
2) Even if you could come up with a gearset that guarantees 100% DP uptime, that wouldn't actually make it notably good. Poison comprises about 4% of your total damage, so increasing it's uptime from 90% to 100%... doesn't really do that much for your damage, relative to some things you could be paying attention to.
3) Even assuming 1 and 2 *weren't* true - that is, your poison damage *was* actually highly relevant, and you *could* guarantee 100% poison uptime... that still wouldn't make it a value that rogues should necessarily seek to have. The correct approach would still be what it always hit - look at the gear available to you, consider the tradeoffs, and take the set of gear that maximizes damage. There is no such thing as a magic amount of any stat that you absolutely must have; just various breakpoints where certain stats become less marginally useful.
Seeing that DP Uptime would be essentially increasing number of hits your OH can go through, thus its prolly upgrading ur DPS at the same point of time. What im saying is to work out a benchmark so that rogues know that when they hit that benchmark they are at the point where dp wont drop and then focus on Arpen or something.
That brings out a question of me though. Is it worth it to shiv on fights where you have a maxed DP Stack but its about to finish? EG Bear avatar in ZA Where he charges away.
You missed my third point. Any statement of the form "you should focus on stat X until level Y, and then focus on stat Z instead" is incorrect. That's not the right way to think about itemization, and doing so will very likely get you into trouble. One *always* wants to consider the tradeoffs, rather than stacking any given stat to try to make some abstract crossover point. There's 8 different stats that appear on items that increase Rogue DPS. All of them do so in varying amounts. Stacking any one to the exclusion of the others to make some abstract breakpoint is usually inadvisable. Instead, one should look at the blend of stats on each item and pick the best one. Thus, specifying some benchmark number to reach is foolish, and I will never do it. The optimal amount of any stat to wind up with is "whatever you wind up with when you wear the best set of gear you have access too" - and that's all you can say.
Re: Shivving. I believe there are some estimates on this posted on these forums already. I recommend searching to locate them.
Also, I hope you'll forgive me for being a tad rude, but: when you're making your first couple posts on a forum to lay out some napkinmath and unconfirmed theories, doing so in a thread titled "advanced" might not be the best place to do it. I might suggest starting off in the Roguecraft 101 thread for a while until you have a better idea of the mechanics and concepts before trying to participate in the advanced thread, as, if you don't mind me saying so, you seem to have missed a lot of the subtlety and complexity of the discussion in this thread.
In all due respect, I do not feel that stacking hit, expertise, haste, to be over pirioritizing and would cost one to lose DPS. And yes i do forgive you for being a tad rude if you thought you are with the statement, which is true, to a certain extent. I was merely trying to assist in every way possible that i could to get you guys on this path that you desire. If you wish me to leave this discussion of "advanced" Rogue mechanics, so be it. I shall leave.
It was nice talking to you ald, I wish you good luck in any new findings.
In all due respect, I do not feel that stacking hit, expertise, haste, to be over pirioritizing and would cost one to lose DPS.
There lies your problem. Stacking stats will inevitably lower your dps. Picking an item for the sole reason that it has Hit, Expertise or Haste is a bad idea. Are those good stats? Yes. Are they the only stats? No. If you have no AP, that hit isn't doing you a whole lot of good. If you have no Arm Pen, same thing. If you have no Crit, that haste loses some value. Just about all rogue stats affect each other and buff each other in a multiplicative way. However, most stats do not scale at all with themselves. Thus stacking is, by nature, bad.
Not to mention, when it comes to determining which item or set of items will produce the highest dps, "feel" is not a word which should come into play.
There lies your problem. Stacking stats will inevitably lower your dps. Picking an item for the sole reason that it has Hit, Expertise or Haste is a bad idea. Are those good stats? Yes. Are they the only stats? No. If you have no AP, that hit isn't doing you a whole lot of good. If you have no Arm Pen, same thing. If you have no Crit, that haste loses some value. Just about all rogue stats affect each other and buff each other in a multiplicative way. However, most stats do not scale at all with themselves. Thus stacking is, by nature, bad.
Not to mention, when it comes to determining which item or set of items will produce the highest dps, "feel" is not a word which should come into play.
I'd have to agree but with a side note that getting more out of Itemization is the best way to improve your dps. If one item has 50 hit on it v/s an item with 10 haste, 10 hit, 10 agility, 10 AP, 10 stam. The item with 50 hit has more dps value if you're not capped. Thus the need for AEP calculations.
I'd have to agree but with a side note that getting more out of Itemization is the best way to improve your dps. If one item has 50 hit on it v/s an item with 10 haste, 10 hit, 10 agility, 10 AP, 10 stam. The item with 50 hit has more dps value if you're not capped. Thus the need for AEP calculations.
There is also the subtleties of the itemization formulas which allow for more "stats" (in a general sense) to be spent on an item the more DIFFERENT stats appear on it. Therefore an item with 50 hit rating on it would be higher ilvl than an item with 10 agi, 10 crit rating, 10 hit rating, 10 haste rating, and 20 attack power (attack is worth half :P)
There is also the subtleties of the itemization formulas which allow for more "stats" (in a general sense) to be spent on an item the more DIFFERENT stats appear on it. Therefore an item with 50 hit rating on it would be higher ilvl than an item with 10 agi, 10 crit rating, 10 hit rating, 10 haste rating, and 20 attack power (attack is worth half :P)
This is also true, but Blizzard doesn't itemize gear based on AEP. So in some cases an iLevel 141 item could yield a higher AEP than an iLevel 151 item.
Well, right. That's the point. Even if a high-hit item is as good or better than a more blended item, it will also be higher level due to the nature of the itemization formulas, and thus (probably) harder to get. Thus getting well-itemized balanced pieces tends to be the most effective way to gear up, rather than looking for pieces that stack any particular stat.
I've updated my simulator to include provision for special attacks. It works more or less as before, but now includes a special attack which uses a different miss rate and a user-settable frequency. This is especially useful for evaluating, say, Mutilate builds or for situations (such as combat dagger builds) where you might want to try DP mainhand and IP offhand in the absence of a shaman. Here is the code.
EDIT: Based on a comment by Aldriana, I realized that I mucked up the dodge issue in here. Basically, it can be assumed for the purposes of poison application that specials aren't ever actually dodged, since a dodged special (a) costs a lot less energy, and (b) is immediately reapplied. All that the dodge rate does is lengthen the average interval between attacks slightly, so you can account for that in the "specInterval" variable if you're really worried about it.
I have adjusted the code accordingly.
print "DP Modeling for special attacks, tick-based model"
# Longer times result in better estimates, but take longer to model
maxTime = 100*24*60*60 # 10 days of steady DPS
# maxTime = 60*60
# Weapon info
speed = 1.4/1.3 # weapon speed (remember to account for SND/Haste)
missChance = (5.5 + 6.0)/100 # miss + dodge (+ parry)
# Poison talents
impPoisonsRanks = 3
masterPoisonerRanks = 0
vilePoisonsRanks = 2
# Deadly poison rank 7 -> 180 over 12 seconds
dpDamage = 180
# Special attack interval
specInterval = 6.5
## Estimates here... 3.1 for Sinister Strike, 3.5 for Hemo, 6.5 for Mutilate?
############################################################
# You should not need to change anything below this line,
# unless you want to alter the fundamental mechanics of this
# program.
############################################################
# Compute some basic calculated values
attsPerSec = 1.0/speed # p
hitChance = 1.0 - missChance
hitChanceSpecial = 1.0
bossResistRate = 0.17 - 0.05 * masterPoisonerRanks
poisonProcRate = 0.3 + 0.02 * impPoisonsRanks
# Compute the chance for DP to proc on any given attack
# (Distinguish between normal and special attacks)
procChanceNormal = hitChance * (1 - bossResistRate) * poisonProcRate # v
procChanceSpecial = hitChanceSpecial * (1 - bossResistRate) * poisonProcRate
# This is Aldriana's prediction equations for uniform/periodic attacks
Q = (1-procChanceNormal)**(12*attsPerSec)
P = 1-Q
predictedRate = P * (1-P**5) / Q
print 'Predicted Rate (excluding specials): ', predictedRate
# Now we modify the equation to include specials (but for simplicity ignore
# any differences in hit chance)
attsPerSec += 1/specInterval
Q = (1-procChanceNormal)**(12*attsPerSec)
P = 1-Q
predictedRate = P * (1-P**5) / Q
print 'Predicted Rate (including specials): ', predictedRate
# Define the duration of a DP proc
procDur = 12
# Define variables for tracking our simulation
t = 0.0
stacks = 0
ticks = 0
procStart = -2 * procDur
nextTick = 0.0
nextAtk = speed
nextSpecial = specInterval
nextTypeSpecial = 0
from random import random
# Assumption: attack speed is less than 3.0 (valid for all rogue weapons)
while t < maxTime:
# If the next tick would occur after the duration from the last
# DP proc has run out, then the stack falls off. Set stacks to 0.
if procStart + procDur < nextTick:
stacks = 0
# If the next tick is recorded as earlier than the current time,
# then DP ticked since the last attack occurred. Update our total ticks
# counter and compute when the next tick will occur.
if nextTick < t:
ticks += stacks
nextTick += 3
# Now, resolve the current attack.
roll = random()
# What type of attack are we resolving?
if nextTypeSpecial == 1:
procChance = procChanceSpecial
else:
procChance = procChanceNormal
if roll < procChance: # Determines if DP procced
procStart = t
# This if statement determines type of tick modeling. Comment
# if you want to assume a global tick. Uncomment if you want to
# assume ticks are tied to when the first proc lands.
if stacks == 0:
nextTick = t + 3
stacks += 1
if stacks > 5:
stacks = 5
# Evaluate when the next attack will occur, and whether
# it will be a special or a white attack
if nextSpecial > nextAtk:
t = nextAtk
nextAtk += speed # Set time for next white attack
nextTypeSpecial = 0
else:
t = nextSpecial
nextSpecial += specInterval # Set time for next special
nextTypeSpecial = 1
# This section allows the DP stack to tick out at the end
while nextTick < procStart + procDur:
ticks += stacks
t = nextTick
nextTick += 3
# 4 ticks over 12 sec = 1 stack of DP
# 20 ticks over 12 sec = 5 stacks of DP
# Compute average stacks by relating ticks to stacks
print 'Simulated Rate: ', (ticks*3)/t
print 'Simulated DPS: ', ((ticks*3)/t)*(dpDamage/12)*(1+0.04*vilePoisonsRanks)
print 'End of Simulation'
I'm using this simulator to evaluate the differences between a 1.4 and a 1.8 speed offhand for Mutilate over in the Mutilate thread. Feedback welcomed.
Modeling Deadly Poison is a two-part process. Not only do we need to know whether it's up, but how many stacks are up. Attempting to do these two things in the same model is a huge problem since we have to model time differently in each part. The best way to approach it is to separate the two issues from each other. It is much easier to calculate the average number of stacks if we assume at least one is up, and it is much easier to find out how long the stacks will stay up if we don't care how many are up. I believe Aldriana was on the right path of looking at different parts of the problem separately, but I don't think much progress was made there. I'll admit that I hate reading code even though I know C/Java enough to figure out what's going on, and I assumed that such code was just simulation related and skipped it. I have no desire to work on simulations.
The 17-state Markov chain is definitely the best model we can really have once it's been stacked up. The poison is ticking in discrete amounts and the only thing that matters is whether it was refreshed (and sometimes how often) within a 3-second period of time. When during that time period is irrelevant. Calculating the probability of refreshing is not particularly hard and basically obeys the Markovian principle. While I admit there is a good amount of complexity in the computation if you really wanted to find exact solutions, multiplying matrices can be done extremely fast and as all the entries are positive and they are theoretically converging there shouldn't be any issue of rounding errors. I'm not a whiz at excel, but I'd imagine there's a way to tell it to continuously compute the 256th power of a matrix as new data is entered, which should be good enough. With the speed of today's processors you might not even get a hiccup, but that's pure conjecture on my part.
Now in order this to work, we need the model to accurate depict the number of stacks whenever the poison is up, and never be considering time in which the poison is down. That is, it needs to give the probability density of the stacks conditioned on the fact that at least one stack is up. Multiplying those densities by the the probability that at least one stack is up gives the overall probability each number of stacks is up.
Our states are (X,Y), where X is the number of DP stacks and Y is the number of times the current stack has ticked. Except for the first stack, each stack must have ticked once. In total, they are (1,0)-(1,3),(2,1)-(2,3),(3,1)-(3,3),(4,1)-(4,3),(5,1),(5,3). There are 4 + 4*3 = 16 states. The transitions in which the poison falls off lead to (1,0), in line with the assumption that the poison is immediately reapplied, ie, we don't concern ourselves with times the poison is not on. Assuming we can correctly determine transition probabilities, taking this matrix to a large power will approximate the limiting probabilities.
Assuming that you can find the average time to poison a mob and the average time that the poison remains up, you can model the transitions back and forth as a 2-state continuous-time Markov Chain. Solving the balance equations for such a chain is quite trivial:
Let S = rate at which mob is poisoned (calculated from weapon swings/sec and poison proc rates directly) and R = rate at which DP drops (calculated a bit more indirectly). Let P = probability of being poisoned and Q = (1-P) = probability of being unpoisoned. Let state 1 be unpoisoned and state 2 be poisoned. The rate of entering state 1 is PR, which must equal the rate at which one leaves which is QS = (1-P)S. Since this is a 2-state chain, the other balance equation says the same thing. Solving we get S-SP = PR => S = P(R+S) => P = S/(S+R), as one might arrive at naively as well. Note that S and R are rates, the reciprocals of the mean times.
Calculating the rate at which DP drops is a two-step problem. First we have to calculate the probability it drops immediately, since we get a full 12 seconds there, and then find the probability it's going to get refreshed again in 9 seconds, form an infinite series, then calculate its sum. I have in mind a decent way to calculate it in terms of the probability that a stack gets refreshed in a 3-second interval, but I'm short on time to fully flesh it out in text.
I wonder, have there been research in terms of dodge rate meanwhile?
Currently we are assuming a 6.5% dodge rate for level 73 (boss) mobs, but has anybody been doing the tedious work to prove this right or wrong?
At one point, I went out and fought some lower level mobs looking for the point mobs begin to dodge/parry. I didn't begin to see dodges/parries until fighting level 61's without weapon skill and 63's with it. This led me to believe that for lower level mobs, the rate change is 0.5% per level, same of hit rating. Expand that up and 6.5% makes sense. Still, I looked through various posts and forums and ran across a few tanks disputing 5.6% pointing to dodge rates in the ballpark of our 6.5% number. Beyond that, I couldn't find much more definite information.
I believe there have been partial parses by warriors and enh shamans who have pinned the number to be above 6%, and seemingly somewhere in the range between 6.25% and 6.5%.
Given all the new expertise gear, it shouldn't take long for someone at 6.25% -dodge to come up with a dodge on a boss. Similarily, if after a ~week or so of killing bosses at 6.5% -dodge you have yet to dodge, I would be quite confident in using that figure as the correct amount.
At one point, I went out and fought some lower level mobs looking for the point mobs begin to dodge/parry. I didn't begin to see dodges/parries until fighting level 61's without weapon skill and 63's with it. This led me to believe that for lower level mobs, the rate change is 0.5% per level, same of hit rating. Expand that up and 6.5% makes sense. Still, I looked through various posts and forums and ran across a few tanks disputing 5.6% pointing to dodge rates in the ballpark of our 6.5% number. Beyond that, I couldn't find much more definite information.
I know, and my own reasearch, started in the weapon skill thread, based on your (and others') logs.
However I never really pursued that topic further, also due to lacking the the expertise rating required.
I could reach exactly 63 expertise rating now (with some crappy gear), which - together with weapon expertise - should give me 6.25% anti dodge (63 being the 'magic number', as 64 would already result in 6.5% anti dodge).
I'm not so eager to do another Alterac session *again*, especially since the changes done to it and the following possibility of never seeing Drek'Thar in a row of matches.
I suppose there haven't spawned some magic level 73 mobs in Outlands somewhere in the meantime?
// Edit
Damn Dontmindme, you're typing faster than I'm editing.
The only single dodge was against another player while mindcontrolled on our way to Shahraz.
21:58'00.931 Churkai's Swing dodged by Haley
I don't have the equipment to do some test at 25 expertise, but at least the assumption of Boss dodge rates being not higher than 6.5% seems to be correct. I will continue to check my logs for unexpected dodges.
Modeling Deadly Poison is a two-part process. Not only do we need to know whether it's up, but how many stacks are up. Attempting to do these two things in the same model is a huge problem since we have to model time differently in each part.
For some reason, I never saw this thread until today. When I read through it, I realized: maybe we can just harness already existing simulators to solve our problems? There's more than enough discrete event simulators floating around, I have the most experience with OMNeT++, which actually is used for network simulation, but can be "dumbed down" far enough to make it useful in this case, I think.
My current idea (about 20 minutes old, so there's probably flaws there) is to create several entities in the simulation:
1) The MH/OH/Special entities. For ease of use, just make one for every type of attack. It rolls a random number, and decides, based on the proc chance of the poison whether it procced or not. If it did, it sends a message to the DP entity (see #2) to inform it of the proc. Afterwards, it schedules its next event for 1.5 seconds in the future, or whatever your weapon speed is.
The main problem here seems to be the special attacks, since for rogues, those depend on your energy consumption and how often you can use them. They are most probably not as easy as "fire every [OH speed] seconds". Precisely modelling those based on, let's say, a typical rotation, looks like shifting the modeling problem to a different area. Thankfully, DP modeling should work fine, because generally, it's only used on the OH, which is not used in specials save shiv; therefore, at least here, you probably can ignore special attacks as triggers.
2) The poison entity. Receives events from the MH/OH/Special entities. Whenever it does, it increases the internal stack counter if it's below 5, and resets the poison tick timer. An internal timer makes sure that at the appropriate times, it sends an event to the logging entity (#3), which just notifies it of the current number of stacks up.
3) The logging entity. Just logs the poison ticks, and how many stacks were up for each tick. You use that information to compute the DP DPS, how many stacks were up at each point in time, etc.
TL;DR: What I'm getting at: Would it be a nice idea to use preexisting discrete event schedulers to do the modeling and simulation for stuff like DP? But, what's better, since you can write your own entities and wire them together, you can simulate pretty much everything in game with them. Think of stuff like mongoose uptime, or trinket procs (internal cooldowns are piss easy to implement). Generally, it would only be a few lines of simple code to model pretty much every item or mechanic in-game, wouldn't it? And you wouldn't have to reinvent the wheel every time. Of course, there's pitfalls here too (see #1), and analytical solutions are probably preferable. But those are often very hard to find, while simulation is comparatively straightforward.
Writing a simulation is not notably hard, I would argue; even without anything as fancy as event schedulers. I think the general framework used in the python program above could be extended pretty easily to add more types of attacks. The issue is that, in a system with so many variables, a simulation isn't particularly useful. If there were just a few parameters, we could just precompute everything and build a lookup table into the spreadsheets; since there's not, we kind of need an analytical model rather than a simulation if we're going to include this in our modeling.
Writing a simulation is not notably hard, I would argue; even without anything as fancy as event schedulers. I think the general framework used in the python program above could be extended pretty easily to add more types of attacks. The issue is that, in a system with so many variables, a simulation isn't particularly useful. If there were just a few parameters, we could just precompute everything and build a lookup table into the spreadsheets; since there's not, we kind of need an analytical model rather than a simulation if we're going to include this in our modeling.
Hmm, but since the analytical model still isn't there, what about just doing a series of simulations for different OH speeds (just looking at the easiest case of DP on OH, nothing fancy), possibly everything between 1.0 and 2.6 in 0.01 increments (it's not like these simulations are computationally expensive), and then, if a lookup table of that size is deemed unhandy, interpolate to a makeshift pseudo-analytical formula? I know interpolation is evil(tm), but isn't it still better than no analytical model, and an unhandily large lookup table?
edit: and about the fact that it's not hard to write a simulator: you are probably right there. The main advantage of using an already existing DES would probably be that it has been tested thoroughly for bugs, so the actual simulation framework can be expected to be bug-free. Of course, you can always screw up writing your modules for it. Also, it generally comes with visualization If you can't explain some weird results, you can step through the events and watch them fly around. It's closest I came to playing games at work writing my thesis.
Well, at the very least you'd need every OH speed from about .7 up to 1.5, plus different application rates corresponding to different combinations of hit, expertise, and improved poisons ranks. So you're talking something like a 100x100 table to get a reasonable approximation, which is not the most efficient thing in the world.
03/04/08, 1:09 PM
in 
Similar Threads
