Better yet, we could make it a community thing to try and get a rawr for all the existing specs and classes that have been theorycrafted extensively in this section. (To bad i'm both math and programming illiterate and would be of no use whatsoever in furthering this idea.)

Cowbell: Every man who reads the BB has a genius IQ and a ten inch cockDeeNogger: I am PMing you a picture of my balls because somehow that is thanks for the link.

Better yet, we could make it a community thing to try and get a rawr for all the existing specs and classes that have been theorycrafted extensively in this section. (To bad i'm both math and programming illiterate and would be of no use whatsoever in furthering this idea.)

I just recently started a similar project for Protection Warriors. I wrote it in VB; .net Framework 2.0. I collected the information from wowarmory, deposited it into a hosted database. When someone goes to my webpage, they enter their character name an realm, pick what instances they are currently capable of clearing, and load the page.

I did "pre-rate" the items, based on Armor Equivalence Points. I am working on the algorithm now that working round "Health Equivalence Points" or something to be displayed on the page, time to live, or something, that when you change an item out with another item, this will be updated to show how one item will reflect with the entire set overall.

My biggest challenge was to gather the data and get it into a usable format, how did you overcome that?

Won't happen unless we do one of three things -- Modify Rawr to allow EP values to be input as the comparison settings- Figure out the "one true EP value" that works perfectly and correctly at every gear setting- Include the 'baseline' EP values as options to compare with

Won't happen unless we do one of three things -- Modify Rawr to allow EP values to be input as the comparison settings- Figure out the "one true EP value" that works perfectly and correctly at every gear setting- Include the 'baseline' EP values as options to compare with

Sorry, EP?

EDIT: Ah, "Enhancement Points". Give me a few and I'll explain how to properly model this in Rawr.

OK. EP values are equivalency points, which wouldn't work in an accuracy-based system like Rawr. But the current EnhSham sims do compute DPS, which is what Rawr would need (You'd also want a 2nd rating of UR uptime). So ignore EP, let Rawr do the accurate calculations, based on the DPS calculation formulae you've already got. Except, there's the problem, they're simulators which run thousands of hours of attacks, not formulae, which would be extremely slow in Rawr.

Using the simulators, you can build formulae to predict the uptime of Flurry compared to crit rate and weapon speeds, and formulae to predict the overall WF proc rate based on Flurry uptime and weapon speeds. Those could then be used in Rawr, to calculate DPS and URU in single passes. It's a process similar to what Toskk has done for the heavily proc-based rotations of Cats, and is now the basis of Rawr.Cat.

Using the simulators, you can build formulae to predict the uptime of Flurry compared to crit rate and weapon speeds, and formulae to predict the overall WF proc rate based on Flurry uptime and weapon speeds. Those could then be used in Rawr, to calculate DPS and URU in single passes. It's a process similar to what Toskk has done for the heavily proc-based rotations of Cats, and is now the basis of Rawr.Cat.

The difficulty (or just obscene tedium, depending on which method you take to calculate it) of doing what you describe, accurately, is exactly why we use sims.

That having been said, if someone spent a lot of time graphing out the results from the sim to make a close-enough-approximation for the WF ratios and flurry uptime, perhaps it would work. I'll check out Toskk's work to see what's up there.

Procs themselves aren't hard. Procs with internal cooldowns are harder. Perhaps I should be looking more into the models of people who have worked on trinket procs.

Edit 1: for an example of why it's hard to do closed for windfury, it's because there are so many intertwined variables:

Given weapons of given speeds,Windfury procs are dependent on weapon speed times (in absolute seconds), which are dependent on flurry being active or not, which is dependent upon crit rate, stormstrike crit rate, and windfury crit rate, and windfury proc rate.

Which is a nice way of saying that the windfury proc rate affects it's own self as a second order effect due to the fact that it can proc flurry. Maybe I'll make a pretty picture of this.

Edit 2:I just checked the Cat model. Looks like a lot of work went into that, though I had brief moment of sadness seeing the powershifting line /grieve

In any case, stuff like this makes me a bit uncomfortable, taken from CalculationsCat.cs:

DPS from a weapon constantly swinging at 1.49 speed is incredibly different from DPS of a weapon that swings at 1.51 for 9.33 minutes and 1.16 speed for 40 seconds, even though the total number of attacks (ignoring flurry) per bloodlust-cooldown-cycle is the same. I know it's just one example in the cat code, but seeing people be able to do this compared to what we have to deal with makes me less inclined to think this is practical without the afforementioned calculatory breakthrough, or someone spending a whole lot of time with the sim to chart all the variables and retroactively fit an equation to it.

Indeed, it's a very complex problem, and would be very hard to build a one-pass function to model. Perhaps too much work to be worth it. Was just throwing out how I think it could be done, theoretically, (it may not even be possible, I'm just guessing, I don't presume to tell you guys how to theorycraft your class that I'm not that familiar with) to work with Rawr. It very well may be that EnhShams' rotation is too erratic to be reasonably modeled in Rawr, disappointing as that may be.

EDIT: Aye, I didn't mean to say that how the cat model handles haste is how an EnhSham model could. Rather, I saw similarity in how your attacks are erratic based on changing weapon speed to how ours are erratic based on changing energy regen (Clearcasts and energy gain procs).

EDIT2: The averaging you quoted there works for us because haste benefits scale in the same pattern (increasing), whereas yours scales up, then horribly drops off once you pass the cusps of each level of weapon speed within the WF cooldown (1.5 to 1.49, 1.0 to .99)... I think that's how yours works anyway, not positive, like I said, my enh shammy is a lvl 45 noob.

EDIT: Aye, I didn't mean to say that how the cat model handles haste is how an EnhSham model could. Rather, I saw similarity in how your attacks are erratic based on changing weapon speed to how ours are erratic based on changing energy regen (Clearcasts and energy gain procs).

That's actually the part I want to look at more, because I agree it at least *seems* similar, with discrete chunks intertwined with the linear stuff. If it could work out, I think rawr looks really really nice.

That's actually the part I want to look at more, because I agree it at least *seems* similar, with discrete chunks intertwined with the linear stuff. If it could work out, I think rawr looks really really nice.

Could you perhaps look at a Flurry proc in the same way you look at a Windfury proc? A Flurry gives you an extra 1.5 (?) auto attacks, in the same period of time, though 0.5 (?) of them wouldn't be able to proc windfury so you'd have to discount the damage they could do? I supposed you'd run into problems of counting too much damage on back-to-back flurry procs... I dunno, just throwing out ideas.

Use the existing sims to generate 4-5 uptime lookup tables (crit vs. uptime) for given popular weapon speeds, rather than attempting to derive functions perhaps? 20 reference points in realistic crit ranges with a forced average on in-between points would be good enough.

Many times when you have a higher order system like this, it's simply easier to lookup a points on a measured curve than figure out the precise formula that drive the function itself.

The point of any simulation is never to perfectly predict future outcomes (nearly impossible whenever you have random elements), but rather to model it closely enough that you can make informed decisions that are likely to yield good real world outcomes.

This would take 1,638,400 runs to build the data set. At one minute per run (Yo!'s takes a bit longer, but also does more than we need), this would take 3.1 CPU-years to build. This data set is still not guarunteed to have all of the inflection points. If we knew where all of the inflection points are generating the data set would be fast and easy, but if we could find the inflection points we'd already have a closed equation for dps.

To whoever responded about working on a Tankadin version, I just made a post over on maintankadin asking about it....so if you'd like help or have mechanics questions to be answered while working on it, feel free to post there....at a minimum you're sure to find peopel to give input and test it

To whoever responded about working on a Tankadin version, I just made a post over on maintankadin asking about it....so if you'd like help or have mechanics questions to be answered while working on it, feel free to post there....at a minimum you're sure to find peopel to give input and test it

Abynth and thedopefishlives both were interested in doing the Protadin model, so Abynth went ahead and started it, and thedopefishlives started on Rawr.Moonkin instead. But now Abynth has stopped working on it (conflicts with his work over writing public code or some weird thing), so thedopefishlives is working on both of them. I'm pretty sure he wouldn't mind any help.

If anyone wants to help out with any of the models, create an account on CodePlex.com, and tell me your account name, and I'll set ya up.

Went to ask about a tps model for bear and realized it was already asked and answered (it's coming), so I'll just say I'm looking forward to it so I can more easily tell if my threat output is my fault or my gear's fault (likely mine).

Though can I request that the output of the bear threat report be labeled "TPS Report"? So if you could just put that cover sheet on the TPS Report that'd be great.

Though can I request that the output of the bear threat report be labeled "TPS Report"? So if you could just put that cover sheet on the TPS Report that'd be great.

I laughed so hard at that, I just might have to include it.

The Protadin module is forthcoming; I will probably start it next week. Along with it will (hopefully) come a threat generation mechanic that can be applied to bears and warriors, as well. That's the goal, anyway.