Try to remove the Wait time for the Signature shots in the shot priority. If it works as I suspect, having more haste means shorter casts=more room to squeeze another shot (having more total shots) within the "Wait time" window. Thus you can end delaying KC (up to 0.3sec as default) more times and finally losing that one KC

Not true. Haste does affect two things primarily that affect your shot selection:
1) CoS cast time - 1000 haste is significant change at 2.38% - from your initial haste amount, it decreases your SS cast when under no dynamic haste effects by about 0.03s from 1.445s to 1.414s.
2) Increase your focus regen rate by about 0.1 FPS from 4.378 to 4.473. ).1 FPS may not seem like much, but over a 6 min fight at the base regen rate that equates to 36 focus, which is almost enough for 2 extra ASs. The actual amount of extra focus is a little higher due to the multipliers when dynamic haste effects are present.

The net result of these effects is that under some dynamic haste conditions, you may now have room on several occasions to perform an extra AS and delay the next KC a bit due to the deadtime before KC comes of CD and the additional focus gained.

This is indeed what happened in this case. Although you perform 1 less KC, you perform 3 more ASs, 4 more autoshots, and 1 more Stormlash. Despite the loss of a KC, this is almost 1200 DPS better. This changed shot selection only cost 20 more focus, which is less than what was generated by the extra haste. The haste increased DPS since you were able to squeeze in a net of 2 more instants (although 1 less KC) and 4 more autos. Both hunter DPS (762) and pet DPS (416) improved. The hunter DPS increased due to more shots performed. The pet DPS increased due to 7 more melees, the extra Stormlash, and an increase of 3.67% in WH uptime due to the extra focus regen from the haste and the GftT procs from the 4 extra autoshots.

The phenenom in true for any of the hunter spec primary CDs (KC, CS, ES). While there is a delay in the primary CS usage, more haste will reduce the delay and possibly allow an additional primary CD in during the fight. If you keep adding haste, you will come to situations where you can add in an extra focus dump, which then delays some of the primary CDs and reduces the number of them. Add yet more haste and the rotation in thos instances will tighten up and get back to the max number of primary CD usages. With how our haste levels are not constant throughout a fight. where haste may be tightening up the primary CD cycle on some cycles it may be increasing the deadtime on others making room for another focus dump if sufficient focus allows. Anyway, the sim should switch back and forth between the maximum number of primary CDs and 1 (maybe more depending on fight length) less as haste levels change.

Sure, there can be *some* slight variations in the number of abilities because you push others off (though really you shouldn't, and instead hold off on the CoS, and other abilities should be aligned right after the use of a 6s CD and possibly delayed instead.

It sounds like FD just does one sample iteration, using averages for trinkets and talent procs? If so, that would explain why an integer number of KCs are used even though one would be only very slightly delayed.

I think there are options to address that though -- run the sim, say, 10 seconds longer. Taper off the damage from those 10 seconds based on how far they are from the specified fight end (so a KC right at the 361 second would basically be 0.9 extra KCs, while one at 362 would be .8 extra KCs and another one at 0.2 at 388). This should stabilize the effect of haste and more accurately represent numbers people can use (since their fights don't have hard ends like that, either). Or you could pro-rate just the remaining CD on short CD abilities. There are a few options here that I think will give more accurate haste results without requiring a massive rework of the engine.

Fights do have hard ends. When the boss dies all damage stops and you do not get credit for the KC or any other ability that you were about to do in a couple seconds. You also do not get any credit for the remainder of any DoTs that are still on the boss. FD models how fights actually end quite well.

Running the sim 10s longer would not gain anything. You would still have the same problems after an additional 10s as you have at the current end time. Adding benefits for attacks that did not occur is very misleading and does not represent actual game play. If you want to stabilize the effects of haste and am worried about the impacts of shots being chopped off at the end, then you just do a very long sim where the damage from the chopped off shots are a very small fraction of the overall damage done. However, doing so makes the sim less realistic for the duration of standard boss fights encountered.

Plus, if you think that it is always best to use a primary CD like KC immediately after CD and to not ever delay it to squeeze in another ability to take advantage of excessive deadtime before the next primary CD, you are very wrong as the data in my previous post clearly indicates.

It is true that FD is a simplication of a fight. Every sim is to some degree or another. Although FD does average procs for stats like agi, crit, and mastery over the full duration of the fight which makes analyzing burst DPS a little more difficult unless you do a test for just the burst duration with having the items you want active enabled during the test. As is true with using any simulation, you need to understand its strengths and weakness and how to best use it to get the most useful information out of them.

However, in FD, haste is the exception. FD does not average out haste over the fight. Zeherah has gone to great efforts to accurately model the effects of both static and dynamic haste in her simulation. I believe that the only place that haste may be averaged out over the course of the fight is in determining the number of autoshots. Any dynamic haste effect has an immediate impact on SS and AI cast times and focus regen. If you look through the shot simulation, you will see how the rotations automatically adjust to the dynamic haste affects per the rules provided, which simulate actual game play pretty well. It is true that with a fixed duration of time in the simulation that haste effects will cause some shot shifting, but it still providse a relatively accurate representation of what benefit you will receive from haste. As with anything in a sim, it helps to understand why the results came out as they do to draw better conclusions.

Note that in most cases, procs of agi, crit, and mastery will not affect too much your shot selection. You still will normally perform that same shots as without the procs but with the procs you do more DPS. Haste is a different beast. Haste procs affect your shot timing, which is why Zeherah implemented haste effects into her shot simulation.

Although there are plenty of improvements I would love to see to her tool, giving partial credit for shots is not one of them. On this item, we will just have to agree to disagree.

What I would not mind seeing is in addition to doing the simulation over a set period of time would be also being able to specifify a damage amount and seeing how long it takes to perform that damage amount. Obviously, a shorter sim duration equals higher DPS. Regardless of whether the sim is the current way or this way, the fight will normally end somewhere in the middle of the primary CD rotation and not exactly on a boundary, which is real game play situation.

Also note that the hard end in FD is just as valid as the hard end in a real life fight. If you want as genuine a simulation as possible to base your choices on, you should simply do some mental math first, and find the common denominators for the critical abilities and make sure the simulation ends 1 second before they all become available again.

For example, if you want to look at the impact on dps in the BM 6-second cycle, turn off every CD except BW and set the fight duration to something that ends at X:59 - I would suggest something along the lines of 7:59 to have a sufficiently long simulation period to "remove" the "starting from full focus" bias that is most clear in the first minute.

On the previous page Zeherah you said you weren't totally sure about the implementation of the t15 set bonuses. I picked up the 4 piece set bonus tonight so I did some testing. Nothing particularly interesting came up, but in addition to what ghostcrawler said back in January (3 RPPM, buffed by survival mastery) I found the "lightning arrow", which looks like a white streak pretty similar to multishot, is able to crit, and when it procs on multishot it seems to only go to 1 target. After 100 procs from spamming multishot at the group of 3 target dummies in Stormwind I never saw it hit more than 1 from the same multishot. It also didn't prefer any of the 3 targets when it did proc, it was able to hit any of them.

If there's anything specific you'd like me to test just let me know.

It looks like FD has an issue modeling RPPM with Rune of Re-Origination

Using the current BM max DPS profile (HC+TF) it shows:
If I get it right, it says the trinket will proc roughly every 23s (~43% uptime). Not sure about this though as lower haste rating doesn't seem to change that value.

If I replace Rune by Talisman of Bloodlust it states [cd] 964.78540749513 with 21s uptime. In the Simulation Shot Breakdown it effectively makes it proc at start for 21s (assuming 2 or more stacks?) and it never procs again for the rest of the simulation.

Making my own (simplified) math for Rune:
Base RPPM: 0.92
iCD: 22s
March 12th hotfix: +10% chance to proc
ilevel scaling: 1/(1.15^((528-ilevel)/15))
ilevel of HC/TF: 541
Haste: 9158 (22.40%)

0.92 * 1.1 * 1/(1.15^((528-541)/15)) * 1.2240 = ~1.4 RPPM ~= 1 proc every 43s ~= 23% uptime.

Trinket procing haste can't increase RPPM as it lasts 10s with a 22s icd.
10% attack speed buff doesn't increase RPPM so I assume RF/FF don't either?
Bloodlust increase RPPM but that's only a small portion of the simulation.

Importing the gear from FD into simulationCraft also returns something closer to my maths. I vaguely asked Lokrick to check it out and his answer was close to mine.

Thanks for the details NoGoal. Lokrick mentioned the issue to me but he didn't have enough details for me at the time and I haven't had time to look at it yet. There are some coding issues with my Rune implementation that are on my list to fix (haste trinkets use a different mechanic for calculating than the others and my RPPM changes didn't fully clean them up) although I'm not sure if I will have time before the weekend (I used up my free time this weekend on Talisman support)

For Talisman of Bloodlust, I just made changes yesterday to better suport it. I've run simulationcraft with the normal mode version at various haste levels for each spec and established a rough uptime and average stacks pattern which I'm using as the basis for my implementation. Presumably the different ilevel versions will have a similar pattern but with different base numbers- I still have to do more investigation to support them better, for now all ilevels are using the proc pattern from the 522 version. I have it setup to use a 21 second duration because the average stacks when up were around 2.1 in the sim and that seemed like a reasonable basis for implementation. I don't know what happened with the CD though- when I tested it, it was working for me but there must be a bug in the implementation. I don't have time to fix it now but I'll try to get to it tonight since that's probably easily fixed.

If you're curious about the talisman uptime data I simmed out, I have it in a spreadsheet you can see here:
https://docs.google.com/spreadsheet/...2c&output=html

RF and FF are haste btw and do increase RPPM. 10% attack speed buff and MM's attack speed buff do not.

Hi Rivkah,

When you get a chance, could you also add the Thunderforged Abandoned Spaulders of Arrowflight to the shoulders listing? I've also noticed an issue with importing Armory profiles. If you start looking at a profile that includes Enchanting, and then do an Armory Import of a character that doesn't have Enchanting, it will keep the enchants on the rings after the import, even though the professions no longer support that. I believe Blacksmithing and Leatherworking also works the same way (in trying to apply an enchant that is no longer applicable after an import). If you have time, would you mind changing the behavior to reset everything in the gear profile to only what is on the gear after an Armory Import? Thanks!

Slightly off-topic but, would you recommend the action priority list that SimC provides? It occasionally will change depending on gear/stats obviously which seems to me like the best priority list if one can adapt. Thoughts?