Team Robot Simulator and Gear Comparison Tool - Page 2

Thundrul · 01/06/10, 3:39 PM

Nice work, love the interface.

I see some steps in the log with Energy>100 especially after OOc procs.

Allev · 01/06/10, 3:46 PM

Issues, issues, issues. I keep finding them because it's very easy to work with, though!

- Editing talents is clunky unless you're doing it from scratch. When you try manually changing from a 0/60/11 bear build to a 0/55/16 cat build that puts 4 points in Feral Aggression, you have to take points out of the bottom of the trees just to move things around.

- Default gemming of Agi isn't really a good idea for entry-level T10 gear. I don't enjoy switching an item and then needing to change every gem on it to something else-- either let the default be selectable, or let it follow the suggestions which the tool generates (it recommends hit in yellow slots, but populates Agi).

- is the upper right-hand corner stats supposed to represent character sheet, or results against level 83 mobs? Expanding that area to show absolute stats would help to verify it's adding numbers up correctly as well.

- Crit: something, somewhere is wrong. I set up a profile with no crit procs of any kind and only self-buffed, and also was hit-capped. The upper right-hand corner shows 43.6% crit, while the simulator shows 44.9% white crits, 41.3% rip crits, and 45.5% shred crits. Obviously you can't nail down the numbers with the number of simulations, but rip seems 4% different from the other attacks, and bleeds are 2% less than reference crit and melee attacks are 2% higher. The missing element isn't obvious, but something's wrong-- depending on what the upper-right stats are, you're missing crit depression, or always adding a buff/debuff you don't always get, something of that nature. Or you're using a bad number for crit depression, or applying it incorrectly.

- Hit: clearly over-valued. It looks like your energy return on yellow attacks is wrong. Your code does this: a dodged rip isn't reducing your energy at all. A missed Shred reduces your energy by 42. In game does this: All CP-generating attacks already only lost 20% of the attack's energy cost (or OoC), and with the Primal Precision talent, finishers act the same. So a dodged Rip reduces energy by 6. A missed Shred reduces energy by 8.2, depending on game rounding.

Yellowsix · 01/06/10, 4:16 PM

I'll try and get an update out tonight with some fixes -- here are the things currently on my list:

- character stats are a little off from what is displayed in the armory
- savage roar isn't consuming combo points
- energy is sometimes going over 100 (must be a rare case, I wasn't able to immediately reproduce)
- proc rate on OOC and 2t8 is a tad off (verify: is 2t8 a 2% proc rate (as seen on wowhead) or the same proc rate as "normal" OOC procs?)
- add some more advanced conditions/options that will allow better control around desynchronizing rip/SR timers and making decisions based on the glyph of shred
- tweak the default rotation logic a bit

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)

It is flagged as a bleed, so it ignores armor.

The base damage I just took off of wowhead... I'm wondering if it's not quite right.

Here's another minor thing that drives me nuts: "base" crit rate. Supposedly, everyone has a base 5% crit rate. Then you get a certain amount from agility. (And then of course crit rating, talents, etc.) If I take my druid's character sheet and use the number 77.075 agility per 1% crit and assume a 5% base crit rate, I get:

5 + (1643 / 77.075) + (14.62% from crit rating) + (6% sharpened claws) + (4% master shapeshifter) = 50.94%
But my character sheet says that I have a 56.81% crit rate... what am I missing?

edit:
- I'll fix the issue with energy consumption on missed/dodged atttacks
- I also noticed that the crit rate on rip ticks was lower than other attacks... which makes no sense to me... nothing jumped out at me, so I have to dig a little more on that one
- The crit rate reported in the stats in the upper-right subtracts melee crit suppression against bosses, so it should be 3.8% lower than your character sheet
- crit rates in the summary of a simulation will be a bit higher due to idol agility procs
- if you mouse over the stats in the upper-right, it shows you more stuff; I can add a few more stats to that list as well
- the default gemming is pretty simplistic right now... it just always does agility. I'll work on this a little bit... the logic for "default" gems is intentionally simple to avoid performance issues, but I can probably add a few more heuristics to make the defaults more appropriate

SaxJazz13 · 01/06/10, 4:37 PM

I see how to turn on and off the mangle debuff. What I think would be nice is the option to have mangle in the rotation. I am manglebot for my guild and therefor have to account for that whenever I run sims. If there is a way to put mangle in the custom rotation I'm all ears. My programming skills are nil so I have not a clue how. Feedback is much appreciated.

Yellowsix · 01/06/10, 4:52 PM

@SaxJazz13:

If you turn off the mangle raid buff, it will automatically switch to a rotation that includes mangle. In the "ROTATIONS" section at the top-right, there are 2 buttons: AUTO and CUSTOM. AUTO will attempt to choose a pre-defined rotation based on your current options. If you uncheck BLEED DAMAGE % in the BUFFS section, you should see the AUTO rotation toggle between manglebot/regular rotations. Feel free to PM me if that doesn't answer your question.

dedmonwakeen · 01/06/10, 5: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://simulationcraft.googlecode.co...e/sc_druid.cpp

Allev · 01/06/10, 5: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.

Yellowsix · 01/06/10, 5: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.

dedmonwakeen · 01/06/10, 6:40 PM

Originally Posted by Yellowsix

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".

Yellowsix · 01/06/10, 7:30 PM

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.

dedmonwakeen · 01/06/10, 9:00 PM

Originally Posted by Yellowsix

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!

Calmwind · 01/06/10, 10:39 PM

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.

Yellowsix · 01/07/10, 1:57 AM

Originally Posted by dedmonwakeen

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.

Yellowsix · 01/07/10, 5: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.

Yellowsix · 01/07/10, 6: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.