Not to stray terribly off topic but about your OH slot; I ran into a similar problem several weeks ago when I got the 245 ilevel axe from 25 Anub'arak. I figured it should've been an upgrade over my Caress of Insanity but it didn't sim as being an upgrade. Since the FT coefficient scales up with weapon speed the 2.7 speed Caress will beat any 2.6 speed weapons but 258 ilevel weapons (nothing conclusive on Raging Deathbringer yet though). I don't play an orc however though I would surmise that the 245 axes would probably be a DPS upgrade in your OH if you needed the expertise.

Brynmor, you are wrong about Caress. Even for non-orcs, the ilevel 245 axe from HAnub-10 is the superior weapon. Most likely your misinformation is because you are not changing your offhand speed to account for the bug with matched weapons and Flurry charges in the sim.

Change your offhand to 2.71 and rerun your sims and you will see the axe show up as a better option.

Running your profile through EnhSim I get 8235.94 when the speed is kept matching. This drops to 8199.77 when you unmatch the offhand speed to 2.71 Loading up the Axe and sticking a 20 expertise gem in it (slightly under the expertise cap but more relevant without regemming things) EnhSim shows 8220.59dps.

Until the sim gets fixed always make sure to unmatch your weapon speeds.

I think Brynmor is referring to [Hellscream Slicer].

minchar

It is available in change 26691 or later see EnhSim - Source Code for the source code. You will need to compile this source code for it to work. If you don't know how to do that then please wait for the release. I and the other developers will NOT be compiling versions for you sorry.

This is EXACTLY a description of someone completely and utterly screwing up and using EP values in the worst possible way. DO NOT multiply EP values together on stats of an item to compare them EP is too variable these days to make that a sensible strategy.

Instead sim start and end states and see how much DPS you gain or lose not how much EP you gain or lose. Using EP values correctly means using them as a guide as to which direction to go in. This is where I think graphs will be better as they could be easier to understand.

I'm not in favour of abandoning the concept of a feature that shows us what direction to go in. I am in favour of abandoning the way EP values are treated at present as the current variability of them means that far too many people fall into the trap of the poster above.

Rawr and enhsim combine together to do some things very well. "What is our BiS gear talent and priority combination" is a good example of an interesting, meaningful, approachable, and non-trivial problem that the rawr + sim combination is helpful for, and we have a whole thread full of posts approaching the best answer to that question. An even more ideal scenario: I have (or hope to have) two items in my possession, and want to find out which one will provide me with more potential dps.

In theory, every time a potential upgrade drops, I should compare it with my current gear in this fashion. If it ends up not being an upgrade, or if I can see that it will be more beneficial to a hunter or rogue, I pass on it. However there are several pieces of gear for each item slot in any given tier. The combinatorics on this set end up being too big for me to test every possible drop with enhsim. Rawr's genetic algorithm optimizer is great, but its formulae don't have the depth of simulation. The ideal scenario of just grabbing every item on the BiS list is out of the question for me, since my main spec is resto; by guild policy and personal unselfishness I get leftovers that other people don't need.

So, fully aware of the limitations and weaknesses of EP values in the current game, I deliberately use them anyway, in the exact manner you deplore. I'm not going to wait for 9 or 24 other people wait for me to weigh in on loot when we can otherwise spend that time. After I win an item I then of course go through a more rigorous examination with the available tools. Maybe an item isn't an upgrade after all, then I give an Abyssal Crystal to the group. It would have been disenchanted anyway if I didn't want it.

EP isn't the best way to compare gear. No one will argue that. It is, however, a convenient quick and dirty guesstimator. It's fast, and it's usually pretty close.

bestpike - sounds like you just described the optimizer in rawr. you select (the green diamonds next to gear name) the gear items and run optimizer to select the best item, enchant, and gemming based on its formulae. As Levva as said before, it will go thru all the selections, running them thru the formulae and select the best end result. Also, run that new selection thru the sim to confirm the results. always always always sim to confirm.

side note, EP does change per item change. As it is calculated for the total set as it currently is. Changing one item, changes the result of the EP calculation. For most reliable EP reults, however reliable EP is, it would need to be calculated after each item/enchant/gem change. I personally stay away from EP. And if need be, I will run a quick sim between pulls to see an item drop from a boss is worthwhile.

For haste, yes sadly they are changing that fast. It has yet to be determined if this is an artefact of using a computer doing perfect priority skills and thus hitting an exact sweet spot for haste which means suddenly 22.2% haste is miles better (EP 2.8+) than haste of 22.1% (EP 1.6).

There are numerous possible fixes for the issue that can be investigated and its not an issue if your gear build doesn't include much haste. However since a large percentage of Enh Shaman as going haste as main stat then it makes sense to warn these people in particular that they MAY be deluding themselves using EP values multiplying them up.

Your suggestion that we need a program where you select each item you have available and all the different gems and enchant and then get the program to work out what combination is the best is EXACTLY what the Rawr Optimiser does. This is why I spend so much time trying to improve its calculations as the optimiser is a fantastic tool that takes a massive amount of work out of trying to decide how to regem to hit caps, up dps etc.

@Jessamy

Perhaps I'm just too organised but I know in advance of a raid which items I could use as an upgrade off which bosses, and encourage all guild members to do the same. If you were in my guild and didn't have a clue if something was an upgrade you'd be told to go get a clue before the next raid or risk losing a spot to someone who came prepared.

The boss loot tables are seriously not that large that its in any way difficult to know which pieces are an upgrade for you. Waiting until an item drops and only then bothering to think about it is slowing down the raid.

I can however fully appreciate that for an offspec this is perhaps above and beyond the call of duty and so can forgive you on that count

EP values are just the partial differentials of the DPS function in [ap, crit, hit, haste, expertise...etc] space, and "normalized" so that the value of AP is 1. This said, given that the appropriate soft caps are reached, only haste has any complex (higher than ~2nd order) interactions with the DPS function over the ranges that we care about - it wouldn't be terribly difficult to reduce the current "EP system" to a less simulator-dependent "Haste-EP system", where we divide the DPS function and its EP values into groups based upon haste rating, splitting around the windfury interaction areas (which are the root cause of the "haste problem").

Within each group of haste %'s, the EP values would be (very) simple functions - AP would be flat, crit would be (approximately) flat or an exponential function given by flurry and E.D., hit would be linearly dependent on haste %, haste would be approximately linear, etc. With the implementation of such a system, it would be possible to move away from EnhSim for all but the most demanding applications, to a spreadsheet-based system, one that most people are capable of understanding and utilizing, and one that is drastically simpler to use. EnhSim would only be needed when moving across haste groups (from one to another) - however since most of our gear doesn't even contain haste, we could do away with the need to sim every time we acquire a new piece. This would be simple enough that it could merit the return of EP values to the TTT, grouped based upon haste ranges and MH weapon speed, with the caveat that using a trinket with a haste proc (Elemental Focus Stone, etc) will distort these EP values.

edit: also note that (given the differential nature of EP values), the value of current haste is at a max/min when the EP value is lowest.

Wow I didn't know Rawr was so sophisticated. I didn't give it too much time to work with. I will check it out. Thanks for your hard work Levva

I have, with some help from the codeplex enhsim site, compiled a current Mac version of EnhSim. It's a Unix binary but works just like it always has on the Mac.

EnhSim Mac Binary

At the risk of sounding like a complete newb, what am I supposed to do with this file? Is there a place I'm supposed to put it in my iEnhsim folder? Or do I need a separate program to run it?

It might not be completely clear unless you've used previously released versions. This is the mac binary file, not a GUI app and must be run in Terminal.app in much the same way Windows users will run enhsim.exe.

The first thing you need to do is rename it if your browser downloaded it as a generic file. (just call it enhsim)
Secondly, as with many binaries, you need to make it executable. In the terminal locate the file and enter:

I'd recommend moving it to an existing enhsim folder that contains the windows files, that will give you a default config file.
After exporting from ShockAndAwe and pasting in another file, you can run something like:

You should expect a similar experience to enhsim.exe from the command-line and I've verified this is true with 10.6.1.

Not sure who is approving patches on EnhSim right now, but I added a patch to fix the changes to Flame Shock and Armor Pen for 3.2.2. I uploaded the patch to CodePlex so if one of the coordinators could look it over, it would be nice to get EnhSim updated for 3.2.2.

How does the sim work with "use" trinkets? I saw the option for syncing it with heroism, but if that's not chosen does it just pop them whenever they're off cooldown?

Sadly that isn't true. Hit rating also has a very significant effect above the spell hit cap. As additional hits generate more MW procs which means you can get an extra LB in before another skill (eg: LL). This then puts that second skill delayed for another GCD. By which time a third higher priority skill (eg SS) might be available further delaying the "second" skill (LL). This delaying effect then ripples through the combat sequence of skills used and can significantly change the balance in numbers of casts between abilities - LB & LL usage numbers are often significantly changed for instance.

This means that the numbers of LBs cast during a combat cycle of the sim will vary due to RNG but also due to additional hit adding a greater frequency in there. This can push more LBs at the expense of other abilities (notably LL & MT). This CAN mean that marginal variations in hit rating (above the spell hit cap) can change the number of abilities used and hence the dps results.

In EP terms this can seriously distort hit rating above the spell hit cap, adding additional hit rating does definitely give a dps boost, however it feels "stepped" ie: small amounts of hit make little difference then there is a jump to a new plateau. This is my gut feeling as to how it will come out. I'm still working on adding a graphing function to Rawr which will show steps of each stat +/- 5 steps of 1 epic gem's worth of stat either side of your current gear. eg: +/- 200 AP, +/- 100 haste, +/- 100 crit etc. The output will be presented as a graph of each stat change vs dps.

Here is a new EnhSim executable with some small fixes: REMOVED I create a patch for some of the changes.

Things i try to fix:

* Change the proc of the Mjolnir Runestone from 612 ArP to 665 ArP.
* Change the value of 'SPELL_HASTE_RATING_TO_HASTE' to the value of 'MELEE_HASTE_RATING_TO_HASTE' (0.00039646246f). At the armory it seems that both have the same ratio but i did not test it in game.
* Change the value of 'ARMOR_PENETRATION_RATING_TO_ARMOR_PENETRATION' from 0.0008119361f down to 0.0007142857f. I just calculate the value using my ArP rating and percentage. If someone knows the exact value i will replace it.
* Flame shock gives six dot ticks. The coefficient for the dot was not changed if i remember correctly.
* Flurry now gives three charges even with same weapon speed.

Some words about the flurry fix: There is already a define for these change ('FLURRY_SYNCED'). But the code which was commented out by these option did not work anymore. So i only fix these two lines. But i do not have the time to take a closer at the simulator so i'm not sure if i did it the right way. With different weapon speed i get the same results and with same weapon speed flurry uptime ist not higher anymore. So it seems that the sim works correctly.

We get 30% more melee haste then spell haste since the 3.1 patch (armory is wrong - check your in-game paperdoll if you want to check your values). Hopefully someone can incorporate your other fixes into a build that treats haste rating properly.

Levva should be able to include you into the codeplex project if you are interested in helping us out in the future. (Ziff should have been contacted about this already, for the curious)

So as of now, are we better off using the default EnhSim on CodePlex, or this new one? Which would be more accurate?

I think Ziff's uploaded source code patch attempted to fix a few more issues than Paterle's uploaded executable even though Ziff didn't say much in his post. These are the full notes that Ziff posted with his patch on the codeplex site:
There were a number of problems with calculating the damage for FS dots in the prior version (e.g. T9 bonus was not being applied) that Ziff attempted to address and he even marked off the issues in the issue tracker.

Default one since having 30% less melee haste then occurs in game is likely to lead to some significant inaccuracies. Hopefully one of the other coordinators who actually knows what they are doing will have a chance soon to review the changes in Ziffs XML update to the source code and then compile it into a new executable for download and proper testing.

Can I ask anyone that has coding experience and wants to contribute to the project to contact a project co-ordinator - Myself or Rouncer and we can add you as a contributor.

PLEASE don't issue your own mini versions with adhoc changes as that just leads to confusion with multiple different versions at all different stages of development. The whole point of creating a codeplex project was so that multiple developers could assist and we would have a unified code repository and avoid the diverse versions issue.