I don't add anything to crit modifier. I calculate the crit chance and then multiply the damage according to the calculated crit chance and a given crit modifier. I could've also written down the crit chance calculation which would be:

CritChance=1-((1-KM*Meleecrit)^(AbilityDelay*(1/MHSpeed+1/OHSpeed)))*(1-AbilityCrit)

What I do is calculate the chance that KM is not up and then modify that according to the crit chance, so I'm having 1(=100%) minus the chance that KM is not up AND it doesn't crit.

@your last statement: The formula in my post above is the total crit damage calculation for HB/FS/IT, it's not just the part of "how much crit does KM give you?". I've done this because I made that formula directly for Methods' spreadsheet that doesn't separately calculate the crit chance.

Edit: Now I got it, you're thinking that the crit modifier is the modifier for the damage the abilities do if they crit. That's not what it is, it's the average modifier an ability has through crits. So if IT crits for 50% and you're not specced into GoG, this would be 1.5.

Sorry if I don't always put things into clear words, English isn't my native language.

My formula looks very exact to me with the only assumptions being that the attack speed and melee crit chance are relatively constant.

Kurokaze, in the DW thread you wrote your way of calculating KM is more exact than mine, that is more or less true because to me it looks like you're not calculating KM but more or less simulating it, which is fine but not something people usually want to include in their spreadsheets, so if they want a way to calculate the KM benefits, the formula I posted above is probably as exact as it can get - it also matches my WWS observations quite well giving a 77.5% crit chance for my IT/HB when I'm seeing crit rates of 75-80% in game.

About your spreadsheet in general:
It looks very exact and the DPS numbers given are definitely in the right region, however I'm finding it quite hard to check your calculations because you're using so many columns and abbreviations. Another thing I noticed is that it's taking years to calculate one single profile, wouldn't if have been easier to simply write a simulator in Java for example if you're already simulating everything? (This is what I was thinking about to do but I haven't found the time yet)

The reason it's a spreadsheet rather than a separate program is partially because it really is much easier to make and partially because I simply don't know how to write a program that works with such huge masses of data as this. The most major reason, however, is because I don't trust my own calculations and I expect that it would be much easier to find others to help validate them for a spreadsheet than if it required programming knowledge. I know that my eyes glaze over whenever I see Python code, even if I could recognize the math behind it, just because it's not a C or basic like syntax. Spreadsheets are more universal... to an extent.

It takes me just about a minute or two to calculate a profile, though, so either there is a huge PC discrepancy or you're exaggerating a bit... it would help me to know which. Now, calculating the talent values does take an hour or three, but that's not something you need to really look at for every gear change. I'm pretty sure I accidentally broke it in R3 anyhow so it doesn't even work in the version you have.

Also, you can use logic to figure out when you need to recalculate; anything that modifies the rotation (haste or adding/removing strike talents or changing weapon speed or procs) requires a recalc, but most stat changes don't.

As I'm using many haste items, I'll have to recalculate after nearly every gear change.
To be honest, I don't even know how long the recalculation took. After a few minutes it was still calculating so I switched to my browser and looked back into the spreadsheet half an hour later.

I've just measured the recalculation time, it's been just over 4 minutes now which is probably quite fine, I'll look into the spreadsheet some more tomorrow.

About it being a spreadsheet:
It's probably a personal preference but I find it much easier to develop a program and spot errors in a program than working with such a complex spreadsheet, assuming the program is well arranged.

No, I'd noticed rather large claw numbers as well. Turns out after looking closer on Wowhead, it appears Claw is not normalized. With the ghoul's extremely high attack power relative to weapon damage and fast base weapon speed this cuts its damage estimate in about half.

Best way to add an item is to copy the lower 'None' row then insert a row above it and paste it in, then add stats. You shouldn't particularly break anything by editing it though.

I've fixed many bugs and made many changes since the released version. I'm just going to add a bunch of gear options then I'll post r4.

The high value of haste is due to the gargoyle's haste contribution, which is pretty lacking in supporting test data one way or another. Change D81 under Rotation to 0 for a more traditional number where the gargoyle doesn't inherit haste.

Post r4!
Your sheet could be interesting. It's a bit confusing, but maybe I have some improvements for you.

Kuro, would you mind adding Berserking as a selectable off-hand enchant? As Mages may now go back to deep Fire/Arcane this may be an option over Razorice/Cinderglacier.

Where can we get it? The link in post #2 doesn't work.

Fixed. The update notes post (2 above this one) has a working URL.

Copied from the DW thread:

I was going to wait until I added in a solid gear database, but it seems we've reached critical mass on conflicting napkin math and wild speculation. I have no choice but to release some harder numbers. Hopefully Grigori or someone can provide some optimal post-patch rotations so that our numbers are as accurate as can be.

I'll run some of the more recent questions and edit in/post the results next, but I think it'll be most efficient to get the tool out there ASAP.

Caveats:
**Be sure to check 'Parameters' for a few variables that swing the calculation one way or another between the two popular specs:

Desecration uptime (this just represents the amount of time standing in it vs. not assuming it's up 100%; entering 50% will result in 25% uptime if your rotation keeps it up 50%)

Bone shield and UA uptime also self-explanatory. Target snared is for Glyph of Blood Strike, activate this (up to 100, not up to 1) if you expect to have FFB mages postpatch and want to estimate based on the claim that the FFB dot activates said glyph.

Ghoul uptime given x points in NotD - this is multiplied by 2/5 if you don't take MoG, which might not be the most realistic way to model things...

Merciless uptime might be a bit low on the estimate but shouldn't change much one way or the other.

**Additionally, check 'Buffs' to ensure that the proper buffs are selected regarding Crypt Fever and Ebon Plague. Particularly, make sure to include 3 CF if you're not the EP bitch and want to estimate stacking as it is on PTR.

**Rotationwise, the options are rather a mess. I'm pretty sure I cleaned out all the impossible rotations, but I wouldn't assume the optimal rotation for whatever spec is included or anything.

**I haven't fully tested the options regarding the optimization code for accuracy or workingness. All I know is that the numbers the estimate spits out don't raise too many red flags (provided the ones listed DO NOT USE are not used) and that in theory the non-estimate should be both more accurate and hellishly slow to calculate.

--

Additional non-DW related caveats:

DRW is a rough estimate and probably completely off in the outlier case of a 51 blood dual wielder.

If you add your own 2H weapon make sure to set its special property to Two-Hand in column T.

The unholy 2H rotation - for glyphed scourge strike, use 5xSS but replace an SS with PS/IT if diseases fall off - is in early stages/rough estimate.

Sudden Doom is completely untested but should work.

There is currently no way for 2H frost to estimate using HB when KM procs instead of OB.

--

Edit: A couple quick bugfixes:

Set Spec.Q47 to 1 and set Spec.D27 to OK.

I'm not sure how that's superior to the current method of handling the belt buckle (manually adding it to each belt as a "Any" socket) given that there is no other belt enchant in game with a relevant effect. The concern I had with that method is that I'd have to add rows or columns to deal with enchantment sockets, and I'm trying to keep the Profiles page nice and clean and easy to use. I suppose I could just replace the fourth socket column, though, since no item that I know of has four (at least one belt I can think of has three, plus a buckle is why I included four).

You should also be able to add a "BS" socket to all bracers and gloves (I will do this when I implement professions fully) which currently acts identically to the "Any" socket but will later throw an error if Blacksmithing is not selected as a profession.

Do blacksmith sockets stack with enchants? Never even considered the matter. If they don't I'll have to add the socket in as a statless enchant and throw a socket error of a BS socket is used without the enchant present. No big deal.

My current project is an automatic gear optimizer (pretty basic, it'll just use strength gems in all sockets) and it's making my head hurt. I can easily optimize the gear around hitting the proper hit rating cap, but then I may be well over or under for expertise; then after optimizing for expertise it will probably botch the hit. I don't think multiple iterations would do anything except juggle back and forth. Maybe I could just prioritize expertise second and refuse to remove/add any hit along with it? That might work for dual wield but expertise isn't far behind hit for 2H builds, which should be more problematic anyway due to the lower hitcap.