Visualising the optimal cat rotation ingame - Page 11

sakkie69 · 01/08/10, 10:27 AM

Hi there,

Thanks for improving the Ovale scripts. I've been following this since inception, and you guys are doing a fantastic job.

For the posters that are noticing a decrease in DPS, I am running this side by side with FBN and notice that with Ovale the dps is lower (normal man 25 single target fights like Saurfang, Anub etc) (2pc 264 T10, 2pc 245 T9)

Quite often I find the Ovale timer showing the next move as red/black/greyed out while FBN showing the next attack as ready, with enough energy to do it. But otherwise the suggestions between the two addons are "close", with the next move suggestion being the same for probably 3 ouf ot 5. There will obviously be differences are both have different mechanics.

I'd like to help out as much as I can possible, so if there are any requests for data I will also try to contribute

NaturesVoice · 01/08/10, 10:53 AM

@sakkie69 FBN never pools energy that's why it's always ready

I to feel like the Ovale project can still do better but I'm very pleased with it sofar.

btw I tried Furions suggestion

if ComboPoints(more 2) and BuffExpires(ROAR 8) and {at least 0s from BuffExpires(ROAR) until TargetDebuffExpires(RIP min=1) or at most 3s from TargetDebuffExpires(RIP min=1) until BuffExpires(ROAR)} Spell(ROAR)

instead of

if ComboPoints(more 2) and TargetDebuffExpires(RIP 6 mine=1) and BuffExpires(ROAR 6) and less than 3s between BuffExpires(ROAR) and TargetDebuffExpires(RIP mine=1) Spell(ROAR priority=4)
if ComboPoints(more 2) and BuffExpires(ROAR 6) and less than 6s between BuffExpires(ROAR) and TargetDebuffExpires(RIP mine=1 forceduration=22) {unless TargetDebuffExpires(RIP 6 mine=1) Spell(ROAR priority=4)}

this made it better for me, more smoother to keep rip/roar up. I still get in the situation sometimes of only having 3 seconds to generate 5 combo points to get rip back up but it happens a lot less often. I guess with end game gear 3 seconds is enough time to get 5 combo points so it's not a problem with the code.

jasn345 · 01/08/10, 11:42 AM

is it possible to get this working on a german wow ?

sakkie69 · 01/08/10, 1:16 PM

Originally Posted by NaturesVoice

@sakkie69 FBN never pools energy that's why it's always ready

Yes, I saw that hence I mentioned it. People that were comparing DPS between the two might not have had both showing at once and didn't see it, and the short little bursts inbetween refreshes that you get with FBN might be the reason it has slightly higher numbers in certain fights.

Leafkiller · 01/08/10, 2:40 PM

If you think the energy pooling is an issue with your dps, a simple change you can test is the shred line towards the end of the script:

if Mana(more 69) Spell(SHRED priority=2)

You can lower the minimum mana to 41 for example. I am skeptical that this is an issue as I have been watching my energy bar to see if it pegs over 100 when energy pooling is happening and I have not been seeing that. My guess is that if you remove energy pooling it will slightly lower rip uptime. Reiterating what many have said before, RNG plays a large role in dps on any given fight - and can easily give you +-500dps on a given fight - so trying to compare how two scripts are functioning based on your dps numbers is not meaningful.

Ironhyde · 01/08/10, 4:14 PM

FBN does indeed pool energy.

FeralbyNight (Cat & Bear simulation tool)

bottom of the page

Allev · 01/08/10, 5:16 PM

Originally Posted by Leafkiller

If you think the energy pooling is an issue with your dps, a simple change you can test is the shred line towards the end of the script:

You can lower the minimum mana to 41 for example. I am skeptical that this is an issue as I have been watching my energy bar to see if it pegs over 100 when energy pooling is happening and I have not been seeing that. My guess is that if you remove energy pooling it will slightly lower rip uptime. Reiterating what many have said before, RNG plays a large role in dps on any given fight - and can easily give you +-500dps on a given fight - so trying to compare how two scripts are functioning based on your dps numbers is not meaningful.

Just to be on the safe side-- we've now had several people come in and say that Ovale isn't doing as well as FBN. You'd think we'd have equal numbers both positive and negative if it were all RNG.

chetal · 01/08/10, 5:48 PM

Originally Posted by Allev

Just to be on the safe side-- we've now had several people come in and say that Ovale isn't doing as well as FBN. You'd think we'd have equal numbers both positive and negative if it were all RNG.

I have ran many tests on heroic training dummies to compare the two but have not found any real difference between the two. Both FBN and Ovale give me between ~6150-6300 DPS over 6 minutes. The difference people report is probably due to reaction time since Ovale does not give a future projection.

ramenchef · 01/08/10, 5:58 PM

What people don't realize is that ovale was designed with the assumption that you would be fully raidbuffed. FBN on the otherhand, used an on the fly approach when predicting the next move, based on your current stats. This includes seeing your stats go up when something procs. As a result. FBN shows higher dps on dummies as it detects that you don't have buffs and modifies the rotation accordingly.

Allev · 01/08/10, 7:16 PM

Where is FBN doing any calculation based on your current stats? Here's the relevant code from the simulator:

//shred?
						
						else if ((en>=shred.energy) && (cp<5)&& ((((koj_timer<((shred.energy+rake.energy-10-en)*10) && 
						((mdebuff_timer > ((shred.energy+mangle.energy-10-koj_m1-en)*10) && ((rake_timer > ((shred.energy+rake.energy-10-koj_m1-en)*10))||(rk==0))
						  && (cp<3) && (mdebuff_timer >= 100+lag) && rake_timer>(0) )||((sr_timer<(100+lag))&&(en>(rake.energy+sr_energy-10)))||((rip_timer<(100+lag))&&(en>(rake.energy+sr_energy-10)))||(koj_timer<(100+lag))))||(((mdebuff_timer > ((shred.energy+mangle.energy-10-en)*10) 
					      &&(( rake_timer > ((shred.energy+rake.energy-10-en)*10))||(rk==0)) && (cp<3) && (mdebuff_timer >= 100+lag) && ((rake_timer>0)||(rk==0)) )
					      ||((sr_timer<(100+lag))&&(en>(rake.energy+sr_energy-10)))||((rip_timer<(100+lag))&&(en>(rake.energy+sr_energy-10)))||(koj_timer<(100+lag)))))||((cp>=3)||(rip_timer<0)))||(time_to_die_boss<=kill_mode)))

All of that is dependent upon CP, timers, and energy, not player stats. There's some basic stuff about whether your shreds will be stronger than your rakes, but that will be true 100% of the time for anyone with 2T9 or 4T10.

Now, that's not to say it's not a great idea-- but that'll require research into where exactly the stats thresholds are.

ramenchef · 01/08/10, 7:57 PM

Hrm, that's what Nightcrowler said that his addon/simulator would do, so I wrongly assumed it did. I tried to look over his code once before, but he didn't break it up into libs and modules, making it difficult to sift through. I do seem to remember it not suggesting rake, though, whenever mjolnir procced, further strengthening my misconceptions. It probably just scanned the player for certain ArP buffs to check rake vs shred dpe.

NaturesVoice · 01/09/10, 2:08 PM

Ok the differences between FBN and Ovale are interesting to me. In the past I've used FBN and now I'm trying Ovale. I also did some raiding with both addons on at the same time. The one thing that caught my eye was the following:

FBN does indeed pool energy and does it more efficient than the Ovale script. I discovered this while raiding with both FBN and Ovale active. What often happens with Ovale is that you pool energy, Tigers Fury is ready and you're at around 50 energy which is not optimal to use Tigers Fury. Therefor you first get rid of some energy and afterwards use the TF. The end result in long fights is simply less use of TF.

Now what I tried to do with the script is to work around this. Unfortunately I could not find a command to say something like; unless Spell(TIGER)in (less 3) so I had to be creative.

I replaced

if Mana(more 69) Spell(SHRED priority=2)

with

unless BuffGain(TIGER 28) Spell(SHRED priority=2)
{if BuffGain(TIGER 28) 
 if Mana(more 69) Spell(SHRED priority=2)}

What it does is it checks if Tigers Fury has been used in the past 28 seconds (TF has a cooldown of 30sec), if it was used then it should continue to pool energy as normally, if it wasn't used in the past 28sec (which means there are 2sec left till it's up) you are allowed to use the energy a bit earlier so you can make use of Tigers Fury as soon as it's ready.

I hope this makes sense and maybe it can be written in a more easier way because I missed some kind of command.

Furion · 01/09/10, 3:32 PM

if TargetDebuffPresent(Rake 0.4 mine=1) and {Mana(more 79) or BuffPresent(OMEN) or {TargetDebuffExpires(RIP 2 mine=1) and ComboPoints(less 5)} or BuffPresent(BERSERK) or 2s before Spell(TIGER) or {ComboPoints(less 1) and BuffExpires(ROAR 2)}} Spell(SHRED)

That's most of my current shred suggestions including what you want to do with TF.

Leafkiller · 01/09/10, 3:52 PM

Originally Posted by Furion

if TargetDebuffPresent(Rake 0.4 mine=1) and {Mana(more 79) or BuffPresent(OMEN) or {TargetDebuffExpires(RIP 3 mine=1) and ComboPoints(less 5)} or BuffPresent(BERSERK) or 2s before Spell(TIGER) or {ComboPoints(less 1) and BuffExpires(ROAR 2)}} Spell(SHRED)

I am wondering if there are a couple of typos in there Furion. Shouldn't it be at least be:

if TargetDebuffPresent(Rake mine=1) and {Mana(more 69) or BuffPresent(OMEN) or {TargetDebuffExpires(RIP 3 mine=1) and ComboPoints(less 5)} or BuffPresent(BERSERK) or 2s before Spell(TIGER) or {ComboPoints(less 1) and BuffExpires(ROAR 2)}} Spell(SHRED)

(I changed the Rake test to remove the "0.4" and changed the mana check to 69 from 79).

Also, did you intend to lower the debuf expires check on RIP from 4 to 3 (it is 4 in your 2.2 script).

Furion · 01/10/10, 4:09 AM

Numbers are tested with simcraft you can find most of it in the best possible dps in simcraft thread. And there are actually supposed to be 2 rip checks in the script one with 2 seconds left near the end (=lower priority) to build cp for your next rip and one near the beginning (=higher priority) with 4 seconds left to extend rip.