Quote:
It is too hard to tell whether something will be a small DPS increase.
No, it's not.
Some things are obvious as far as coding goes.
Furion's Work wrote:
if ComboPoints(more 2) and BuffExpires(ROAR 8) and TargetDebuffPresent(RIP mine=1) and at most 3s from TargetDebuffExpires(Rip mine=1) until BuffExpires(ROAR) and TargetDeadIn(more 8) Spell(ROAR priority=4)
In Furion's piece here, if your combo points are more than 2, SR expires in 8 or less, Rip is present:
You're quite likely to SR depending on how much time is left on rip relative to roar. The question is, is it needed to always renew SR just because those events occur? Are there no other events that should help dictate? It's like a flat rule set whether you've got 3, 4, or 5 combo points.
You could complicate it and split it into two pieces:
The first for 3 & 4 combo points
And the second for 5 combo points
At first, it'd basically look like two identical pieces of code except one says "if ComboPoints(more 2) and ComboPoints(less 5)"
3 or 4 and the other says "if ComboPoints(more 4)"
5 In the first piece, you could add an omen of clarity check (unless BuffPresent(OMEN)) so that the code doesn't execute if you do have ooc proc. By doing this, the script would move down to the next part that should be executed. Which would be where the code says that if ooc is present, you should shred. You consume no energy to do the shred, you push closer to a 5point roar from a 3 or 4 point roar, and you allow a new ooc proc to possibly proc directly behind when the first was consumed (We should all try to use ooc procs as quickly as we can so a new one can proc in its place; it can't proc if it's already there). The way it is on EJ, you would SR first and let the proc sit there til after, all while you still have 6, 7, or 8 seconds left on Roar.
In the second piece, you wouldn't want to consume the ooc proc immediately because you'd already be at 5 combo points... so for this one, you wouldn't add an "unless" command for ooc and just let it suggest to you to SR whether ooc proc is there or not. To consume an ooc proc with a shred immediately while already at 5 points, would benefit you ever so marginally in that a new ooc might proc right behind it, but you'd be throwing away future combo points. So in that piece, you would want to Roar first, and then consume the ooc proc after to help build to the
next 5 combo points.
A small recap: Split the SR code into two pieces to better take advantage of ooc procs, the first for 3 & 4 combo points where you do consume ooc proc before SR, and the second for 5 combo points where you SR before using the proc.
When you read this small change by itself, it might seem simple to some of you reading. But now add an energy check into those two pieces. I'll ask a question: What benefit is it to you to clip SR just because Ovale says it'd be a good time to do so, if by doing so you have zero energy directly after the renewal of the SR? You clip SR at 8 seconds remaining only to find yourself at zero energy? Why not just wait 2 more seconds, and clip with SR at 6 seconds remaining, so you will have pooled up the energy to do something immediately after you renew SR? By doing this, you will have kept 2 additional seconds on the old SR before doing the new SR all because you knew you wouldn't be able to do anything immediately after the SR anyway.
You're moving along, and then SR expires in 8 or so seconds, you had just shredded down to basically zero energy (because of a rip extension as furion's code does prioritize rip extending shreds some), and now the addon says to SR while you're at 22 energy. Seemingly instantly, you're at the 25 energy required to SR and so you do, putting you down to zero energy, or 10 directly after the global. As the addon was telling you to redo SR, rake fell off. But you have to wait nearly 2.5 secs (25 more energy plus the 10 after you SR'd) before you can renew the rake.
So in the first piece for the 3/4 combo point Roars, you add an energy check for 48+ energy if rake will expire within 1 second. Now, you won't be told to SR unless you can immediately follow it up with the rake that's about to wear off. So instead of clipping at the 8 seconds left on SR, maybe you clip at the 6 seconds, which means you got two more seconds out of the old Roar, simply because you knew you wouldn't be able to do anything after the Roar's 25 energy was consumed because you'd have to just sit there with no energy after you roared.
So instead, it looks like this:
You're moving along, and then SR expires in 8 or so seconds, you had just shredded down to basically zero energy (because of a rip extension as furion's code does prioritize rip extending shreds some), and now the addon says to SR in grey while you're at 22 energy. From there, your energy pool ticks up to 48 (instead of 25), and it lights up to SR (48-25cost +10 within the global =33 energy or at most 200 milliseconds until you could rake) (because it's been coded to check energy and when rake will expire). Immediately after you clip the 6secs remaining SR, you renew the rake that was falling off basically at the same time. And now, you've gained 2 secs on the old Roar and lost nothing. How much is that worth in terms of DPS? How often does that exact scenario come up?
Now, add mangle to the SR code because it follows almost the same rules as rake as far as how you try to maintain it.
How complex can I really make the code? How long before energy checks and mangle/rake timer checks etc before it becomes a headache to try to come in behind someone else and fix an error or update the code because they quit and no longer play (look at fbn)? I think my personal code is 3 times as long as Furion's because of micro managing like this.
You don't always have to test something a thousand times to know if the change is for the positive or the negative.