Well so far the sheets agree with each other pretty well.

2 of the main differences I have noticed is Landsoul's sheet values STR more than crit (where on the first sheet socketing for Crit brought the most dps) this is assuming a dream set of ( illidari helm, endless nightmare neck, onslaught shoulders and chest, Shadowmoon Destroyer's Drape, Grips of Silent Justice, belt of one hundred deaths, Divine leggings, legion boots, Dragonstrike MH and Blade of Infamy OH and Ancient Amani Longbow ranged.

The other difference I noticed was the Tsunami Talisman / Dragonspine was the best trinket combo per the first sheet. It is now Madness of the Betrayer / dragonspine, which seems to support the new sheet having a lower value for crit.

Can't say I'm happy about that since I busted my ass to get Dragonspine / Tsunami lol

Lastly Landsoul could you add the Badge bought Nyn'jah's Tabi Boots

thanks.

I can add ninja boots, yes. Check it at the next release.

And I am keeping Mongoose and Exe at base 1 PPM.

My sheet supports STR minorly greater than crit up until about max Sunwell gear and buffs where they equal out.



Version 1.012 March 11 2008
Download Here
FuryDPS1.012.ods - FileFront.com

Changed Madness of the Betrayer to 1 PPM no cooldown
Changed Band of Eternal Champion to 1 PPM 60 second Internal Cooldown
Added Nyn'jah's Tabi boots as they are just a tad better than Warboots of Obliteration.

Well you can't just assume that the added damage from doing >12 rage executes (you will have way more rage per execute with DW than with 1h+shield) is unimportant. You also have to take the loss of OH damage into account. I find it very very unlikely that 1h+shield will be able to compete if you compare the total damage output. You are much better off just switching to fast weapons to ensure that you have 12 rage per gcd. In my experience, having ~150 hit and executing with a fast/slow setup with 95 dps weapons enables me to execute on >90% of gcds

I had a look in the spreadsheets, which are not really good to model this since they currently can't model miss streaks. However, I can look at the average rage generation for my current gear and compare 1h to the DW case (assume 5% dodge for both). With DW I get 12.1 rage/sec, i.e. roughly 18 rage per gcd. With 1 weapon equipped I get 7.5 rage/sec => 11.5 rage per gcd (incidentally just below executing every gcd if you have imp. execute). Both of these are without WF, WF will not help you get executes at every cd, it will rather help you get higher damage executes.

The 1h case will not guarantee an execute at every gcd since this is an average (some hits will be glances, let's assume 25% of the hits) and will only work if your weapon speed gets below 1.5 sec. The DW case (considering fast weapons) will of course not have a guaranteed execute each gcd either, but has the added security of 2 swings for each gcd. Assume that the miss rate is 17% and 25% glances.

Now, let's say that one hit (or crit) will guarantee that there is enough rage for execute at a gcd, a glance, miss or dodge will not work. Then there is roughly a 70% chance that the 1h case will give enough rage to do an exeute. The dw case will have enough rage if one of the weapons hit (or crit), 0.53*0.53 (both weapons hit or crit) + 2* 0.53*0.47 (one of the weapons hit or crit) = 0.78. (same figure assuming that glances give enough rage is 0.95)

So even if you disregard that the DW case will have "heavier" executes, DW will provide a safer rage generation to do executes for this assumptions. Ok, if you have a MH weapon and gear that is good enough to ensure 12+ rage per 1.5 sec even for glancing blows then you may be able to get a 100% execute rate, but if you scale up the DW gear in the same way you will in principle have a 95% chance of getting an execute off at each gcd. Looking at lvl 70 mobs is completely uninteresting in my opinion, using full raid gear and buffs you will have enough rage to execute at each gcd vs such a mob even using a grey sword of crappiness and a cod as oh .

I hope you will forgive if I ask for something completely cosmetical: Is it possible to implement a filter for items in the drop down menus by their drop location? Like, filter our Kara or 5 man gear and such to remove the bloat when choosing an item?

F9 should recalculate everything. Try pressing it a few times.

Grim - I cant wait for your new sheet, especially the 2h - DW weapon switch for execute phase feature. Keep up the good work!

Few questions. . .

Right now fully raid buffed I'm sitting at ~42% crit, ~3300 ap, ~140 hit, and ~300 armor ignore. Now I understand the merits of each stat and combat effectiveness (white v yellow). Basically I'm wondering at what point do you start getting enough diminishing returns on ap v crit v hit. My guild is currently doing the T5 stuff, we haven't yet got Kael or Lady V. Thanks for the replies in advance.

Grim13,

If you're looking to go with a web based solution, I would highly suggest a clientside language such as javascript. Javascript is easy to learn, and easy/fast to code with. If you're already familiar with strongly typed languages like c, then javascripts loosely typed syntax will be a breeze. Theres also no memory management to worry about.

You could use a serverside scripting language(like php, asp, perl etc..), but then you must have the user submit the form for the calculation to be made, and they must wait for the web request to hit your server, then the server must return an answer, which is slow and eats your bandwidth. In javascript all the work is done on the users computer, and results will be near instantaneous. They could even save the html page to thier desktop to run it offline. Plus with a serverside language you must be far more concerned with code security and be very strict with validating user input, which if you're not familiar with coding for the web, is a very significant issue.

You can 100% replicate the spreadsheet functionality in pretty much any programming/scripting language. However, a clientside language such as javascript will be the best for the user experience, as well as the fastest and easiest for you to develop. With javascript, viewing the source code/formulas is a simple right click>view html source, so I think more users will audit the code, which can help bugs to be found and advance functionality.

Before any of the spreadsheets supported prot dps, I wrote my own model in javascript if you want to take a look.
World of Warcraft Prot spec dps Calculator
Theres a lot more functionality that could easily be added. For example, an item database could be embeded into the web page, so that users can select thier items/gems/enchants etc... as opposed to having to enter stats manually. Armory import could be done with javascript if your willing to host a small serverside script to help it.

Flash would be pretty much equivalent to javascript in most apsects.

But, to take a sharp turn...
Have you considered the Rawr model framework? Most of the work is done for you, all you need to do is write the warrior class/spec specific code. Theres many cool features implemented that you can integrate into your own code with little effort on your part. The drawback to Rawr is that the user must have the .net framework installed, and be willing to execute an exe program, which means it will be available to slightly less users. For example, people probably arent going to want to install software and run it while goofing off at work, where as they would still just visit a web page written in javascript. However I still think this is far better than spreadsheets.
http://elitistjerks.com/f31/t21713-r...l_development/

I've been considering writting some warrior models for Rawr, but havent yet commited to it due to time constraints. Other users have expressed interest in helping with it. I say go Rawr, but javascript/flash would be an excellent solution as well.

bagelbite, thanks for the input. That's exactly the kind of reply I was looking for. I will investigate both options that you suggest and see where it takes me. And as to time.....well, work is verrry slow this time of year, and I need something to keep my mind engaged, else I end up more crazy than normal.



I've taken a quick look at both. Rawr looks really awesome, but I am more interested in a web-based solution at this time. For now, I am learning HTML, then JavaScript. I am a total web building n00b.

In comparing the spreadsheet and against in-game measurement using Uptime Meter (Uptime Meter | World of Warcraft Addons | Downloads), I've noted what appears to be a fairly significant difference in flurry uptime. That is, the spreadsheet will calculate flurry uptime in the 80% range, while Uptime Meter will record flurry uptime nearer to 70%. Some of this may be due to the bugs of offhand WW crits not proccing flurry, 3rd flurry crits not proccing flurry, etc.

However, I've also noticed some terminology used on this board which doesn't appear precisely correct, and wonder whether it may be related (I "wonder" rather than "know" because I don't have the Excel fu to verify directly). It's frequently suggested here that flurry uptime can be simplisticly modeled (with a single weapon and in the absence of special attacks or existing flurry bugs) as 1-((1-C)^3), where C is chance to crit against the target mob. This seems like a correct measure of the percentage of swings which are affected by flurry. But because flurried swings do not take the same amount of time as non-flurried swings, this formula does not give you the percentage of time spent under the effect of flurry. I think it's that latter definition that we think of as "flurry uptime" - what fraction of my dps time I have the flurry buff.

To determine the fraction of time spent under the effect of flurry, we have to account for the time difference between flurried and non-flurried swings. Note weaponspeed as S, and the result of the 1-((1-C)^3) formula as F. The time taken by a flurried swing is 0.8S. The average time taken for a swing is 0.8S*F + S(1-F), where the first term is the fraction of time taken by flurried swings and the latter term is the fraction taken by non-flurried swings. The fraction of time spent with the flurry buff is the time taken by flurry swings divided by the total time: 0.8S*F/(0.8S*F+S(1-F)). Arithmetic reduction removes the S component from all terms, so the final result (which I'll call U, for Uptime) is 0.8F/(0.8F+(1-F)).

This doesn't account for all of the difference I saw, which I attribute to the other flurry bugs, but it's a meaningful term. With 40% crit, F is 0.784, and U is 0.744. Accounting for the differences in swing time yields around a 4% difference in "flurry uptime" at that crit level.

I don't know whether the spreadsheet or other models in development account for this. If you're doing something like calculating white damage as DamageWhileFlurried * F + DamageWhileNotFlurried * (1-F), then I think that using U instead of F will improve accuracy. This may also indicate that the diminishing return curve for crit itemization is very slightly higher than previously measured, perhaps changing the SEP very slightly.

Of course, if you're already accounting for this, or I have some math error here, then my mistake!

EDIT: Changed the time of a flurried swing from 0.75S to 0.8S. As Landsoul pointed out, flurry increases attack speed by 25%, it does not reduce swing time by 25%.

Well to start off I can point out that flurry is not .75 of a swing, it would be .8 by your logic. The definition states the swings happen at a 100% + 25% rate, not take 25% less time. For you to tabulate flurry uptime as a portion of time where which swing (especially for DW) and what portion of said swing is not under the flurry buff delves into areas of complex combinatorics. What is the probability of X happening under this specific subset of N number of sets, where N can reach a rediculous amount......

I am trying to model flurry's effects for 2.4, where it supposedly will not be bugged and OH WW crits to refresh the timer. I do not plan to take the rediculous amount of time and energy in modeling partial swings because thats going way way way too far and my margin for error (at least) it less accurate than even delving into it at all. My model will show increases and decreases in flurry uptime where it deems appropriate based on rates of crit and the relationship of flurried attack speed versus rate and number of special attacks.


Also, would anyone here know of a minimalistic way to incorporate SEP calculations without relisting all of the models again 8 different times for each stat? Thanks.