Advanced Rogue Mechanics Discussion - Page 6

Left · 06/26/08, 10:39 AM

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.

Yavn · 06/26/08, 11:32 AM

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.

EDIT: Expanded a bit, for clarification.

drumbum · 06/26/08, 12:17 PM

Originally Posted by Vulajin

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:

(1) :02.399 SWING_DAMAGE
(2) :03.050 SPELL_CAST_SUCCESS
(3) :03.419 SPELL_AURA_APPLIED
(4) :03.499 SWING_DAMAGE

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:

(5) :04.433 SWING_DAMAGE
(6) :04.636 SPELL_AURA_REMOVED
(7) :05.699 SWING_DAMAGE
(8) :06.966 SWING_DAMAGE

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).

PSGarak · 06/26/08, 10:07 PM

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.

Yavn · 06/27/08, 5:17 AM

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.

Yavn · 06/30/08, 9:26 AM

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.

m/d	time	action	src	dst	id	name		value	dt	dt (ticks)
06/28	19:34:00.734	SPELL_CAST_SUCCESS	Yavn	Servant of Razelikh	26867	Rupture	0x1			
06/28	19:34:00.953	SPELL_AURA_APPLIED	nil	Servant of Razelikh	26867	Rupture	0x1	DEBUFF	00.219	00.2
06/28	19:34:02.796	SPELL_PERIODIC_DAMAGE	Yavn	Servant of Razelikh	26867	Rupture	0x1	99	01.843	01.8
06/28	19:34:04.656	SPELL_PERIODIC_DAMAGE	Yavn	Servant of Razelikh	26867	Rupture	0x1	98	01.860	01.9
06/28	19:34:06.640	SPELL_PERIODIC_DAMAGE	Yavn	Servant of Razelikh	26867	Rupture	0x1	99	01.984	02.0
06/28	19:34:08.140	SPELL_CAST_SUCCESS	Yavn	Servant of Razelikh	26867	Rupture	0x1		01.500	
06/28	19:34:10.406	SPELL_PERIODIC_DAMAGE	Yavn	Servant of Razelikh	26867	Rupture	0x1	109	02.266	03.8
06/28	19:34:12.421	SPELL_PERIODIC_DAMAGE	Yavn	Servant of Razelikh	26867	Rupture	0x1	108	02.015	02.0
06/28	19:34:14.609	SPELL_PERIODIC_DAMAGE	Yavn	Servant of Razelikh	26867	Rupture	0x1	108	02.188	02.2
06/28	19:34:16.375	SPELL_CAST_SUCCESS	Yavn	Servant of Razelikh	26867	Rupture	0x1		01.766	
06/28	19:34:18.453	SPELL_PERIODIC_DAMAGE	Yavn	Servant of Razelikh	26867	Rupture	0x1	108	02.078	03.8
06/28	19:34:20.515	SPELL_PERIODIC_DAMAGE	Yavn	Servant of Razelikh	26867	Rupture	0x1	109	02.062	02.1
06/28	19:34:22.468	SPELL_PERIODIC_DAMAGE	Yavn	Servant of Razelikh	26867	Rupture	0x1	109	01.953	02.0
06/28	19:34:24.015	SPELL_CAST_SUCCESS	Yavn	Servant of Razelikh	26867	Rupture	0x1		01.547	
06/28	19:34:26.312	SPELL_PERIODIC_DAMAGE	Yavn	Servant of Razelikh	26867	Rupture	0x1	108	02.297	03.8
06/28	19:34:28.093	SPELL_PERIODIC_DAMAGE	Yavn	Servant of Razelikh	26867	Rupture	0x1	108	01.781	01.8
06/28	19:34:30.140	SPELL_PERIODIC_DAMAGE	Yavn	Servant of Razelikh	26867	Rupture	0x1	108	02.047	02.0
06/28	19:34:31.578	SPELL_CAST_SUCCESS	Yavn	Servant of Razelikh	26867	Rupture	0x1		01.438	
06/28	19:34:33.859	SPELL_PERIODIC_DAMAGE	Yavn	Servant of Razelikh	26867	Rupture	0x1	108	02.281	03.7
06/28	19:34:35.734	SPELL_PERIODIC_DAMAGE	Yavn	Servant of Razelikh	26867	Rupture	0x1	109	01.875	01.9
06/28	19:34:37.031	SPELL_CAST_SUCCESS	Yavn	Servant of Razelikh	26867	Rupture	0x1		01.297	
06/28	19:34:39.140	SPELL_PERIODIC_DAMAGE	Yavn	Servant of Razelikh	26867	Rupture	0x1	108	02.109	03.4
06/28	19:34:40.968	SPELL_PERIODIC_DAMAGE	Yavn	Servant of Razelikh	26867	Rupture	0x1	109	01.828	01.8
06/28	19:34:42.203	SPELL_AURA_REMOVED	nil	Servant of Razelikh	26867	Rupture	0x1	DEBUFF	01.235	01.2

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.

Mojofabulous · 06/30/08, 4:53 PM

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 :-)

PSGarak · 06/30/08, 9:27 PM

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.

Dontmindme · 07/02/08, 3:32 AM

Originally Posted by PSGarak

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.

sp00n · 07/04/08, 6:58 PM

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).

Analogkid · 07/20/08, 10:50 AM

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.

◊ Shaker · 07/21/08, 3:45 AM

That is the case for all fixed location bosses (Ragnaros, Murmur).

Garren · 10/08/08, 7:51 PM

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.

• Aldriana · 10/08/08, 8:28 PM

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.

• Vulajin · 10/08/08, 8:58 PM

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.

• Aldriana · 10/08/08, 9:09 PM

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.

Halfdane · 10/13/08, 3:55 PM

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).

Thank you very much for your time.

• Aldriana · 10/13/08, 4:29 PM

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.

Halfdane · 10/13/08, 4:56 PM

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).