Yes you are right. I overlooked the option to upload a patch to the project. Ziffs changes are looking much more accurate to me. So i only create patches for the Mjolnir Runestone and the 'FLURRY_SYNCED' option.

As i wrote before: I took only a superficial look at the simulator. So there is no guarantee that the 'FLURRY_SYNCED' change is correct.

Compiled Ziff's update off of Alandovos work but was unable to patch up his GUI changes so it is currently listed as an Alpha but is available for download and testing.

Once Alandovos compiles a new release with his GUI changes it will be changed to release status but all the EnhSim changes are in place and from my testing it is working well enough for people to start using it.

Still missing the Flurry updates so if you are using matched weapon speeds make sure to set your offhand speed up or down by .01 hopefully those can be tested and incorporated into the release patch along with the GUI updates.

EnhSim - Release: 1.8.4 Alpha

Rouncer and I must work on the exact same schedule. I've bumped the version number to 1.8.4.1 and package up the GUI changes and incorporated the Mjolnir Runestone fix.

Again the flurry updates aren't in there because I didn't have enough time to check it out. Someone on the team will get to that very soon.

EnhSim - Release: 1.8.4.1 Beta

I noticed that the total damage output of ES and FS is the same regardless of T9 4Pc. The DPS output at the bottom changes as expected (25%) but the total damage output at the top is the same.

Other than that, most of the changes seem to be working from what I can tell and FS seems to be coming out better than I had hoped.

Not sure if this is a problem with my machine or with the code however attempting to use anymore than 1 thread results in using only 1 thread! I've been using Taskman and the Threads column to monitor this.
I did a quick search of the 104 pages of posts and didn't see anyone else comment on this as I glanced over everything.

Never mind, please delete this post.

Something that I have wondered about Enhsim:

When l look at my profile in the Armory, my Spellpower is increased by the buff from Flametongue Weapon in my off-hand. But when I try to paste from Rawr, the buff is not added in. Does Enhsim add in the Spellpower buff when you select Flametongue for your off-hand, or do you need to add the additional spellpower yourself?

Enhsim adds the buff, so you should not include it with your stats when you set up your config. This is one reason why it's better to use rawr to export an enhsim config rather than pull stats from your paperdoll in game.

(And especially avoid using stats from the paperdoll on the armory. Quite often the armory has wrong stats for some pieces of gear. Some items get updated late in a PTR phase in the actual game files, but not in the armory database.)

My recollection is that multithreading has not worked since Tukez went AWOL. When Verges updated Tukez's last version and created v1.7.0.3, he was not able to get multithreading to work. There also is a patch note with v1.8.0 noting that multithreading is not supported. I haven't heard anything further on the issue, so I assume that multithreading still is not supported.

I did some simming with the Fetish of Volatile Power (heroic) and Mirror of Truth, and the DPS difference is about 5 in favour of the Fetish, but since the enhsim priority doesn't seem to allow for adding Wind Shear into the rotation, I'm wondering if that's actually a bit lower than it should be? My rough calculations make me believe it should be closer to 15-20, seeing as Wind Shear helps build up the stacks almost twice as fast.

Has anyone tested these in a more live-fire environment? The Fetish is definitely harder to use properly, since it's on-demand, and you have to be sure to be pushing wind shear as well as everything else, but considering the amount of on-demand burst the current content seems to require, I'm thinking it's probably better.

I was also wondering if there was some way to add Wind Shear into the priority just for this.

I've taken this from the BiS thread as it is a more appropriate conversation for this thread.

If the sim truly requires a fixed combat time of 10 minutes at 5000/10000 hours to achieve the best results, then we seriously need to take a good hard look at just what constitutes an accurate simulated test. If what you said is true, then this is right along the lines of same speed weapons with Flurry bug. The simulator should be modified to provide random combat intervals - say +- 90 seconds for each 10 minute fight and then run for 10000 hours. It may still not be perfect, but it would be a lot more realistic than using a quirky coincidental set of numbers to achieve the BiS setup/dps values.

Three factors make fixed time combat rounds a bad thing: GW, BL and trinkets. Ok, and profession/race CDs so four things. (And I'm sure others will list new and exciting things I didn't think of). Anyway, they are all on 1*X minute timers and some combat intervals can be greatly manipulated by said cooldowns. I always found the 10 minute combat length thing a bit odd as it diminishes Bloodlust and favors GW and trinkets(and profs/race). Very few fights are 10 minutes long and as such, simming 10 minute fights does not represent live fights. A ten minute fight does not produce greater accuracy in DPS or EP if you're calculating that. The sim has a configurable time it's supposed to simulate and decreasing combat length will only produce more simulated fights, with the added bonus of being closer to live fights.

Back to my original point; Instead of having more random inserted into EnhSim, how about fixed combat segment intervals?

combat_min_length = 4 // in minutes
combat_max_length = 10
combat_stepping = 1 // perhaps do it in seconds instead?

So the first simulated fight will be 4 minutes, second 5, etc and then a ten minute fight. After that EnhSim will reset it's internal combat stepping counter and start at 4 minutes again. Why do this? Well, we have a simulator that has a lot of random factors. While live has random combat length it's not necessarily a good thing for the simulator to incorporate all things random in the game. As shown, some deviation is good because it negates false plateaus due to EnhSim's strict nature. However, as many deterministic (here loosely used as we can easily and precisely calculate each and every combat lengths just by looking at the config) factors as possible will make less "flukes" in EnhSim results.

I uploaded a patch which includes a new option for config file:
This will add or substract up to 10% (in this case) of the combat length.

New EnhSim available from the site: EnhSim - Release: 1.8.5.0 Beta

Big thanks to Peterle for the patches.

As always please use the EnhSim site for reporting issues.

I've uploaded a new release of EnhSim. Changelog is as follows...

Various fixes
Updated config.txt file with various new values - eg: no longer uses lvl 70 potion by default
Armour debuffs now warn if outside acceptable range. Boss armour now warns if users using old config file value of 10645 instead of 10643.
Added warnings about using low level potions/flasks
New racial flag wasn't being initialised for Draenei causing odd crashes for Alliance Shaman
Various efficiency improvements with combat log settings
Fixed bug with Feral Spirits AP, they get AP from 2 times their strength not their str + agi.

I believe that the sim was calculating this properly. The agility-related variables were just there to future-proof the code in case wolves at some point began scaling off of Agi instead of Str, but their presence did not alter the calculation.

The original code in question was as follows:

attack_power_base_ + sim.ap_ * attack_power_scaling_ + strength_ * strength_to_ap_ + agility_ * agility_to_ap_

But agility_to_ap_ was set to 0, so no AP was added. But if Blizzard made a future change to allow Agi-based scaling, all that had to be done to implement it would be to change the constant from 0 to another number.

So that was a long way of saying that I don't believe that change should throw off the values that people were simming previously.

Some trinkets are implemented in the simulator itself but not listed in the GUI drop-down menu. You can include these in various ways. You can manually edit them into a config file, or if you select the trinket in question in rawr and export a config file it will automatically include them. If you want to use a trinket that you don't find in the drop-down, and want to select it from within the GUI, you can type its item number. For reference, the Darkmoon card you're looking for is item number 44253.

Ah bugger. You're right - reverting change and immediately releasing fix as v1.8.5.2

Yah I realized this after posting -- but still, when the gui was updated and the trinkets were alphabetized and added into the drop down, it made me feel like it should just be added for "completeness' sake" :P

Thanks though

Apologies if this is the wrong place to ask, but how would one go about manually adding a new trinket to the sim? Specifically my shaman is currently using a mirror of truth, and EnhSim crashes every time I attempt to copy her into the sim because the trinket isn't in the list.

Mirror of Truth is in the Sim, you are crashing for some other reason. Make sure that the GUI is pointing at the proper exe file since that seems to be the most common cause for crashes.

Actually Mirror of Truth isn't available as an option in the enhsim GUI drop-down menu in the most recent build. You have to type it in, and it doesn't work to type in the name, you have to type in the number. If you search for the item on any common database web site, you can find out the in game item number. Enter that number as the name of your trinket. In this case, Mirror of Truth is item number 40684, which you can see in the url when you search for the item at any of these sites:

[Mirror of Truth]
The World of Warcraft Armory
Mirror of Truth - Items - Sigrie

But really, you should be using rawr to create your enhsim config files anyway, and rawr does this automatically. It's faster, easier to do without making mistakes, and as long as your item database is up to date within rawr, it's more accurate. (Some items have different stats in game than their stats on the armory, especially socket bonuses.)