Your combat log parse translation shows 4 swings between flurries and an entire second between a crit and flurry up. I never really trusted combat log. Do you use matching speed weps?

No, I used [Golden Dragonstrike Breastplate] and [Vanir's Left Fist of Brutality]. I tried to be careful and make sure there was >1.5 seconds before and after the events of interest.

At any rate, I think the log clearly shows that misses consume flurry charges, which was all I wanted to prove. If they did not consume charges, flurry would have stayed up until another hit, which didn't occur till 1.5 seconds later. Lag shenanigans don't change that logic.

Edit: I guess I actually do have a log of a dodge eating flurry. To make sure lag's less of an issue, it's with the nice slow [Halberd of Smiting] (with Fiery Weapon enchant, hah):

56.703: crit (flurry was up before I started logging)
59.515: hit
02.390: hit
05.109: dodge
06.234: flurry down
08.437: glancing hit

The SPELL_AURA_REMOVED event occurs pretty consistently 0.9-1.2 seconds after the last charge is consumed.

So if proc'ing Flurry on one hand will speed up the other hand in mid-swing..... What happens when Flurry drops mid-swing? Does the swing in progress slow down?

Rezarel, looking at your "dodge log" it seems that the Glancing Hit came too fast. The weapon speed is listed at 3.5sec, yet the time between the Dodge and the Glancing Hit is ~3.3sec.

Did that swing benefit from Flurry from time-05.109 to time-06.234 when it fell off?

Assuming the swing that resulted in a Glancing Hit benefited from the Flurry Aura, it would have been initially scheduled at:
05.109 + 3.5 / ( 1.0 + 0.25 ) = 7.909

If Flurry Aura went down at 06.234, then the swing was 40% complete when Flurry dropped.

06.234 + ( 100% - 40% ) * ( 3.50 Weapon Speed ) = 8.334

This is reasonably close to the 8.437 time in which the Glancing Hit occurred.

If Flurry did not partially affect the Glancing Hit, then it would have occurred at 8.609.

IT IS HARD TO TELL FOR SURE DUE TO LAG BUT IT iS POSSIBLE THAT REZ GOT THREE-AND-A-HALF SWINGS WORTH OF FLURRY GIVEN THAT THERE IS DELAY BETWEEN CONSUMING THE LAST CHARGE AND THE REMOVAL OF THE BUFF.

Given the following lag effects: (should be 2.8)
Time between crit and first hit: 2.812
Time between first hit and second hit: 2.875
Time between second hit and dodge: 2.719
Time between dodge and glancing hit (with flurry going down mid-swing): 3.328

EDIT: Massive edit due to bug in the haste expression and Rez's explanation of lag.

I'd guess that the attacks do occur exactly at 2.8 speed on the server, but the time stamps in the combat log are when my computer received that information. If you average the three hits you get 2.802 seconds per swing. I'd guess the packet telling me about the second swing just got delayed, which is why it looks like the third swing occurred too soon.

Basically, with my lag it'll be hard to see the effects of partially flurried swings. You'd have to find someone closer to their server.

I can make a video swinging a torch of the danmned partially naked (to subtract some expertise and hit rating) on a ~72 mob and post it here. I'll edit it into this post today. Maybe it will be more clear off of visual cues instead of a laggy combat log.

flurrytest.avi - FileFront.com

....and yeah avoided swings definately do eat flurry charges. I better spend some time modding my sheet down then.

Nice..warrior dps simulator, my friend is gonna like this. I am the author of this new enhancement shaman simulator enhsim - Google Code . I can give you some tips how to do this.

Do it event based for sure. I have done that and that is what makes my sim so fast. It runs on my computer(core2duo 7700, 2.4ghz dual core) at ~4000000 times normal speed. So 150000h of simulation takes about 2min 15s to complete. (/w multithreading, 2 threads)

I know, I know, if you look at the code..it's a bit of a mess. I have sacrificed a lot to speed but a big reason is also that I'm not patient enough to design it well. So try to design more! It's very hard though, because there is always something that you forgot to think about.

Event based does not sacrifice precision. What I have done is, that I use 0.01 precision with ints and doubles. I just multiply necessary values with 100 and floor doubles. I use doubles for example to record damages, time variables etc. That is because with long simulations, otherwise you will end up with overflow. By the way, 64 bit int is slower than double.

I think my simulator is quite good when looking at the variance. Thanks goes to SFMT, short of SIMD-oriented Fast Mersenne Twister SIMD-oriented Fast Mersenne Twister (SFMT) . It is Mersenne Twister random number generator. I greatly recommend to use Mersenne Twister with random numbers, because I tried with the default rand and it sucked balls, big time. SFMT is for C++, but I bet you can Mersenne Twister for other languages as well.

Then about flurry. In my sim, haste change during mid-swing does not change the speed. Maybe that is not corrent but I haven't seen any proof otherwise. I have a strong feeling that my sim's model is right. Why? Because I bet my ass that the real WoW is event based and that Blizzard have done it the easy way. It uses less CPU power and that's what they want with MMORPG. Well...who knows, I might be wrong.

My sim is with BC mechanics and I don't think I have too much problems to change it to WotLK. So in my opinion you can start to design it anytime.

Could you just give a link, as I can't seem to be able to find it? I'm very interested in this stuff, because I think it might have a noticeable effect with the sim. Also in my sim, same speed weapons do not stay in sync with flurry...might be wrong?

[Warrior] DPS Spreadsheet 2.3 and beyond I think.
Two weapons of the same speed stay in sync forever, but you have to start attacking when you are in melee range or the offhand starts slightly slower (maybe that's intended?).

I was thinking about the event driven system, which I assume is some sort of linked list. How would you handle the searching, add/delete, and reordering of the event queue possibly more than once for each event? For example if you crit and gain flurry, you have to add an event at the correct time for flurry to fade, possibly delete an old flurry fade time, and adjust the swing time of both weapons plus any procs that happened on the hit.

This is what I have done. I have an eventnode which represents one tick(0.01s). There can be many events in one eventnode. Events are separated in 3 categories: high priority events, low priority events and auto attack swings. If there are all of those events in one tick, high priority events are executed first(cooldowns mostly), then auto attacks and then low priority events(buff fades etc.).

So when I add and event, I first search the eventnode linked list for the right spot and make a new eventnode. Sometimes I don't have to make a new one because there is already an eventnode for that particular tick. Then I add the event to the eventnode and thats it.

About the flurry example. I do not delete the old fade time. I handle it internally in my talent, skill etc. classes with one varialbe which is proc_stack_. It is increased every time there is a fade event added to event queue and decreased every time the fade event is executed. When it reaches 0, I know its time to actually take off the buff. (In my sim, I don't actually model flurry buff time...it is not possible for it to fade in sim with current weapon speeds. It would slower the sim).

About haste in mid-swing...my auto attack events are actually just boolean values in every eventnode. I keep a pointer to next auto attack eventnode, so I can cancel the auto attack if needed and make a new onw.

Then to the proccing system. I have arrays for every possible proc event. For example mh hit, mh crit, oh swing, spell hit, stormstrike. Before the sim, I register the procs to these arrays. When mh hit happens, the mh hit array is went through and the procs are executed.

That was bit about the insides of my sim. Hope it helps someone to design his own.

I have a list, where I put everything in with a timestamp and then sort it. No need for ticks, nodes or roundings. Just handle the next event.

Haste changes aren't that elegant, but they don't happen very often anyways. Search for the autoattack and change the time accordingly.

Sorting is too slow to be done each time you add a new event. A better approach would be to search for the correct insertion point, and place the event there by relinking, if you're using a doubly-linked list, which I think that's what you meant by "list". If you keep track of a few nice reference events in that list - like the last event added, next swing - they become very nice starting points for you search, making the whole event handling thing a set of very fast operations.

For haste changes, since you were already keeping track of the next swing event, you'd simply have to relink it again at the correct position in the list. All of these events should be fairly close together, making this also a very fast and clean operation, with very little searching. All you have to do is, starting at the next swing iterator/pointer, search backwards until you find the place you should be inserted, unlink from current position and relink there.

If you don't want to keep track of these reference points, you can use some simple logic to find the place to start your search for insertion point. For example, if the event will happen in less than 10secs start from the head of the list, otherwise start from the end. So for example, for long cooldowns, it would be fairly obvious that most likely they would be at the tail of the list, instead of at the start where all the "cool" stuff is happening. This will still be much faster than sorting.


Cleaner is just a matter of how well things are encapsulated. You can provide a very clean interface to a very bloated and ugly implementation that nobody has to look at, as long as this interface is clean and well (self)documented. When you're writing time-critical code, you can't rely on it being beautiful and the most efficient at the time. Sometimes you can make a little trade-off, for all the other times, you just have to encapsulate it behind some class that hides all the "dirty" details from the rest of the code in your project.

I have developed my own simulator.
Would you mind to take a try and tell me is it correctly reflecting your fury warrior dps?
My DPS Sims

I found a bug on reducing rage after heroic strike used and fixed.

I have been optimizing my event queue a bit.

My first system I already explained. On that system I did a linear seach from the beginning of the list and I recored how many nodes I had to pass to find the correct place. It was about 11 if I remember right.

I tried a lot of different systems, at least map, heap, binary tree and none were faster than my system. Then I dropped the eventnode idea and placed every event as own node in the list. I also made it double linked list so I could remove nodes easily. This change made it already faster than the old system and avg nodes passed was about 8, starting the search from beginning.

Then I tried to set a constant treshold to decide where to start the search, start or end. It improved the performance too and the avg node passed was just under 6. Then I figured that I could record the last inserted node, start the search from that point, to start or to end. This increased performance a bit too and avg nodes passed decreased to under 4.

I remember you had posted some suggestions to do the event queue and came back to read it again...and Dang! You had suggested everything I tried, which made some improvements. Do you have any other good ideas?

Took the time and made it WotLK compatible/only. Now I can start with the interesting part, the simulation. The addon provides a big need for stuff like this.
I just don't know what to show in the DPS window, besides damage distribution or proc uptimes.
I also wonder if I get any usable feedback here .

Doc's PvE Simulator : WoWInterface Downloads : WotLK Beta
I've uploaded my addon on a fancy wowinterface page. Maybe someone can try it out.

I need to know:
- Common boss armor at 80?
- Glancing works the same?

Edit: Updated
Edit2: Updated again

Assuming they went with the same mitigation values, the common boss armor values should be something like this:

Level 70
* 6200 armor equals 37.00% mitigation
* 7700 armor equals 42.17% mitigation
* 8800 armor equals 45.46% mitigation

Level 80
* 8950 armor equals 37.01% mitigation
* 11100 armor equals 42.15% mitigation
* 12700 armor equals 45.47% mitigation

Wouldn't it be 35% for Lv73/83 bosses?
%Reduction = (Armor / ([467.5 * Enemy_Level] + Armor - 22167.5)) * 100

Edit: Also, updated again. All buffs & stats are now included.

I believe the 'Enemy_Level' variable is the attacker, not the target, as per PaperDollFrame.lua.
Regardless, here's the values for L73/83.

Level 73
* 6200 armor equals 34.14% mitigation
* 7700 armor equals 39.17% mitigation
* 8800 armor equals 42.39% mitigation

Level 83
* 8625 armor equals 34.14% mitigation
* 10710 armor equals 39.17% mitigation
* 12240 armor equals 42.39% mitigation

Still doesn't seem to be functioning for me on the PTR, "quick get" "get dps:start" both produce a "Get a weapon, fool!" error.

...

There we go!

I don't get the "get a weapon fool!" error as long as I manually select the weapons from the list, I do get the error when I attempt to go directly from "copy target" to "quick get" or "get dps:start"

I've never ever tested that function before . Good to know, thanks.

Hi there!

I used the official holiday (in germany) on friday to do some maths about PvE Fury warrior. I tried to put as much knowledge into as I could but there are some points I'm not sure about - they are marked yellow. So this is not the final version . But I think here in this forum is the best place to put the file online and to get some productive discussion and help on it.

The Excel-Sheet includes:
You can compare some talents and 2x1-hand vs. 2x2-hand. You can insert yout stats and the stats of your 2x2-hand vs. 2x1-hand weapons.
To view the results you must scroll down a little ^^
-> For all sceptic: It shows quite easy that TG is an DPS increase, on paper.

The sheet:
Warrior_calculations.xls


I know there are many assumptions on the talents and I hope you will help me to find the real numbers to include.

I hope some can use it, I hope some can help me to correct and improve it.


*corrected an error*