There is definitely some tweaking to do to the simulator, which is going to come with good discussions like this one. But, I think that we can approach Mr. Robot as more than just a beta at this point. Mr. Robot was not created purely as a simulator: it uses a simulator under the hood to achieve it's main purpose, which is gear comparison. We absolutely want to have these discussions to get the DPS numbers as accurate as possible, but, in the end, we care more about the relative value of gear.

Right now, Mr. Robot is accurately telling us which gear is an upgrade in 95% or more of cases - and that is just with the estimates. When you actually run the simulator it is giving us good results 99% of the time.

Tweaking the simulator is going to help us offer more features, such as enchant and gemming optimization, which require much higher accuracy.

I'll look into that arawethion. If I read what you are saying correctly, you're saying that the combat log shows a smaller resist number than it should, but the overall amount of damage that is resisted should be the same. In other words, I'm doing:

[buffed damage] * 0.9 = [final damage] for a 10% resist, and I say that 0.1 * [buffed damage] = resisted amount.

But the game actual does something like:

[damage] * 0.9 * [damage multipliers] = [final damage] for a 10% resist, and 0.1 * [damage] = resisted amount.

In both cases [final damage] is the same, but the combat log reports different resist amounts.


I did the research on resists quite a while ago, and unfortunately I didn't keep track of my source for the information... I tried looking it up again when I started the moonkin, but couldn't find it.

Currently I use this table for resists:

0.5756 chance for full damage
0.3372 chance for 10% resisted
0.0872 chance for 20% resisted


Allev -- the main reason that I changed it to wait for 2pc instead of doing 1cp savage roars was completely empirical... the simulator does a little more damage if I do it that way. I have to dig into why, but my assumption is that it has something to do with the timing and lining up of finishers at some point, and waiting for 2 results in a different outcome. Either way, the difference in DPS is extremely small, almost within the margin of error. It is possible that another condition elsewhere in the rotation would produce the same result, and allow 1cp savage roars to work better.

All of the conditions that you mention for not shredding unless you have a reason to do so are in both the SimC and Mr. Robot rotations, with the exception of "TF coming off cooldown." I'll play around with that one and see if it makes a difference, though due to the limited circumstances it will be minor at best.

Also, while I agree that an ability that does more damage per energy is better, it is not immediately clear to me that DPE is the whole story. Your highest DPE attacks are your cp-consuming moves, no matter what your gear level is. If I get to the point where shred is higher DPE than rake and drop rake entirely, I'm now spending more total energy on cp-generating moves than cp-consuming moves. In other words, my combo points have become more expensive. Now the difference here is probably pretty small, and we're splitting hairs at this point. I tried a rotation without rake on a character that had 100% ArP, and thus a significantly higher DPE with shred, and total DPS was almost identical to a rotation that contained rake. Thus, I am lead to believe that this incongruity between cp-generators and cp-consumers makes it more complex than simply "use your highest DPE attack, amen."

The physical damage part of the simulator has not had a "fundamental mechanical bug" in quite a long time. The caster damage part is newer, and with the help of arawethion and erdulf's testing, has become much better over the last couple weeks.

I fixed a minor timing issue with savage roar that you found -- not "fundamental", just a bug with a single action. And the issue that I mentioned with checking for the next action at a different interval is not likely to make a huge impact... we're talking about checking on the order of 100 milliseconds earlier for a condition here. At this point it is more of a curiosity thing on my part, to see if I can translate a SimC rotation into a Mr. Robot rotation and consistently get a similar result. It is quite possible that due to the different design of the simulators, you will need slightly different conditions to produce the same attack pattern in each simulator.

Right what, I was describing only affects the amount resisted in the log, not the actual damage. Doing it your way actually makes it easier to see how much damage is lost to resists, but it doesn't match the in-game log.

I've been poking around on this question recently and don't think anyone has a really solid answer. This post is a good summary:
General Mage Discussion and Information

He gets 6% here, which is what I've been using in WC. It also agrees with what I saw when I tested Nibelung. If you're not sure on your values, I'd just use the ones in his post until we get something better.

The rotation editor itself is a self-described alpha version. While you addressed the SR bug I found, what about the bug where SR wasn't working at all a few weeks back?

Intuitively, giving up damage is stupid. If your simulator says to do sething empirically stupid, isn't it more likely that you either have a bug, or the spec isn't right?

Thank you for agreeing that reducing rakes is a bad idea-- so why does your sim do it?

Finally-- the sim is probably fine for gear evaluation. But more important than gear (to me) is the specifications themselves-- an action list is effectively an interactive guide on how to play. You are right that we are talking about small margins, but those margins separate decent players from great ones.

I will continue to be skeptical, but that's actually a good thing-- I'm more likely to find bugs that way!

I disagree-- as a programmer, it hurts my head.
- It's amazingly unreadable. All the buttons to click for "not" and "and" and "or" plus not actually typing anything makes it a pain to use.
- The icons might save space, but since they're so big, they hurt readability.
- no "or" at the top level.
- the "difference in time remaining on X and Y", to me, implies that it's an absolute value, but it's not. At the very least it's not really clear. I think "time left on X minus time left on Y" would be more clear.

Other bugs:
- Most feral theorycraft puts the ashen ring proc worth only a small amount of DPS because of its low procrate, making the exalted version not even BiS. Whereas MrRobot is rating the revered version as 250 DPS better than any other ring.
- Just overall, something is wrong with the cycle and your percent damages. Only the worst ferals I know reach 38% auto-attack damage (since you can't affect white damage except through SR, the white-to-yellow ratio is a good indicator of good play). The number should be in the 33-36% range, depending on ArP (my character should be around 34%, since I have decently high haste but am only soft-capped ArP).
- So I looked at your "empirically 1SR is better than 2SR" statement. It turns out, most of the difference disappears if I set the CP check after the SR check. Weird. Then, I looked at the SR check itself. I switched out the "NOT have >=1 stacks of SR" with "target missing SR or less than 1 sec remains" and ended up losing 50-100 or so DPS. My DPS varied depending on how many CP I had at that point, which means it didn't invalidate the line, it's just being interpreted wrong (since refreshing SR one second early wouldn't cause a 50 DPS drop). If that line is broken, then the SimC profile would be significantly broken since it uses it a few times.

I think what he meant Allev is that a programmer will most certainly have a good grasp on conditional "if/then" logic flow right away, while a lay person will probably struggle with that concept somewhat, at least without big happy buttons and icons or a detailed wizard or tutorial. In that way a programmer will be able to "use it well". I agree, as Yellowsix indicated, that it could stand to have some UI improvement, but it's certainly functional at this time, and better than just a simple text box for typing (probably proprietary) code for non-programmers.

Moonkin looking at Mr. Robot (extremely nice UI by the by) and seeing something a bit confusing.

Using default rotation in both cases, with (customized) raid buffs, DPS is about where I'd expect it to be; however, with the self buffs setup it is far lower than that. Self buffed is lower than what I see in WrathCalcs, Rawr, and what I know from experience I can do on a dummy. 8.2k raid buffed, only 4k self buffed - the difference is usually not that great.

berseking uptimes in top25 dps @ saurfang 25man @ worldoflogs in 06.02.2010:

36.1 % -> Xsâra - 03.02.2010
61.3 % -> Superb - 03.02.2010
22.5 % -> Juushiro - 21.01.2010
23.4 % -> Ristaccia - 02.02.2010
19.1 % -> Pelletteria - 03.02.2010
43.7 % -> Bruni - 04.02.2010
27.1 % -> Spektrum 02.02.2010
14.6 % -> Redx - 28.01.2010
28.2 % -> Elassar - 02.02.2010
36.0 % -> Chuckboris - 04.02.2010
15.0 % -> Demnon - 28.01.2010
55.2 % -> Rhaia - 04.02.2010
52.5 % -> Odas - 03.02.2010
30.8 % -> Rashes - 27.01.2010


mongoose uptimes in top25dps @ saurfang 25man @ worldoflogs in 06.02.2010:
52.2 % -> Chilifaner - 02.02.2010
52.4 % -> Lastsoul - 03.02.2010
47.0 % -> Cymro - 04.02.2010
37.9 % -> Éule - 04.02.2010
32.5 % -> Phantastic - 03.02.2010
26.5 % -> Zinette - 03.02.2010
22.6 % -> Vaydoln - 02.02.2010
15.9 % -> Satrion - 03.02.2010
41.0 % -> Paskgotsheal - 02.02.2010



25 ppl is not enough for avarage but;
berserking avarage is %33~
mongoose avarage is %36~

i checked your simulator and it saying me %83.6 uptime for berserking, %83.5 for mongoose. i think there is huge differents with uptimes here.

btw list of top25 feral in saurfang is here:
World of Logs - Real Time Raid Analysis

You also have a selection bias in that higher uptimes on Berserking/Mongoose lead to more damage overall. Most average uptimes are near 33% across multiple theorycraft tools.

I have fixed a bug that was causing PPM procs for ferals to proc too often (basically it was using your equipped weapon's speed rather than 1.0 to calculate the proc rate). On my local version, I'm showing about a 45% up-time for mongoose using a 1 PPM proc rate... might be a little high, but it's closer.

Unfortunately I haven't had a lot of time to work on the simulator this last week, so it'll be another day or two before I can post an update.

I looked into it a little closer, and it appears that I was allowing physical-damage DoTs to trigger actions flagged as triggering on "physical". I've fixed that such that bleed ticks will only trigger actions specifically flagged to trigger on dot ticks.

So now the mongoose up-time is around 35%.