For poisons, I believe that refreshes will not reset the tick timer. Aldriana thinks (or at least thought) this as well. However, there is still the issue of whether the poison ticks are tied to starting when your attack lands or tied to some global tick timer on the server. This post on my DP simulator shows what the difference is in "average stacks" using one model or the other.
I am not sure how Rupture refreshes. I think, though, that because Rupture is an entire ability with often differing coefficients, that it would simply start over entirely when you refresh it before the last one ticks off. This isn't a case we usually care about, since we try to avoid clipping Rupture whenever possible.
EDIT: I forgot, DMM later confirmed the way DP works in this post.
I think I saw that post earlier, but didn't draw proper conclusion from it. I believe that DP, Rupture or any DoT effect for that matter must obey the same simple rules. Based on DMM's observation i suppose DoT can be refreshed only by multiplication of its tick time, i.e. 3 seconds for DP or 2 seconds for Rupture.
If I apply DP in [0,3) seconds, nothing happens and total time is 12s still (proc does nothing). But if proc happens in [3,6), so essentially after first tick, another tick is added and time stretches by 3 seconds (to a total of 15s poison uptime). Perhaps it's most convenient to think of DoTs as a number of ticks released at certain interval. Deadly Poison is 45 damage * 4 ticks (i.e. 180 damage over 12s). Now, if we proc DP after N ticks, we get:
After 0 ticks -> zero ticks (no effect)
After 1 tick (3s) -> +1 tick
After 2 ticks (6s) -> +2 ticks
After 3 ticks (9s) -> +3 ticks
After 4 ticks (12s) - poison dropped, we apply it anew
The last thing to verify is: if DP proc increases stacks from 1 to 2 during a tick, will that tick be counted as 1 or 2 stack? (45 or 90 damage). I guess the latter is correct.
Rupture should work in the same way, with the exception of overwriting rules (so you can never apply e.g. 2r over 3r). Anyway, it looks like I have the needed information to tweak my simulator a bit. I have some idea about swing timer and haste too and I have to check if that change will make any difference in DPS.
Based on the timestamps, you can see that the two swings during which the Slice buff was gained and lost took 1.100 and 1.266 seconds respectively, while the fully Slice-hasted swing took only 0.934 seconds, and the fully unhasted swing took 1.267 seconds. Obviously some sort of mid-swing hasting effect occurs; I simply haven't been able to nail down precisely what to date.
Based on the combat log snippet you supplied (although I haven't yet checked out the rest of your log) I think I might see what's going on. It appears, at least to me, that the SPELL_AURA_APPLIED and SPELL_AURA_REMOVED are reported in the combat log with some short delay after the effect has actually been applied or removed. For instance, let's assume for a moment that SND is applied instantly when the SPELL_CAST_SUCCESS message occurs, instead of applying when the SPELL_AURA_APPLIED message occurred. Assuming the swing will instantly change its timer to the new speed, here's what we see:
Between events (1) and (2), 0.651 seconds go by, which is about 50% of the expected swing time of 1.3 seconds. Assuming the swing time is instantly adjusted to 1.0 now, you'd expect that the next swing will occur in roughly 0.5 seconds. As it so happens, it occurs in 0.449 seconds.
On the other hand, if you base your numbers off of SPELL_AURA_APPLIED, you'd see that between (1) and (3), about 1.02 seconds goes by, which is 78.46% of the time between unhasted swings. With the swing speed bumped up to 1.0, you'd expect that 0.215 seconds are left in the timer. However, we observe a much smaller number instead: 0.08 seconds.
Another example is that at the end of the snippet, you see this:
Between (5) and (7), we see that the observed time between the two swings is 1.266 seconds. The observed time between (7) and (8) is 1.267 seconds. Clearly SND is not active at all between (7) and (8), so it's hard to believe that SND is being considered active at all between (5) and (7) either, even though SND wasn't reported as being removed until (6) occurred.
On the other hand, if SND actually had dropped about ~0.37 seconds earlier than it was reported in the combat log (which is the same difference in time we observe between SPELL_CAST_SUCCESS and SPELL_AURA_APPLIED), then SND would have fallen off before swing (5) occurred, which might explain why there was no haste observed between swings (5) and (7).
There are actually two divergent methods for DoT refreshes currently used in the game. As much as I would also like mechanics to be unified, it's entirely possible and in fact quite likely that Rupture follows the exact opposite rules than deadly poison with respect to refreshing. In the more common method, refreshing the DoT resets both the duration and the tick timer, generally resulting in lost damage. This is why affliction warlocks have to be very careful about not refreshing a DoT too early. In the second method, refreshing the DoT resets the duration but does not reset the tick duration. This may result in some extraneous debuff time.
As a general rule of thumb, if a DoT stacks, then refreshing it will not reset the tick timer. I am only aware of testing for this with respect to warlock, priest, and druid spells.
Regarding swings and haste I have to analyse rest of that log. These times are a bit too irregular to tell anything with satisfactory degree of certainty.
PSGarak it's good that you pointed out that one difference between DP and Rupture - stacking. This is definitely worth checking. I'll try to do some tests with Rupture reapplication. This might also mean that 5 stacks of DP and <5 stacks behave differently. I'll post my findings here, once I'm done.
I have ran some tests through weekend and gathered data on how Rupture and Deadly Poison works. This is what I've found; this information isn't anything gamebreaking, as we have already known this (more or less), but I think it's good to have facts in one place with proof to back it up.
Rupture
1. You can't overwrite higher damage Rupture with lower damage one (can't cast 2 CP Rupture over 1 CP version).
2. New rupture cancels previous one - it's like removing old one and placing new instead. This means that tick timer is reset and remaining ticks are lost.
Deadly Poison
This poison indeed behaves differently from other DoTs. Perhaps being a temporary enchant, as opposed to activated spell is the determining factor here.
1. Poison always ticks in 3 second intervals, counting from initial poison application. Stacks/procs don't affect this. Tick timer is reset when poison fades/is removed from the target.
2. Poison proc alwyas sets number of remaining ticks to 4 (3*4=12s of poison time). The gained poison uptime is variable and determined by the time of next tick. It can be anywhere between 9 and 12 seconds.
3. Poison drops after 4 ticks since last application/proc.
Combat log is affected by latency and uncertainity of 300 ms seems common with <150 ms in game latency. Paste code sections into Excel so it's more readable.
Following log (edited in Excel) shows time between Rupture ticks. Last column contains time between ticks. You can easily see 4s delays between ticks when Rupture is reapplied on the target.
Following code shows what happens when poison dose is applied roughly in the same time when tick is about to happen. The entry in log is inverted - application takes place after a tick, but the increased tick value clearly shows that tick was based on 2 doses. Poison drops correctly after 4 ticks, even though uptime since last proc is shorter and close to 9 seconds. Colum "dt (ticks)" contains time between poison ticks and last colum "t (application)" shows time that passed since first application of poison.
m/d hour action src dst id name value stack dt dt (ticks) t (application)
06/01 19:37:58.718 SPELL_AURA_APPLIED nil Servant of Razelikh 27187 Deadly Poison VII 0x8 DEBUFF 23.312
06/01 19:38:01.234 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 45 8 02.516 02.5 02.5
06/01 19:38:04.406 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 46 8 03.172 03.2 05.7
06/01 19:38:07.359 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 46 8 02.953 03.0 08.6
06/01 19:38:10.343 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 46 8 02.984 03.0 11.6
06/01 19:38:10.640 SPELL_AURA_REMOVED nil Servant of Razelikh 27187 Deadly Poison VII 0x8 DEBUFF 00.297 drop 11.9
06/01 19:38:16.765 SPELL_AURA_APPLIED nil Servant of Razelikh 27187 Deadly Poison VII 0x8 DEBUFF 06.125
06/01 19:38:19.500 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 46 8 02.735 02.7 02.7
06/01 19:38:22.343 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 46 8 02.843 02.8 05.6
06/01 19:38:25.296 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 92 8 02.953 03.0 08.5
06/01 19:38:25.531 SPELL_AURA_APPLIED_DOSE nil Servant of Razelikh 27187 Deadly Poison VII 0x8 DEBUFF 2 00.235 08.8
06/01 19:38:28.375 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 91 8 02.844 03.1 11.6
06/01 19:38:31.281 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 91 8 02.906 02.9 14.5
06/01 19:38:34.281 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 91 8 03.000 03.0 17.5
06/01 19:38:34.484 SPELL_AURA_REMOVED nil Servant of Razelikh 27187 Deadly Poison VII 0x8 DEBUFF 00.203 drop 17.7
06/01 19:39:06.093 SPELL_AURA_APPLIED nil Servant of Razelikh 27187 Deadly Poison VII 0x8 DEBUFF 31.609
06/01 19:39:08.937 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 46 8 02.844 02.8 02.8
06/01 19:39:11.843 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 46 8 02.906 02.9 05.7
06/01 19:39:14.843 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 46 8 03.000 03.0 08.7
06/01 19:39:17.906 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 46 8 03.063 03.1 11.8
06/01 19:39:18.140 SPELL_AURA_REMOVED nil Servant of Razelikh 27187 Deadly Poison VII 0x8 DEBUFF 00.234 drop 12.0
06/01 19:39:20.312 SPELL_AURA_APPLIED nil Servant of Razelikh 27187 Deadly Poison VII 0x8 DEBUFF 02.172
06/01 19:39:22.937 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 46 8 02.625 02.6 02.6
06/01 19:39:26.000 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 46 8 03.063 03.1 05.7
06/01 19:39:28.796 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 91 8 02.796 02.8 08.5
06/01 19:39:29.062 SPELL_AURA_APPLIED_DOSE nil Servant of Razelikh 27187 Deadly Poison VII 0x8 DEBUFF 2 00.266 08.7
06/01 19:39:32.015 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 92 8 02.953 03.2 11.7
06/01 19:39:34.859 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 92 8 02.844 02.8 14.5
06/01 19:39:37.750 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 92 8 02.891 02.9 17.4
06/01 19:39:37.921 SPELL_AURA_REMOVED nil Servant of Razelikh 27187 Deadly Poison VII 0x8 DEBUFF 00.171 drop 17.6
This part shows that ticks are roughly placed at 3 second intervals. Numerous poison procs (off white hits or Shiv) make no impact on this. Poison always drops 4 ticks after last application.
m/d hour action src dst id name value stack dt dt (ticks) t (application)
06/01 19:42:12.687 SPELL_AURA_APPLIED nil Servant of Razelikh 27187 Deadly Poison VII 0x8 DEBUFF 00.969
06/01 19:42:15.203 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 45 8 02.516 02.5 02.5
06/01 19:42:18.218 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 91 8 03.015 03.0 05.5
06/01 19:42:18.656 SPELL_AURA_APPLIED_DOSE nil Servant of Razelikh 27187 Deadly Poison VII 0x8 DEBUFF 2 00.438 06.0
06/01 19:42:21.218 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 92 8 02.562 03.0 08.5
06/01 19:42:23.843 SPELL_AURA_APPLIED_DOSE nil Servant of Razelikh 27187 Deadly Poison VII 0x8 DEBUFF 3 02.625 11.2
06/01 19:42:24.187 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 138 8 00.344 03.0 11.5
06/01 19:42:27.343 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 137 8 03.156 03.2 14.7
06/01 19:42:30.187 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 138 8 02.844 02.8 17.5
06/01 19:42:32.640 SPELL_AURA_APPLIED_DOSE nil Servant of Razelikh 27187 Deadly Poison VII 0x8 DEBUFF 4 02.453 20.0
06/01 19:42:33.140 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 184 8 00.500 03.0 20.5
06/01 19:42:36.203 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 183 8 03.063 03.1 23.5
06/01 19:42:39.265 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 184 8 03.062 03.1 26.6
06/01 19:42:42.125 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 184 8 02.860 02.9 29.4
06/01 19:42:42.328 SPELL_AURA_REMOVED nil Servant of Razelikh 27187 Deadly Poison VII 0x8 DEBUFF 00.203 drop 29.6
06/01 19:42:43.859 SPELL_AURA_APPLIED nil Servant of Razelikh 27187 Deadly Poison VII 0x8 DEBUFF 01.531
06/01 19:42:46.468 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 45 8 02.609 02.6 02.6
06/01 19:42:49.656 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 46 8 03.188 03.2 05.8
06/01 19:42:52.468 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 46 8 02.812 02.8 08.6
06/01 19:42:54.718 SPELL_AURA_APPLIED_DOSE nil Servant of Razelikh 27187 Deadly Poison VII 0x8 DEBUFF 2 02.250 10.9
06/01 19:42:55.562 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 91 8 00.844 03.1 11.7
06/01 19:42:58.468 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 92 8 02.906 02.9 14.6
06/01 19:43:01.468 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 91 8 03.000 03.0 17.6
06/01 19:43:04.531 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 92 8 03.063 03.1 20.7
06/01 19:43:04.734 SPELL_AURA_REMOVED nil Servant of Razelikh 27187 Deadly Poison VII 0x8 DEBUFF 00.203 drop 20.9
06/01 19:43:05.734 SPELL_AURA_APPLIED nil Servant of Razelikh 27187 Deadly Poison VII 0x8 DEBUFF 01.000
06/01 19:43:08.203 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 92 8 02.469 02.5 02.5
06/01 19:43:08.359 SPELL_AURA_APPLIED_DOSE nil Servant of Razelikh 27187 Deadly Poison VII 0x8 DEBUFF 2 00.156 02.6
06/01 19:43:10.109 SPELL_AURA_APPLIED_DOSE nil Servant of Razelikh 27187 Deadly Poison VII 0x8 DEBUFF 3 01.750 04.4
06/01 19:43:11.203 SPELL_AURA_APPLIED_DOSE nil Servant of Razelikh 27187 Deadly Poison VII 0x8 DEBUFF 4 01.094 05.5
06/01 19:43:11.203 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 229 8 00.000 03.0 05.5
06/01 19:43:11.640 SPELL_AURA_APPLIED_DOSE nil Servant of Razelikh 27187 Deadly Poison VII 0x8 DEBUFF 5 00.437 05.9
06/01 19:43:14.171 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 229 8 02.531 02.5 08.4
06/01 19:43:17.218 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 229 8 03.047 03.0 11.5
06/01 19:43:20.171 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 229 8 02.953 03.0 14.4
06/01 19:43:23.234 SPELL_PERIODIC_DAMAGE Yavn Servant of Razelikh 27187 Deadly Poison VII 0x8 229 8 03.063 03.1 17.5
06/01 19:43:23.234 SPELL_AURA_REMOVED nil Servant of Razelikh 27187 Deadly Poison VII 0x8 DEBUFF 00.000 drop 17.5
I hope you will find this information helpful as well.
I believe this question is specific enough and simple enough to belong here. I didn't see this question elsewhere but honestly there's so many freaking pages of rogue theorycraft now it's hard to tell what's where. So the question:
Kil'Jaeden is pretty much always casting ya? From what I'm aware, while a mob is casting they cannot dodge but can still parry, that seems to be confirmed by me having yet to see a dodge on my recount, but have seen a few parries. I can't confirm that this is 100% the case though because he's not ALWAYS channeling spells..they do stop and start, so maybe those parries are hitting inbetween?
Based on the above information, how is Shard of Contempt affected? Is it's value diminished, increased or neither? I doubt that Ald's spreadsheet models parries in to the trinket since it's rare that we should be attacking from infront of a boss. If it's value is indeed diminished, is it enough that I should be switching to my Atol or Madness? I've yet to check on his official armor value but it appears to be of the lower value so maybe the additional armor reduction would put it over the top. I leave that to people who don't have to guess at such things :-)
Players cannot dodge, block, or parry while casting, but mobs can, or at least used to be able to at some point. I remember being quite aggravated when I Pummeled a casting mob, that it was full-blocked and the spell was uninterrupted, and a friend of mine confirmed this was Working As Intended. It would be worth the effort to test whether this is still the case, as I haven't heard any more information on the topic since around 2005. I would recomend testing with an underleveled alt, to increase the mob's block/dodge/parry chance.
Players cannot dodge, block, or parry while casting, but mobs can, or at least used to be able to at some point. I remember being quite aggravated when I Pummeled a casting mob, that it was full-blocked and the spell was uninterrupted, and a friend of mine confirmed this was Working As Intended. It would be worth the effort to test whether this is still the case, as I haven't heard any more information on the topic since around 2005. I would recomend testing with an underleveled alt, to increase the mob's block/dodge/parry chance.
But there was a great deal of discussion awhile back showing that many, if not most, channeled boss spell effects prevent them from dodging or parrying. I believe this is somewhere within the old Roguecraft 101 discussion when we were still trying to work out what the Expertise cap was and what the boss dodge/parry rates were. Bosses when not channeling casts can Dodge, but not Parry when attacked from behind.
Yeah, back in the day I checked on Drek'thar and Tidewalker and didn't encounter one single parry/dodge while they were channeling a spell (Drek's whirlwind is also channeled).
What I assume is happening, since a boss' chance to parry is more than twice as high than his chance to dodge, and the chance to be dodged is easily almost completely negated by WE/T6 boots/SoC/racial, it's just a matter of probability that you are seeing parries when a boss has turned around to cast a channeled spell on someone on your side.
All the occurrences of parry I had noticed in the combat log where directly after he had stopped channeling his spell and was in the process of turning back to his original facing (or not at all).
Regarding KJ and his dodge/parry...it seems that when the tank is knocked back and not within a certain range it goes to the 2nd on aggro and hits them/knocks them back.
He isn't casting 24/7 like some other bosses; it seems there is an aggro range mechanic.
When Left/Todemax updated the mutilate cycles in the Rogue DPS spreadsheet*, they calculated an expectation value for combopoints when your target was X (giving X+ cycles). My thought is this, instead of averaging the combo points generated, and constructing cycles from that, why not average after calculating all the cycles (other than the obvious increase in work and computation time?) Since 3.0 is adding a lot more talents, etc. that provide variations to our CP/energy generation it is likely that more accurately modeling these effects will become more important.
Essentially, the probability of all combinations of attacks and CPs generated are calculated for the cases where you finish at X CPs, X+1 CPs, X+2 CPs, and then from there a family of cycles can be constructed. For example, for a sinister strike cycle, a 4+ cycle is constructed from 8 states: 4 CPs in one attack, 4 CPs in 2 attacks, 4 CPs in 3 attacks, 4 CPs in 4 attacks, as well as 5 CPs in one attack, 5 CPs in two attacks (where the first attack didn't generate 4 CPs), 5 CPs in three attacks (where the second attack didn't generate 4 CPs), and 5 CPs in 4 attacks (where the third attack didn't generate 4 CPs). We can then combine this with another cycle family, and explicitly calculate the DPS for each combination, and then weight by the probability of that combination occurring.
If we wanted to calculate the DPS of a 4+/4+ cycle, we would construct an 8x8 matrix, and calculate the cycle DPS for each one. We could do further explicit calculations for other cases that are normally averaged, eg. relentless strikes procs. In that case, we would get an 8x8x4 matrix.
The main advantage of this, is that it allows for construction of cycles that more accurately reflect what a real rogue already does, and allows us to calculate the DPS of cycles that could not be calculated before. For example, if for a 5s/5r cycle, generating 5 CPs in 5 attacks for both SnD and rupture causes SnD to fall off, that state could be replaced by a 4s/4+r family, if it would generate higher DPS. Or, for example, deep combat post 3.0 almost has the energy regen to do a 3 finisher cycle consistently a family could be constructed that is 3 finishers when procs line up (for the first two finishers most likely), and is 2 finishers when they don't line up. Or, a ruleset for, at least 2 attacks, and at least 2 CP SnD/5r.
I'm working on modeling some of this myself, but frankly other people are much better at theorycraft than I am, so I figured it's worth throwing the idea out there and seeing what sort of feedback I get. Also, the only suitable medium which I have sufficient knowledge in to do something like this is Mathematica, and I have an inkling that the install base in the rogue community is pretty low.
*It's likely other DPS modeling does this, this is the only case where I saw discussion about it.
So, things like this basically always come down to a tradeoff between accuracy and ease of calculation. Given sufficient time and computing power, we could certainly make models that are vastly more accurate than the current ones; the problem is, factoring in details on this level tends to be greatly complicate the model making it harder to write and harder to maintain. Hence, pretty much every model that's even been constructed has made simplifying assumptions somewhere, and the one you refer to in terms of combo points is very much in that same mold. Does it cost some accuracy? Yes. But the theory is that, at least so far, it's been accurate enough, and makes the rest of the calculations far more manageable.
This is not to say that we may not want a more accurate model, and we might even need it with some of the new changes; it's just no one has had the time or inclination to work on it yet.
The Roguecraft Spreadsheet models Mutilate cycles by fully calculating the X/X+1/X+2 cycles and averaging them out based on the expected frequency that you reach X/X+1/X+2 combo points. However, it does not fully separate out all the possible numbers of CP generators used to reach X/X+1/X+2; it averages those.
As Aldriana indicated, fully separating out all the possible cycle variations given a particular "goal" cycle is possible but not usually feasible (especially in a spreadsheet) and certainly not especially necessary. In the past I've used spreadsheets to separate out each possible occurrence of Relentless Strikes/Ruthlessness in a simple cycle (i.e. no Seal Fate) and found that the calculated DPS was not actually significantly different from our current models, which average out the effects of those talents. Is Seal Fate different? Yes, a little. But not to the extent that an averaged model isn't reasonably accurate.
To be really blunt, separating everything out simply isn't going to happen in a spreadsheet. In a program -- such as RogueCalc -- the chances are much more likely that such a thing could be done. But that depends largely on Aldriana's interest in doing it, and his determination as to whether it's even worthwhile.
Well, since we're on the topic, let me say a few words about RogueCalc. Is it capable of this level of subtlety? Absolutely. The ability to model stuff with an actual programming framework underneath the hood is almost limitless. Any particular aspect of the model that you'd like to see can be dealt with. It just takes time, and still really isn't that high a priority as I don't think it's going to change the outcomes that much. So is it the sort of thing I might work in eventually? Yes. Is it going to be in the early releases of expansion RogueCalc? No.
At the moment, things are only just starting to settle down enough that writing new RogueCalc modules makes sense, so while I will be starting work again on them fairly soon, it will probably be after Christmas before I will have anything that I'm particularly confident in. And while I may at that point start adding optimizations of this sort at that point, I think it will be more productive to clean up some of the UI and I/O issues with the program first, to improve usability. So I wouldn't expect to see stuff of this sort anytime soon, and, barring an influx of assistance with the project, it may very well never happen.
I'm interested in modelling PvP damage, and I would like recommendations of PvE modelling tools that might be useful for this.
The idea is not to model all aspects of Rogue PvP, as many comparisons are difficult (such as: "if I had shadowstep, I could have prevented the mage from getting away, and would have therefore done more damage"), but to instead model damage dealt while on target. This would be helpful for the Rogue PvP community for such questions as "Everything else being equal, do I prefer hit (past the yellow cap) to crit". There have been pages of debate on this subject in the PvP forums, but no data. It's an important question for gemming as well as deciding between talent builds. (5/5/51 vs. 0/10/51, for example).
I've hacked my way through the spreadsheets and can model resilience just fine, what I really want to do is model damage dealt when you have intermittent time on target. Basically, when this happens, yellow damage becomes more valuable than white damage (relative to PvE on a boss), since you get free energy regeneration. Such a model would also be useful for comparing different leveling specs.
My plan is to gather data from my own games (I've got a 1600ish R/D and a 1550ish R/M/P team) and use that data to alter a spreadsheet or other simulator. If other (better, or just with different teammates) rogues wanted to contribute data they would be welcome to. For all I know, one stat is more important if you play R/R vs. R/L/D. Additionally, it will be important to consider variance in the data, so we would get an idea of how accurate such predictions are.
My question for the modeling community (and I apologize for mentioning PvP in such good company, but no one in the PvP forums have answered such questions), is what tools should I use? What data collection tool is the best, and what spreadsheet or program is the easiest to modify in such a manner? Additionally, if you have ideas about how to go about the modeling, I would be very interested (and feel free to respond on whichever forum is appropriate).
So, the issue of interrupted time-on-target is a tricky one; it's pertinent to PvE as well, as any number of fights don't allow you to sit there and spam cycles on the boss indefinitely - in fact, most don't. The challenge is that the exact results depend highly on the specific interruption pattern. 15 sec in 5 sec out will exhibit very different behavior than 45 sec in 15 sec out, even though it's the same proportion of time on target in either case.
The most immediate difficulty in terms of modeling this in a spreadsheet-type setting is that cycle determination is a lot trickier. In the sustained DPS case, it's easy enough to identify the optimal SnD/Rupture cycle for maximum DPS; but as neither SnD nor Rupture is necessarily optimal in interrupted or PvP settings, figuring out what pattern of moves you should be doing is a fair amount harder. And, for that matter, you're very likely spending energy on stuns and interrupts, which makes it harder to estimate how much energy is going into DPS abilities.
Moreover, one needs to worry about the timing of stuff dropping off. A DP stack continuously up has different damage properties than a DP stack that needs to be restacked every time you run in. It also changes the value of cooldowns (which continue to occur while you're not attacking) and procs (which may proc just before you have to run out).
So, the short answer here is: there's an awful lot of variability based on the exact patterns of attack and not, which makes even the relatively simple case of interrupted PvE fights challenging to model; I can only imagine that PvP has more complicated issues (as you also need to consider the pattern of outgoing damage, as not all distributions of damage are equally easy to heal). However, in terms of getting some ballpark figures, I'd start with tweaking the white-to-yellow damage ratio.
The idea here is that when you're not on target, you continue to regenerate energy, but you're not autoattacking; hence, rather than having 10 energy to spend for every second of autoattack, you may have 12, or 15, or 20 (depending on just how interrupted the fight is). So by increasing the apparent rate of energy regen, you can simulate time spend out of melee range, regenerating energy, which will at least give some idea about what the properties of such fights is. However, for the many issues listed above, this is still an imperfect model of the situation; I'm not sure how practical it is to come up with a detailed PvP model, given the high degree of randomness in the properties of PvP encounters.
My initial cut for such modeling would be only to model the white/yellow damage ratios, as you suggest. The question "how valuable is a combo point in PvP" is very difficult to model (the first combo point, for example, being more valuable than the 5th).
Even a simplified model, on the other hand, might give some insight on questions such as Precision vs. Malice, or Lethality vs. Dual Wield (for x/x/51 daggers), or simply hit vs. crit. You make some good points on the worth of "burst" damage, but I would contend that non-controllable burst damage can be modeled as a variance on damage. At some point, you could trade higher expected damage for more spiky damage, and we could put a curve on such a decision.
What I'm imagining is an initial model that doesn't include Slice and Dice or any other finisher. Alternatively, the model could use Eviscerate every 5 combo points or 5 KS/5 Eviscerate (which might be close to a dailies PvE rotation).
06/26/08, 10:32 AM
Similar Threads
