Sorcerer wrote:Looking at my raid buffed base AP with quite high Ilev ~45k AP, with all procs + engi + pot + trinkets I can get my AP at around 79k... Talk about almost double RIP dmg for part/entire fight...

Looks like simcraft is far from working as intented here

Not necessarily. You have to factor in what you are giving up. For example, how many FBs are you doing while keeping the mega-Rip rolling? As your gear gets better most of the dps gain due to SotF is translated into FBs and a lot of the dps benefit we get from the DoC rotation is DoCed FBs. As example of how important FB is to the DoC rotation, our most recent sim work showed a significant dps increase DoC by pooling energy for FBs.

Well on paper with procs to me, it looks like that RIP is gonna do ~65-75% more dmg compared to standard rotation, considering 20-23% of base rip dmg ratio, at 110k DPS paperdoll, the net increase is high. I so can't see how pooling for DoC FB would come close.

Think I didnt understand, how pooling for DoC FB is breaking that bugged rip rotation to so low dps % in simcraft.Be my guess, something is broken in simcraft, couse I cant imagine other.

Last edited by Sorcerer on Tue Dec 11, 2012 3:51 pm, edited 1 time in total.

Sorcerer wrote:Looking at my raid buffed base AP with quite high Ilev ~45k AP, with all procs + engi + pot + trinkets I can get my AP at around 79k... Talk about almost double RIP dmg for part/entire fight...

Looks like simcraft is far from working as intented here

Not necessarily. You have to factor in what you are giving up. For example, how many FBs are you doing while keeping the mega-Rip rolling? As your gear gets better most of the dps gain due to SotF is translated into FBs and a lot of the dps benefit we get from the DoC rotation is DoCed FBs. As example of how important FB is to the DoC rotation, our most recent sim work showed a significant dps increase DoC by pooling energy for FBs.

Aggixx and I talked about this Sunday night. I actually end up with more FB's then if I do it the normal way. Taking into account SotF I still don't waste 5 combo points (except during Berserk where its all shred all the time). As soon as I get to 5 I hit FB (most are DoC'd). Being always energy starved I am still only paying 5 energy for the FB and not losing many shreds. Given the FB's are not giving as much damage as they could, but I can still keep the 2 trinket proc, Pot, TF, DoC'd rip going until very close to my next Berserk and not give them up.

Also because I don't have to Rip all those combo points are going to FB.

Tinderhoof wrote:You sure you are keeping the TF'd, DoC'd, and Pot'd Rip going. Under less then ideal situations tonight I am seeing Rip go from 21% of my damage to 36%. I have been able to hold it for 3 minutes 1 time. Average is about 2 (no BL).

The sim does a pretty good job of stacking everything together onto it's first rip, but it usually only gets the first rip to last about 1 minute (with bloodlust casted the same time the rip goes up). I'm not certain if it's a mechanic difference with rip extension not being modelled correctly in the sim or if it's just vastly more buggy than we realize it is, but that's what the sim ended up with.

With the goal of keeping your mega-rip going as long as possible, would it be beneficial to DPS to TF, get your shreds in, then berserk w/ lower energy, with the intent of keeping shreds going, then another TF shortly after the berserk?

Either I'm glitchy, or the game is, but I don't get immediate updates of rip-extension if I shred too quickly. Not sure if it makes up for it later though, so I've been playing it safe and leaving a small time of space between shreds, except during Berserk.

Just not sure if it's better DPS w/ a mega-rip up to stagger energy-helping CDs or business as usual and stack them?

I can test this when I get home in my sim for another set of numbers. I guess I'll use the simc rotation, remove clearcast Thrash, and allow for unlimited extends. I'lll probably just add this as miscellaneous feature: Rip Extends [default 3].

Stenhaldi wrote:Each extension is 3 seconds, not 2. This is a bug that was introduced in 4.0 (October 2010) and persists to this day.

I don't know if that's true. Rip is a 2 second tick. So there are basically 2 things you can monitor: Time Left or Ticks Left. Time Left is really confusing (and causes interface bugs, especially with BitW Rip fading early according to TimeLeft) because is essentially a fake client-side number.

You can think of Rip application, as installing a 2 second timer, with a counter set to 8 (ticks). On each tick, it reduces the count by 1, until it hits zero, then unscheduled itself. When you Rip extend, you add 1 tick to that counter. When you clip a Rip, you set that counter to 9 (+1 for the rollover tick). When you BitW refresh, you reset the counter to 8. It's easy to think about this way, because when you clip your Rip, there isn't a gap in the tick duration, it just keeps ticking aligned to the original application time.

This same effect can be seen with Savage Roar (3 second tick as was pointed out in another thread) when you double apply it at 0-cp (using Glyph) and get a 12-15 second duration. Because behind the scenes, SR is a 3 second timer with a counter of 4 and then SR refresh sets the counter to 5 (+1 for rollover tick). The fact that it displays as 12-15 sec is just dependent on how the timer is aligned to the first application.

On a related note, I've been working on modifying my InlineAura to display Rake/Rip/SR as ticks remaining instead of time left, as it seems far more functional and completely avoids the issue of Rip falling off unexpectedly (although this Ursol Vortex bug would completely screw up my modification).

Edit:

And even better example is Rake: you can Rake 3 times before it ticks once. No matter how often you Rake, the tick is still aligned to the first. First Rake installs the 3 second timer, with a counter of 6. Every clipped application does the initial Rake tick damage, and then sets the counter to 7 (+1 for rollover tick).

I'm aware that rip has a 2-second tick interval. The extension is still 3 seconds, and as you might expect, this leads to some odd behavior at the end of the duration. When you see rip expire with a few seconds remaining, that is an example of this behavior. Typically, a thrice-extended rip lasts 12 or 13 ticks (24 or 26 seconds), something that obviously couldn't happen if it only extended by 1 tick. But when you can extend rip arbitrarily far, it is clear that each extension adds 1.5 ticks.

I implemented support for this in my simulator and exposed some simc hooks so I could use the latest script.

When I apply/refresh a Rip, I maintain a RipExtends counter (like DoC charges) that is initially set to 3. When you cast Ursol's Vortex, all active targets get their RipExtends counter set to a huge number. Also, any new Rip apply/refresh during Ursol's Vortex will also seto the RipExtends to a huge number.

I added Ursols Vortex with pretty high priority (because I didn't know where to put it). I also added "dot.rip.ticks_avail" so I could test to see if the Rip was already bugged:

I don't know how correctly model the Rip extensions yet, so I made it so you get 1 or 2 extra ticks per extension.

Using the BiS gear configuration (pre-5.1, so no upgraded stuff, but 5.1 features like properly scaling trinket effects and rppm procs) with the normal simc raid setup and Heroism at the front, using Ursol's seem to be about an 7-8k dps increase (134k to 142k median dps). Rip goes from 23% to 27% overall, Thrash goes from 6% to about 1.5%. This is for a 60m-ish HP target (which results in a 7-ish minute fight).

If we only got 1 tick per extension, Ursol's Vortex is break even with the current rotation.

Edit: I'll try to release a new version later this week so anyone can test this for themselves.

Some observations regarding Ursol's Vortex though: If you get it off before he teleports the first time, your rip will be extended, but I could not get it to extend if I got it off after his first teleport. The difference in DPS was about 65-70k w/ no extention, and 90-95k w/ the extention (phase 1). We wiped plenty of times so I had a lot of chances to test this

It's actually simple enough that I'm surprised that a lot of people didn't find it independently. The first observation is that -- as Terias mentioned -- Ursol's Vortex triggers Predatory Swiftness now. It's easy enough to see this in normal uses of Ursol's Vortex. Then using Ursol's Vortex to apply DoC to a rip, one encounters the rip bug.

Stenhaldi wrote:It's actually simple enough that I'm surprised that a lot of people didn't find it independently. The first observation is that -- as Terias mentioned -- Ursol's Vortex triggers Predatory Swiftness now. It's easy enough to see this in normal uses of Ursol's Vortex. Then using Ursol's Vortex to apply DoC to a rip, one encounters the rip bug.

Now the ten dollar question: do I update the Ovale script to call for Ursol's? The idea of institutionalizing a bug bothers me...

Please keep in mind that because of the way the sim handles rip extensions it's actually getting 2/3rds of the extension time of what you would in practice, so the results are far from perfect. Unfortunately, there isn't an easy way to fix it because of the way DoTs are handled in SimC.