Archived

This topic is now archived and is closed to further replies.

Astrylian

Rawr (v2.3.23 released on 9/12)

2714 posts in this topic

I'm sorry if I missed this, but where do you import the items from?

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?

Share this post


Link to post
Share on other sites

Armory as well. It's not in a database, but rather I build some data objects based on the armory data, and serialize those data objects to disk between launches.

Share this post


Link to post
Share on other sites
I'd definitely love to see an Enhancement Shaman version of this!

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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:


float hasteBonus = stats.HasteRating / 15.76f / 100f;
float attackSpeed = (1f - (stats.Bloodlust * bloodlustUptime)) / (1f + hasteBonus);
float meleeTicker = attackSpeed;
[/code]

This type of averaging doesn't fly at all for enhance shaman.

DPS from a weapon constantly swinging at 1.49 speed is [b]incredibly[/b] 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.

Share this post


Link to post
Share on other sites

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. :)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Even ignoring items with relevant procs (haste/crit rating), there are five relevant variables: MH speed, OH speed, crit rate, passive haste, relevant procs on items. "Sane" ranges for these based on Yo!'s sim would be around:

MH speed: 2.5-2.8 (4 options)

OH speed: 2.5-2.8 (4 options)

Haste: 0-100 (steps of 5 would give 20)

Crit: 20-40% (steps of .25% would give 80)

Procs: 6 items with procs seems like a reasonable guess (64 possible combinations)

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.

Share this post


Link to post
Share on other sites
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 :)

Maintankadin :: View topic - Character Itemization Development Platform

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Got a specific request now... fr0d0b0ls0n, a friendly tree from here is working on the Rawr.Tree model now, but could use some help on the coding side of it. Any skilled C#ers with an interest in trees want to help out?

Share this post


Link to post
Share on other sites

Do you need any testers?

My coding isn't so great, but i've done a reasonable amount of work with UI design and Software Testing.

It's easiest for me to help on Hunters, but i can systematically click on stuff for any of the modules.

Share this post


Link to post
Share on other sites

I'm always looking forward to helping in the Rawr project, though I may not know much about coding!

So far I'm seeing that rawr b11 seems to have been some huge changes form b10. The whole itemcache is different as is the character sheets I guess. Gotta redo my character manually since armory is down ftl. Will report more after that! :)

Might want to consider adding some kind of class gear base thing, cause I'm showing rogue t6 in my possible upgrades. lol Really like the way editing items is setup now, screw messing with the xml files.

LOVE the new options, sort of reminds me of spreadsheets.

Share this post


Link to post
Share on other sites

I'll take a look at this tonight. I'm rolling up an enhancement shaman now with an eye towards raiding again with it. Also, I'm very knowledgeable about the development platform. Perhaps some sort of interop solution that involves calling into Yo's simulator directly is a possible way to get what we want.

How do you guys prefer to collaborate on this? IRC?

Share this post


Link to post
Share on other sites
I'll take a look at this tonight. I'm rolling up an enhancement shaman now with an eye towards raiding again with it. Also, I'm very knowledgeable about the development platform. Perhaps some sort of interop solution that involves calling into Yo's simulator directly is a possible way to get what we want.

How do you guys prefer to collaborate on this? IRC?

Deffinately would like to see an IRC setup for this project. :O

Share this post


Link to post
Share on other sites
Do you need any testers?

Everyone's welcome to 'test'/use the betas as we release them. Between those, for our dev builds, I'm not really looking for testers actively, but wouldn't refuse it... If you've got VS2008 and sign up for an account on CodePlex, send me your codeplex username and I'll add you to the project so you can test out the latest source as we check it in.

I'm always looking forward to helping in the Rawr project, though I may not know much about coding!

So far I'm seeing that rawr b11 seems to have been some huge changes form b10. The whole itemcache is different as is the character sheets I guess. Gotta redo my character manually since armory is down ftl. Will report more after that! :)

Might want to consider adding some kind of class gear base thing, cause I'm showing rogue t6 in my possible upgrades. lol Really like the way editing items is setup now, screw messing with the xml files.

LOVE the new options, sort of reminds me of spreadsheets.

Ugh, sorry about those Slayer Gloves. I armoried a Rogue right before releasing b11, and his Slayer gloves got into my itemcache. Same with his weapons. Will have that cleaned up (well, filtered out of the Cat model) in another version.

How do you guys prefer to collaborate on this? IRC?

Deffinately would like to see an IRC setup for this project. :O

So far, just the dev site on codeplex, and IM/e-mail. I personally don't use IRC a whole lot, but that could work. My only fear with an IRC would be that tons of users would come in and ask things like "hey can u rate my gear?" or "lol look i made a set thatz got 100 dodge lol"...

Is there a beta with a compiled version of rawr.mage.dll available ?

Kavan has been working extremely hard (up til 3, 4, 5, sometimes 6am working on it, judging by when he's checked in code, heh) on Rawr.Mage. I don't know when he expects to be at a releasable state, but it's looking not toooo far off.

I've been working on coordinating all these new projects (and killing Illidan and Archimonde for the first time, yay!), and haven't had a chance to work on Cat/Bear much, so haven't gotten done the new Cat functionality that I promised for b12. But, Rawr.Moonkin and maybe Rawr.Mage might be in a releasable 'alpha' form by this weekend. We can't release just them, though, because they rely on several new pieces in the core app that aren't there in b11.

So I'm *thinking* of releasing a Beta 11a this weekend or early next week, with any of the models are ready. Would that sound good?

Share this post


Link to post
Share on other sites
Got a specific request now... fr0d0b0ls0n, a friendly tree from here is working on the Rawr.Tree model now, but could use some help on the coding side of it. Any skilled C#ers with an interest in trees want to help out?

I may be able to help with the programming. I am looking over the feral version right now to see what it's all about.

Share this post


Link to post
Share on other sites
I may be able to help with the programming. I am looking over the feral version right now to see what it's all about.

OKie, toss me an e-mail (cnervig@hotmail.com) or IM (cnervig@hotmail.com on MSN, Astro tSD on AIM) if you're interested.

Share this post


Link to post
Share on other sites

I made some graphs about Enhancement Shaman to try to figure out if a closed-form model is even possible. Each point is the result of 10k hours run, giving a standard deviation of .0001. I'm almost certain that the Flurry model used is wrong, but that shouldn't effect the overall shape of the graphs.

Unless otherwise specified, all graphs use 25% crit, two 2.6 speed weapons, 0% haste, 22% hit.

Crit vs. Flurry uptime:

attachment.php?attachmentid=2009&stc=1&d=1203714576

A nice smooth graph. 1 - (1 - crit^5.5) fits the data with an average error of .58%. Although WF and Flurry interactions are ugly, they appear to actually be insignificant enough that they may just be ignorable.

Crit vs. WF proc rate:

crit_wf.png

Note that all of the bumps are significantly larger than the expected variation produced by the RNG, so it actually is that bumpy. However, note also the data range -- the proc rate varies from 15.70% to 15.59%. This is so minor as to be ignorable.

Overall, with weapons with matching speed, crit rate appears to not need a full set of simulations -- its effect on WF proc rate can simply be ignored, and flurry uptime merely requires a single run to find the exponent for a certain speed. If the same holds true for unmatched speed situations, then the required data set drops to 20480 runs.

Haste vs. WF Proc rate:

attachment.php?attachmentid=2012&stc=1&d=1203714599

As the graph doesn't make it clear, the jumps are when the speed is (flurried/unflurried): 1.49/1.8, 1.361/1.614, and 1.27/1.49. Luckily, these are exactly where expected. Each individual section is non-linear, but the total variation is under .3% for all of the sections, which is low enough to ignore.

Haste vs. Flurry uptime:

attachment.php?attachmentid=2011&stc=1&d=1203714592

The jumps are at the same points as with the WF proc graph (and are probably caused by the drop in WF procs). The individual sections fit an equation of the form uptime = b + m * haste, with m constant across all of the sections. My copy of Excel is missing the data analysis addin, and I don't really feel like doing a logarithmic regression by hand, so I don't know the exact values.

For weapons with matching speed, haste effects appear to need only 5-10 runs to build the complete curve. If unmatched speeds work in the same way, this makes the required data set drop to 6820 runs. In addition, the simulator I'm working with currently takes about 10 seconds per run. This would reduce the total time require to produce a data set down to 19 hours.

There's a lot more that I need to look into still, but it looks like although the interactions between haste effects and windfury are very complicated, it may be possible to simplify or ignore enough of them that it's possible to build a closed formula for shaman dps which is backed by a simulator-generated dataset in a realistic amount of time.

data.xls

post-1456-1382326059378_thumb.png

post-1456-13823260594164_thumb.png

post-1456-138232605946_thumb.png

post-1456-13823260594974_thumb.png

Share this post


Link to post
Share on other sites

  • Recently Browsing   0 members

    No registered users viewing this page.