Jump to content


Photo

Team Robot Simulator and Gear Comparison Tool


  • This topic is locked This topic is locked
175 replies to this topic

#21 dedmonwakeen

dedmonwakeen

    Bald Bull

  • Members
  • 1,302 posts

Posted 06 January 2010 - 10:09 PM

I think the Druid SimC models are pretty solid. If you want another source of model verification, feel free to check out:

http://simulationcra...ne/sc_druid.cpp

#22 Allev

Allev

    King Hippo

  • Members
  • 545 posts

Posted 06 January 2010 - 10:17 PM

- Your base damage formula from Wowhead is what Toskk uses. Do you have Mangle increasing the initial Rake damage?

- The formula Toskk's uses is:
var player_crit_chance = 0.07476 + stats.crit / 45.90598679 / 100 + (stats.agility + extra_agility) * 0.012 / 100 + talents.sharpened_claws * 0.02 + talents.master_shapeshifter * 0.02 + talents.leader_of_the_pack * 0.05;
So 1) LotP, 2) I'm not sure about the base 5% number.

- Crit suppression is 4.8%-- typo in your post?

- I switched to a 0-agi-proc idol for the test. (BTW, can you clear out a slot item completely?)

- I saw the real stats for str/agi; I just want to see exact ArP/hit/expertise ratings so I know exactly how far away I am from the cap.

#23 Yellowsix

Yellowsix

    Piston Honda

  • Members
  • 166 posts

Posted 06 January 2010 - 10:47 PM

Yeah I have bleed damage percent modifiers affecting the initial rake damage...

Toskk's formula is pretty interesting and answers my questions: he is assuming 83.333333 agility/crit, and a "base" crit rate of 7.476%. As far as I can tell, there is no other way to determine this "base" number except empirically, and it is different for each class. I'll take toskk's word for it and implement it that way.

Yes I typed it incorrectly: 4.8% melee crit suppression is included in the displayed physical crit rate.


Before I post the update, I'll do some cross-checking with the simulationcraft code and toskk's stuff, thanks for the links.

#24 dedmonwakeen

dedmonwakeen

    Bald Bull

  • Members
  • 1,302 posts

Posted 06 January 2010 - 11:40 PM

And yes, a change to make it more target-health than duration centric may be in order, particularly when doing classes like warlocks and warriors. .


About half-way through the very first iteration:

initial_health = current_health * ( sim -> expected_time / sim -> current_time );

At the end of every iteration:

    double delta_time = sim -> current_time - sim -> expected_time;
    delta_time /= sim -> current_iteration + 1; // dampening factor
    double factor = 1 - ( delta_time / sim -> expected_time );
    if ( factor > 1.5 ) factor = 1.5;
    if ( factor < 0.5 ) factor = 0.5;

    initial_health *= factor;

You feed the sim "expected_time" and then each iteration the "initial_health" of the target is refined.

It converges very fast and I find that the average fight length after 100+ iterations is right on "expected_time".

#25 Yellowsix

Yellowsix

    Piston Honda

  • Members
  • 166 posts

Posted 07 January 2010 - 12:30 AM

Yes, that is an interesting approach.

I did some more thinking on it though, and here are some things to consider:

That approach is meant to deal with things like warriors or DKs with merciless combat: instead of saying "you can use execute once 80% of the fight's duration has elapsed." Well... it's really something more like 85% of the fight, since that last 20% will go more quickly.

Your approach would figure this out more accurately... if every DPSer in the raid were a warrior. This isn't usually the case though: what you want to know is for an average, balanced raid, how much more quickly does the end of the fight elapse?

Since this is a single-player simulator and not a full-raid simulator, you would probably get a better result by simply estimating the DPS curve for a typical raid setup and hard-coding those values when making health-percentage based decisions.

To make things a little more concrete:

1. If nobody in the raid had back-loaded damage abilities, you could use % of fight duration exactly: the last 35% of a boss's health is exactly 35% of the duration of the fight.

2. If every DPSer were a frost DK: they do 12.5% more damage with attacks that do about 50% of their damage for the last 35% of a boss's health. So about 6.25% more damage. The last 35% of a fight would elapse 6.25% more quickly. This means that a DK would have merciless combat active for roughly 33% of the fight instead of 35%.

3. From 1 and 2 it follows that the actual percent of fight duration that a DK could be in merciless combat for a real raid composition is somewhere between 33 and 35%.

4. Possible DPS specs: about 22 (blood dk, dw frost dk, feral, moonkin, arcane, fire, etc. etc.). Of those, I know of 5 that have back-loaded damage abilities: frost dk, fury warrior, arms warrior, fire mage, affliction warlock. I may have missed one or two though. So let's say roughly 1/3 of your DPSers can load it on at the end of a fight.

5. How much of an increase these abilities are and for how long if can be used varies... but assume that it is a similar boost as a DK's boost. This could be a bad assumption, but I would be surprised if any class got a much larger boost than that.

6. This means that from a full raid standpoint, you'll only see about 1/3 of a reduction in the duration of that last X% of a boss's health as if the entire raid were that one DPS class. So for a DK, the naive (current) approach that relies purely on fight duration would put you in merciless combat for 35% of the fight. Your new approach would put him in MC for about 33% of the fight. But in reality... he would probably be in MC for about 34.4% of the fight. In this case, the naive estimate is actually closer to a real fight.

7. Conclusion: using percent of fight duration will result in approximately a 0.3-0.4% overestimation of total DPS for a fight for frost DKs, but will probably result in a more accurate value than the approach that you suggest... assuming that I didn't totally screw something up in my assumptions above, which is very possible. I should really just use a static estimate based on some combat logs to shave a tad off.

#26 dedmonwakeen

dedmonwakeen

    Bald Bull

  • Members
  • 1,302 posts

Posted 07 January 2010 - 02:00 AM

7. Conclusion: using percent of fight duration will result in approximately a 0.3-0.4% overestimation of total DPS for a fight for frost DKs, but will probably result in a more accurate value than the approach that you suggest... assuming that I didn't totally screw something up in my assumptions above, which is very possible. I should really just use a static estimate based on some combat logs to shave a tad off.


I believe it is perhaps a bit more simple: When you end the sim at target-death, then you are perfectly accurate with respect to modeling Merciless/Execute/etc. As your OP suggests, why attempt a complex formulation when you can just model the actual behavior?

Of course, this is not free: The cost of perfectly modeling Merciless/Execute/etc comes at the cost of not perfectly modeling the requested combat length. Depending upon whether Bloodlust is used early/late the initial_health calculated in the first iteration is too high/low. The second chunk of code solves this by adjusting the initial health with a dampening factor.

While this adjustment zeros in on the appropriate target health to get the average desired combat length, each individual iteration will end early/late depending upon crits/etc. However, it is that same variance in combat length that dramatically smooths out haste scale factor generation.

I'm not looking to force-feed you my implementation, so I'll let it go. I just wanted to make sure that I at least explained myself well.

Great job, and keep up the good work!

#27 Calmwind

Calmwind

    Glass Joe

  • Members
  • 14 posts

Posted 07 January 2010 - 03:39 AM

Nice to see that a moonkin version is coming soon. I admit that I'm curious how the rotation editor is set up for the proc heavy/reactive moonkin rotation.
Also hello from Proudmoore, hope your raiding is doing well.

#28 Yellowsix

Yellowsix

    Piston Honda

  • Members
  • 166 posts

Posted 07 January 2010 - 06:57 AM

I believe it is perhaps a bit more simple: When you end the sim at target-death, then you are perfectly accurate with respect to modeling Merciless/Execute/etc. As your OP suggests, why attempt a complex formulation when you can just model the actual behavior?


If I understand correctly, simulationcraft models the entire raid team, not just one player. Thus, when a simulationcraft sim ends, it is indeed perfectly accurate. The Team Robot simulator simulates just a single character... the fact that I hit harder this time around has a small impact on the overall fight duration. It's the cumulative of every DPSer in the raid that has statistical significance. We made this trade-off for the sake of performance of course: our goal was a web-based tool that could give a reasonable result in just a couple of seconds.

But anyway, you have a very good point, and I'm going to think on the best way to incorporate that concept into our single-player, single-target simulator. We've already run into the haste-scaling issue with fixed fight lengths, hence the hokey "randomize" fight duration option. Your suggested formula with an appropriate reduction based on some statistics from actual full raids might indeed be the best approach.

#29 Yellowsix

Yellowsix

    Piston Honda

  • Members
  • 166 posts

Posted 07 January 2010 - 10:06 PM

I have posted a few updates that fix some of the bugs in the initial version. You can see the full list at WoW Simulator Change Log.

The default rotation is still a bit off... I didn't have time to play with it extensively. This update is mainly to get some high-priority bug fixes out there. Another update will be coming within the next couple of days that will incorporate many of the suggestions that people have made.

#30 Yellowsix

Yellowsix

    Piston Honda

  • Members
  • 166 posts

Posted 07 January 2010 - 11:46 PM

Just a clarification: for the time being, the default rotation is very simple and leaning heavily towards 100% rip and SR up-time. Hopefully tonight I'll have time to improve the conditions and work FB back in appropriately. I'm also going to add an up-time column to the summary for DoTs and buffs, which should make it easier to evaluate rotations.

#31 Mijae

Mijae

    Don Flamenco

  • Members
  • 443 posts

Posted 08 January 2010 - 12:53 AM

Someone may know the answer to this question... otherwise I'll go dig through the code for rawr or toskk's: if you look at the summary, the damage from the initial Rake hit looks to be significantly lower than my world of logs reports. It's not a really significant source of damage so it's not a huge deal... but it's irritating. The current formula that I use is this:

[176 + (AP / 100)]
* savage fury (1.2)
* physical damage multipliers (SR, blood frenzy, ferocious inspiration, etc.)
* bleed damage multipliers (mangle debuff)


I have stopped maintaining my spreadsheet, but I compared the numbers I was using against what Toskk's is using now. Some of the numbers are slightly different. I honestly don't know if values have changed and where exactly mine came from. I was extremely bad at maintaining sources for all my numbers. Some I tested myself, but they were all confirmed at the times I entered them (otherwise I would have marked them).

Rake base: 190 + AP/100
Rake bleed: 387 + AP*0.6
Shred: 666 + 2.26*base
Bite5: 1640 + AP*0.35

Otherwise, check if you are applying SR correctly to Rake including the glyph. The base damage can also crit.

#32 Allev

Allev

    King Hippo

  • Members
  • 545 posts

Posted 08 January 2010 - 01:22 AM

Did you stop updating your sheet before the base damage nerfs we got sometime in Ulduar?

#33 Mijae

Mijae

    Don Flamenco

  • Members
  • 443 posts

Posted 08 January 2010 - 06:21 AM

Differences between my 3.1.3 and 3.2.0 releases:

Mangle: 634 => 566
Shred: 742.5 + 2.25x => 666 + 2.26x
Swipe: 2.6x => 2.5x

I basically stopped playing during ToC and stopped updating. I never even added all of the heroic gear. Of course, it's possibly I missed some other changes. These low level details was the exact reason I was keeping it around as long as I did though. :rolleyes:

#34 Yellowsix

Yellowsix

    Piston Honda

  • Members
  • 166 posts

Posted 10 January 2010 - 01:01 AM

I have posted an update that addresses most of the remaining bugs. The complete list of changes is at WoW Simulator Change Log.

The feral rotation seems pretty good now, though I am sure that someone could do better than I have. If you are able to build a better rotation using the Team Robot simulator, please post it or send it to me, as I would be very curious to see how you did it! You can save and export rotations as XML -- there is a guide here: WoW Simulator Import/Export Feature.

A discussion point: for my character (Yellowsix of Spinebreaker, in roughly ilvl245 gear), I was trying to determine the best gems. The value of strength, agility, and armor penetration gems is very close -- I changed all sockets to one or the other, and saw very little difference in the final DPS. Same idea for yellow sockets: going with agi/haste or agi/crit or even str/haste or str/crit is very close in value.

I'll run some more simulations with other characters, but I found this to be interesting. The simulator output seems to be accurate (e.g. I compared the average damage for abilities to some of my combat logs and they were within 1-3% for all abilities, and the total number of each attack was reasonably close), so I must be at some cross-over point for the value of these stats.

#35 Allev

Allev

    King Hippo

  • Members
  • 545 posts

Posted 10 January 2010 - 03:38 AM

You're right, the total range of DPS from one stat to the other is very small. As you enter the neighborhood of soft caps, having half your points above a cap and half below means they all average out to be pretty accurate. Gemming was never supposed to alter final DPS more than a dozen or two DPS, at most (unless you're dealing with ArP hardcaps or hit rating). These are all within your default margin of error, and can thus be considered inconsequential in most cases.

#36 Jaconis

Jaconis

    Von Kaiser

  • Members
  • 38 posts

Posted 12 January 2010 - 05:48 PM

Awesome job guys, very well done. However, I ran a couple of simulations last night and I think I found a problem with the default rotation. During Berserk, it used TF if it got too low on energy, which seemed to get rid of the of the Berserk buff (it never made the statement that the buff had faded, but attacks had normal energy costs). This not only isn't possible in-game because TF can't be used during Berserk (at least according to the tooltip, I never tried myself), but for at least a couple of my simulations caused Berserk to end after only a few seconds.

#37 Yellowsix

Yellowsix

    Piston Honda

  • Members
  • 166 posts

Posted 12 January 2010 - 07:07 PM

You are right that I did not have the restriction that TF cannot be cast during Berserk. I have added that and will post it with the next update.

However, the default rotation should never do this, because Berserk is set to only cast if TF is currently active, which means that Berserk is only used while TF is still cooling down.

I could not reproduce TF causing Berserk's cooldown to finish prematurely. I ran some tests and checked the code as well. I also could not reproduce a situation where abilities started to cost full energy while the Berserk debuff was still active. Please let me know if the problem happens again, and if possible, post the combat log entries that look incorrect to you.

#38 Jone

Jone

    Piston Honda

  • Members
  • 215 posts

Posted 13 January 2010 - 12:05 AM

However, the default rotation should never do this, because Berserk is set to only cast if TF is currently active, which means that Berserk is only used while TF is still cooling down.


Hmm. Do you know that casting Berserk will remove the TF buff? I believe consensus was to use Berserk just after TF during the opening seconds of a fight, then to desynchronize them as much as possible without reducing how often you use them during the rest of the fight.

#39 Yellowsix

Yellowsix

    Piston Honda

  • Members
  • 166 posts

Posted 13 January 2010 - 01:07 AM

I didn't know that, but now I do! I'll change the default rotation.

#40 Ferehar

Ferehar

    Glass Joe

  • Members
  • 1 posts

Posted 13 January 2010 - 07:11 AM

This is just an amazing simulator! The fact that it's web-based makes it even more attractive. Just kind glitchy when setting filters for the gear upgrades, and some class/specs don't seem to load and work properly.

Great job Mr. Robot!




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users