Best Possible Feral DPS in SimulationCraft - Page 3

Odas · 12/09/09, 10:56 PM

I tried doing a rough model of Deathbringer's Will by adding the following line to the profile

trinket2=deathbringers_will,stats=155arpen,equip=onattackhit_600agi_15%_30dur_315cd,equip=onattackhit_600str_15%_30dur_315cd,equip=onattackhit_600arpen_15%_30dur_315cd

. However, when I compared

trinket2=deathbringers_will,stats=155arpen,equip=onattackhit_600agi_15%_30dur_315cd

with

trinket2=deathbringers_will,stats=155arpen,equip=onattackhit_600agi_15%_30dur_315cd,equip=onattackhit_600str_15%_30dur_315cd

the trinket with only an agility proc came out higher. Are trinkets with multiple procs handled strangely?

ramenchef · 12/09/09, 11:08 PM

I was getting 38.5% melee and 8.2% FB, so a more FB aggressive player could probably get towards 50%. I just threw in a range to account for the majority of players.

ithecho84 · 12/10/09, 1:25 AM

Originally Posted by Odas

Ithecho84

Averaging over a proc duration is not the most efficient method of estimating its value, especially for stats like armor pen. 600 armor pen thats up 10% of the time is better than 60 armor pen up all the time because armor pen scales faster than linearly.

I tried modeling the trinket as having 3 different procs each with a 270 second cooldown in Rawr and it still was coming pretty far ahead of other trinkets. It also had some pretty strange effects on the value of armor pen. It decreased the value of armor pen when over the soft cap, but less so than Mjolnir does. I wish I could edit this trinket into simcraft but that is beyond my knowledge at the moment.

Yes, which is why I said it was very rough math, but it is a viable method of fleshing out values for it. Also, the 3 procs are not on seperate ICD's. If an agi buff procs, no other stat will proc for 90 seconds (estimated).

Originally Posted by Allev

Itheco, the logic of "going an entire fight sitting at half the ArP cap" fails, because by the same logic, it's possible you could spend 30% of the entire fight 600 over the ArP cap. Long-term, you'll spend about 10% of the time over cap-- half as much as with dedicated ArP trinkets, so less of a factor, but still a factor.

No, that logic doesn't fail. If you use the DW trinket's ArP proc to reach hard cap then you don't have a reliable method of reaching it. You can count on Mjolnir's to proc an ArP value every time it's off cooldown like clockwork because it's the only possible proc. DW has 3 possible procs, all of which are on a shared 90 second ICD. Thus, it's very possible to go an entire fight without proccing it. By the same logic, yes, you could get the ArP every single proc, but that's a 1/3 chance.

What I'm saying is that ArP will probably be the highest rated stat until static hard cap, and that the ArP proc from DW should not be given much significance. Which is all a moot point because the DW trinkets are BiS even with the null value of its ArP proc.

Odas · 12/10/09, 1:44 AM

The reason I modeled the trinket as if it had three separate procs each with a 315 cooldown was because that gives the same average uptime of each of the three procs. The downside is it will overestimate because of times when more than one proc is up (which in reality would never happen because they share a cooldown).

dedmonwakeen · 12/10/09, 9:34 AM

Originally Posted by Odas

I retract my previous statement about the cooldown. It appears to be 105 seconds.

A SimC release is imminent. Give me your best-guess on the proc chance and I'll code it up before I ship.

EDIT: Odas, Unfortunately, SimC does not support multiple "equip=" tokens in gear descriptions......

dedmonwakeen · 12/10/09, 10:17 AM

// register_deathbringers_will ==============================================

static void register_deathbringers_will( item_t* item )
{
  player_t* p = item -> player;

  item -> unique = true;

  struct deathbringers_will_callback_t : public stat_proc_callback_t
  {
    deathbringers_will_callback_t( player_t* p ) :
      stat_proc_callback_t( "deathbringers_will", p, STAT_STRENGTH, 1, 600, 0.35, 30.0, 105.0 ) {}

    virtual void trigger( action_t* a )
    {
      if ( buff -> cooldown_ready > sim -> current_time ) return;

      static int death_knight_stats[] = { STAT_STRENGTH, STAT_HASTE_RATING, STAT_CRIT_RATING };
      static int        druid_stats[] = { STAT_STRENGTH, STAT_AGILITY,      STAT_ARMOR_PENETRATION_RATING };
      static int       hunter_stats[] = { STAT_AGILITY,  STAT_CRIT_RATING,  STAT_ATTACK_POWER };
      static int      paladin_stats[] = { STAT_STRENGTH, STAT_HASTE_RATING, STAT_CRIT_RATING };
      static int        rogue_stats[] = { STAT_AGILITY,  STAT_ATTACK_POWER, STAT_ARMOR_PENETRATION_RATING };
      static int      warrior_stats[] = { STAT_STRENGTH, STAT_CRIT_RATING,  STAT_ARMOR_PENETRATION_RATING };

      int* stats=0;

      switch( a -> player -> type )
      {
      case DEATH_KNIGHT: stats = death_knight_stats;
      case DRUID:        stats =        druid_stats;
      case HUNTER:       stats =       hunter_stats;
      case PALADIN:      stats =      paladin_stats;
      case ROGUE:        stats =        rogue_stats;
      case WARRIOR:      stats =      warrior_stats;
      }

      if ( ! stats ) return;

      buff -> stat = stats[ (int) ( sim -> rng -> real() * 2.999 ) ];

      stat_proc_callback_t::trigger( a );
    }
  };

  p -> register_attack_result_callback( RESULT_HIT_MASK, new deathbringers_will_callback_t( p ) );
}

Checked in at revision r4085.

EDIT: simc-330-1 released, includes support for Deathbringers Will

EDIT2: simc-330-1 released, includes broken support (unless you are a warrior) for Deathbringers Will (i'll have a fix out tonight..... waiting to see if other bugs shake out)

Allev · 12/10/09, 2:26 PM

Recently, a poster on the main SC site claimed about the scale factors he was seeing-- particularly, that strength was over-valued and agility was under-valued. In researching why this was, you can come to some pretty fast conclusions that we don't have everything figured out, or we need to broadcast reality a little wider than we currently do. The three main topics are:

1) Is agility losing too much potency as it approaches the soft hit cap? If so, how much? Is agility "too bad" after the white hit cap?

2) Are we wasting CP in the profile, thus artificially reducing the value of crit? Is this enough to explain issue 1? How do we do this better?

3) Is hit/expertise "too good"? Can we isolate the concrete stat gains (i.e. more hit/expertise enables more attacks to crit) from possible issues with the profile?

I've done some quick research on point 3, and the initial returns are that by loosening some variables in the profile (relaxing precision timings) you can lessen the value of hit/expertise relative to other stats; however, this also mildly reduces overall DPS. Unlike traditional thought on the topic, though, this implies that the better you play, the more worthwhile hit/expertise are. Traditional thought is hit/expertise are better for novices because they're more likely to not notice an attack missing.

However, it's a big deal to predict that hit/expertise are the best feral stats now, so further research is necessary.

Odas · 12/10/09, 6:43 PM

I did some fiddling around with this profile using mostly 264 gear and I found some interesting things.

1. I seemed to get the highest DPS when I was hard armor pen capped even though when I dropped just below the armor pen cap the value of armor pen was even lower than attack power.

2. Strength was passing agility for the most part, and I even managed to get haste to pass both of them at one point (although that is not the case with the most recent profile).

3. Being hit and expertise capped seems to be the way to go.

4. Swapping [Deathbringer's Will] with [Death's Verdict] resulted in a DPS loss even when at the armor pen cap. Its possible that it would not if you stayed at the cap after you swapped the trinket (the profile I ran was below the cap because it lose the passive armor pen gained from [Deathbringer's Will] itself).

5. [Idol of the Crying Moon] does not seem to be working.

I used [Hearty Rhino] to reach the cap, so that would be an easy swap to lower your armor pen when equipped with 277 gear.

Starfox · 12/10/09, 8:59 PM

Originally Posted by Odas

I did some fiddling around with this profile using mostly 264 gear and I found some interesting things.

1. I seemed to get the highest DPS when I was hard armor pen capped even though when I dropped just below the armor pen cap the value of armor pen was even lower than attack power.

2. Strength was passing agility for the most part, and I even managed to get haste to pass both of them at one point (although that is not the case with the most recent profile).

3. Being hit and expertise capped seems to be the way to go.

4. Swapping [Deathbringer's Will] with [Death's Verdict] resulted in a DPS loss even when at the armor pen cap. Its possible that it would not if you stayed at the cap after you swapped the trinket (the profile I ran was below the cap because it lose the passive armor pen gained from [Deathbringer's Will] itself).

5. [Idol of the Crying Moon] does not seem to be working.

I used [Hearty Rhino] to reach the cap, so that would be an easy swap to lower your armor pen when equipped with 277 gear.

@5: Oops, forgot to rename then. (t10_feral_relic :S) Fixed in r4101

Furion · 12/11/09, 6:09 AM

Edit: I created a different thread for discussing my script in order to keep this thread clean.
http://elitistjerks.com/f73/t84378-v...ovale_scripts/

ithecho84 · 12/11/09, 3:54 PM

Originally Posted by Odas

The reason I modeled the trinket as if it had three separate procs each with a 315 cooldown was because that gives the same average uptime of each of the three procs. The downside is it will overestimate because of times when more than one proc is up (which in reality would never happen because they share a cooldown).

That completely eliminates the RNG nature of the procs though. I understand RNG is hard to model but you have to realize that when it comes to actual in-game mechanics, RNG is very much a factor that has to be accounted for.

Also, having a str or agi proc up at the same time as the arp proc would very much skew the numbers.

Elentor · 12/11/09, 3:59 PM

Originally Posted by Furion

Script

There are many weird things going on at the moment.

First, it suggests Savage Roar far too often. There are times I have 4 combo points and 12 seconds left on Roar, and it suggests Roar.

Rip and Rake often are shown with a timer when the debuffs have already gone from the target seconds ago, which is weird.

I'll try to report any other oddity, but there are more I'm forgetting.

Allev · 12/11/09, 7:26 PM

Originally Posted by ithecho84

That completely eliminates the RNG nature of the procs though. I understand RNG is hard to model but you have to realize that when it comes to actual in-game mechanics, RNG is very much a factor that has to be accounted for.

Also, having a str or agi proc up at the same time as the arp proc would very much skew the numbers.

For ballparking right now, you could simply run 3 sims, one with a 105-second STR proc, one with a 105-second AGI proc, and one with a 105-second ARP proc, and average them together. Since the only factor cycle-wise that this should affect is CP generation during procs, and there's 45 seconds between the end of a proc and the start of another one, they should be sufficiently isolated enough to not impact things. This would simultaneously give you "worst case proc" and "best case proc" numbers, barring the cases where they're very close.

Something that's very interesting, though, is how little the RNG matters, long-term. Think of each player's DPS as a coin flip: bad (0 DPS) or good (1 DPS). If you flip 100 coins, chances are you're going to end up with a number around 50.

And that's what RNG is like with the raid. Your personal DPS may vary by 500 up or down based on RNG; but that in itself is a combination of lots of attempts which most likely end up close to the center. When you add a ton of bell-curve distributions together, you get a final distribution that's extraordinarily more likely to be close-to-average.

You can see this in action in SimulationCraft: a feral simulated independently will have fight lengths that vary up to 25 seconds away from the 300 second limit, because the fight length is determined based on DPS consistency from the first half of the fight to the second-- sometimes you get lucky early, and sometimes you get lucky late, and your individual DPS is RNG-affected. But full raids only vary a few seconds at most, because the sum of the individual RNGs regress towards the mean.

Furion · 12/12/09, 2:34 AM

Originally Posted by Elentor

There are many weird things going on at the moment.

First, it suggests Savage Roar far too often. There are times I have 4 combo points and 12 seconds left on Roar, and it suggests Roar.

Rip and Rake often are shown with a timer when the debuffs have already gone from the target seconds ago, which is weird.

I'll try to report any other oddity, but there are more I'm forgetting.

Please don't quote the whole script it messes up the thread. Apart from that I have to say that your results seem very weird and I think you didn't use my script but the default one as I remember it suggesting SR with 12 seconds left. The default script is, apart from producing much lower dps, useless as it won't even detect Mangle from other players (which I think is due to some bug) so I had to do a complete rewrite.

Try to copy and paste my current script ingame into interface->addons-> ovale and press "accept" afterwards. I'll keep updating it as I find problems for now.

Elentor · 12/12/09, 5:24 AM

Originally Posted by Furion

Please don't quote the whole script it messes up the thread. Apart from that I have to say that your results seem very weird and I think you didn't use my script but the default one as I remember it suggesting SR with 12 seconds left. The default script is, apart from producing much lower dps, useless as it won't even detect Mangle from other players (which I think is due to some bug) so I had to do a complete rewrite.

Try to copy and paste my current script ingame into interface->addons-> ovale and press "accept" afterwards. I'll keep updating it as I find problems for now.

Fixed the post. Seems I'm having a problem with Ovale, it keeps reseting the script (as well as everything else, including the profile) everytime I perform an action.

Furion · 12/12/09, 7:46 AM

Originally Posted by Elentor

Fixed the post. Seems I'm having a problem with Ovale, it keeps reseting the script (as well as everything else, including the profile) everytime I perform an action.

Then let me suggest the following alternative process:
Exit WoW
Delete YourWoWFolder\WTF\Account\YourAccountName\SavedVariables\Ovale.lua and Ovale.lua.bak
Open YourWoWFolder\Interface\AddOns\Ovale\defaut\Druide.lua
Replace the existing script in that file with mine + save the chances

Rooki · 12/12/09, 8:20 AM

Originally Posted by Furion

Any testing/criticism is very welcome.

Tested for five 10 min blocks so far on a boss dummy, results have so far been at a minimum on par with those from following FBN.

Furion · 12/12/09, 8:50 AM

Good to hear. New version up, should squeeze out a few more DPS. The ovale logic isnt hard to understand so I think working on this is a very good way to optimize DPS as it is very easy to modify and understand for many people (I have no programming or addon creation experience and just read a few example scripts + ovale documentation before creating this).

Edit: Would it be a better idea to move the ovale+custom script discussion to a new thread? I can't tell but ovale isn't linked to simcraft anywhere close to the way the FBN move suggester was linked to the FBN simulator.

Allev · 12/12/09, 1:20 PM

You're correct, they aren't related at all. I do believe you want a new thread, I'm just not sure if it's in this forum or the UI forum. I'd definitely contact the Ovale author to get the feral script replaced.

Back on topic!

The conversion to the "new" way of specifying buffs/debuffs/etc will be an effort in itself, but it is allowing us to specify more complicated logic and get decent DPS increases. Now, we can specify burning energy when TF is coming off of cooldown with the following line:

actions+=/shred,if=cooldown.tigers_fury.remains<=3

For my profile at least, adding this condition increases DPS by about 50 points. More changes coming soon.

Odas · 12/12/09, 6:44 PM

Apologies if this information is available elsewhere, but I wasn't able to find it. Is it possible to check the difference between dot durations in Simcraft? It seems to me like the feral model does not do very well as desynchronizing rip and roar, so I was trying to make a suggestion like

actions+=/savage_roar,if=dot.rip.remains-dot.savage_roar.remains<2

Ideally I would check the absolute value of the difference but I think a lack of that function could be worked around with liberal use of conditions.

Also, I was not able to figure out how to make a condition that required omen of clarity to be off. For example I don't think tiger's fury, berserk, or ferocious bite should be used if omen of clarity is active but I think they are.

dedmonwakeen · 12/13/09, 1:44 PM

Just make sure you use parens to make sure you get want you want. The expressions follow standard C precedence.

actions+=/savage_road,if=!buff.omen_of_clarity.up&(dot.rip.remains-buff.savage_roar.remains)<2

Odas · 12/15/09, 7:25 PM

When running various simulations at and around the armor pen cap I have had issues with Simcraft's estimation for the value of armor pen point for point. Unlike hit and expertise rating which both continue to show how much value they would be worth if the cap did not exist, armor pen does not. More importantly, when just below the armor pen hard cap the value of armor pen is vastly undervalued (I consistently get more value for one point of attack power than one point of armor pen). I believe this is partly because in order to get a stable value for the increase you find how much dps increase would result from a large amount of armor pen then divide the difference in dps by that number. Thats the reason hit and expertise measure dps loss for each point deficit correct?

I also was still not able to get the line

actions+=/savage_road,if=(dot.rip.remains-buff.savage_roar.remains)<2

to work. It resulted putting that line in resulting in the error "Unable to build expression tree from (dot.rip.remains-buff.savage_roar.remains)<2" and then crashing completely.

Allev · 12/15/09, 7:41 PM

On the scaling: you're exactly correct. To change the amount of stats measured in the scale factors, you need to create overrides-- essentially add this line of text to the override panel (if using simqt) or to any file (if using command line):

scale_armor_penetration_rating=150

Change the 150 to the distance you are from the hard-cap; if you're really close to the cap, you may not get a stable result unless you use a center-scale delta (in which case you double the scale_armor_penetration_rating) by adding this line:

center_scale_delta=1

If you're measuring a really, really small value, you can increase the iterations of the test (beyond 10000) by adding the override:

iterations=10000

And replacing 10000.

All of these examples you can grab off of the "Examples" tab in simcqt.

Starfox · 12/15/09, 9:27 PM

Originally Posted by Odas

I also was still not able to get the line

actions+=/savage_road,if=(dot.rip.remains-buff.savage_roar.remains)<2

to work. It resulted putting that line in resulting in the error "Unable to build expression tree from (dot.rip.remains-buff.savage_roar.remains)<2" and then crashing completely.

On a first not: 'savage_road' is not a valid action ;D
The rest works for me, but I use the latest revision from trunk, what version where you using?
There was a bug with arithmetic operations between tokens.
That it crashes completely afterwards should also not happen, regardless of the problem with the expression tree.

Allev · 12/16/09, 11:22 AM

I actually find simcqt crashes often when you're editing profiles and your syntax is wrong. Sometimes you get a nice fail message in the log, sometimes it just dies. The same errors tend to produce the same results: if it crashes once, it'll crash every time, if it adds an error to the log, it will every time. This is running on Windows 7.

I'll write up how this happens a little more next time I go profile-revising.