Crackalack because SMD never dropped for them or they do not have enough DKP.

Such as my case.

Supremus neck? One dropped for almost 10 months of farming. We got our 2nd syphon week ago.
Supremus is xbow/idol fest.

RNG and heavy competition are not your friend when dealing with most 'best-in-slot' items. Our raid hasn't seen a Syphon drop in the months we've been in BT. SMD is sought after by Hunters, Rogues, Warriors and Shaman. The same applies for the neck off Supremus. Its just not possible to get all of the gear you'd like all of the time. That's what badge gear is for. Though they may be using Dory's for the defensive aspect? I'm not working on Twins so I can't comment on their actual intent.

Now my question about Lootrank is if it values the [Shattered Sun Pendant of Might] correctly. I'm Aldor and unclear about where the pendant fits in with other neck items. Lootrank has it listed above the Hyjal trash neck which I am wearing currently.

If this has been discussed to death in another thread, could someone point me in the right direction? I wasn't able to find it.

have a question, isent it better to use season 3 axes as an orc and DST and Blackened Naaru Silver?

Or should I use Mounting vengance and shard of contempt instead of the DST?

There was a discussion in the old thread about this neck, way back. It's certainly better than the trash neck, but only by about 10 AP or so, and because it's an on-proc you're going to see more fluctuation in your damage numbers.

Read the wiki -> Offhand & trinkets, specially those are listed there. Also test it with yo's simulator.



p.s. and if you're a slacker and want me to give u a blind answer without knowing ur gear & needs, I'd just say : mounting vengeance/shard of contempt.

Not really. Three new bits of T6 + Shard is over the exp cap. If you're an orc wielding axes, you are further over the exp cap and deflate the EP on the Shard. The question is valid and not covered by the Wiki. The answer is covered by using Yo!'s sim however.

[Mounting Vengeance] is better than [Vengeful Gladiator's Cleaver] allways. Off-hand expertice isn't even 1/3 value of both hand expertice(SS mechanich Mh roll first). Pure stats > 5 expertice for oh.

Simulator says that [Shard of Contempt] > [Dragonspine Trophy] by 2dps with your gear. And when you use shard you can get your fist set complete when kil'jaden drops it you are still expertice capped.
Edit: Even [Berserker's Call] paired with haste potion's is par with dradonspine for you.
Edit2: [Madness of the Betrayer] might be best choise for small margin for you.(+1dps from shard)
Edit3: [Tsunami Talisman] Yieds same dps too.
Conclusion use what you like dps margin is minimal.

I assumed passive 130ep for [Blackened Naaru Sliver].

Hello everyone.

First of all, I am not sure where to post this. I'm sorry if this is a wrong place.

I am new to this forum, so let me make a quick introduction about myself. I am 22 year old software R&D student at Tampere University of Technology in Finland. I don't actually play WoW anymore, but I used to play enhancement shaman at Dragonblight. I've been always interested in optimizing and WoW makes no difference, thus I like to use simulators/spreadsheets. Even I'm not playing anymore, I am still interested solving the problem of estimating enh dps. Anyway, let's get to the point.

I noticed the thread about Rawr and there was some discussion about making a closed form model of enhancement shaman. As most people knew, it turned out to be extremely hard. Then it struck me. We could possibly use artificial neural network to model all the necessary values with different set of inputs(weapons speeds, crit etc.). If you don't know what ANN is, you can read: Artificial neural network - Wikipedia, the free encyclopedia . You can see a simple ANN on the right in that link. Short explanation is that, ANN is a black box with certain number of inputs and certain number of outputs. Inputs and outputs are just numbers. You give it some inputs and it gives you the outputs. The interesting part here is, that you don't really have to know how does it work. You are able to train the ANN to give the correct answers with a training data set and backpropagation algorithm.

We could set up an ANN to have at least weapons speeds, crit and hit as inputs. Outputs could be like absolute windfury procrate, flurry uptime etc. What we need to do this, is the training set. Sadly, the training set is huge as it would need the combinations of the inputs from the wanted range(like crit 15-50%) and the desired outputs. For example:

crit 15-50% 0.5% steps = 70
hit 6-25% 0.5% steps = 38
weapons speeds 1.3-2.8s 0.05 steps = 30 + few additional data points for critical speeds like 1.51 and 1.49 etc.

That would make 70 * 38 * 30 * 30 = 2394000. That's a big training set and it would take forever with Yo's simulator. I could make a simplified simulator with C++, which would be a LOT faster and also allowing me to generate that training data for the ANN automatically.

Anyway, I need help and suggestions to determine the inputs and outputs. What effects what? What outputs do you need to make the closed form? Anything else than flurry uptime and absolute windfury proc rate? Also, what do I need to model in the simulator to get correct results?

In theory, this method should work. In practise, who knows? The amount of data is huge and it could be just too slow to process all the data. Well, thanks for reading and say what you think about this. Is it worth to even try?

If you only had to do the training ONCE...... it wouldn't matter if it took a week-plus to run.

However....... It has been my experience that you are dealing with a moving target. I (used to) maintain the simulationcraft wiki pages for caster classes at the shadowpriest site. The entire suite of runs took almost 48hrs on my laptop. That doesn't sound bad until you realize that I need to re-run every time I tweak the simulator, change the talent spec, or use different raid/party class setups.

If the problem sits still long enough, then you can nail it. But if/when it moves.........

As for coding the actual simulator: I'm in the process of re-writing simulationcraft to handle the physical dps classes. If you can wait a month or so you could use that and simply worry about wrapping it up for your ANN training. The new architecture is complete, and I'm in the process of migrating the existing caster support over to the new base. Once that is up and running, I'll start adding the new class/specs.

Yes, changes to the game mechanics would propably be an overwhelming problem. Also things like trinkets with procs would be another problem as it would make the use of ANN inaccurate. I guess I won't be trying to implement this idea.

You mean an unified simulator for all classes? Wow, if you are able to pull that off, you have all my respect. Just out of interest, how many lines of code do you have in it currently?

I talked about my own simulator for generating the data for ANN training. Well, I implemented most of it(just to calculate wf chance, flurry & ur uptime) and noticed that I was able to make it lightning fast. Really, it is ridiculously fast. Currently it has only windfury, flurry and ur. I made a little comparsion with Yo's sim. I know Yo's sim has way more stuff modeled than mine so this comparison isnt equal. Nevertheless, here are the results:

Hours: 20000
Yo's sim: around 3min 40s
My sim: 3.75s

Thats around 58 times faster.

Let me tell you again: I know this isn't fair comparison because Yo's sim have more stuff modeled than mine. I disable things during the test that wasn't simulated in my simulator but I doubt it makes a big difference in the speed. Also the fact that Yo's sim is made with Java, is good for usability(use in browser, natively multiplatform) but takes a toll on the speed. I like Yo's sim but it's just so slow, that it's killing me.

I don't know should I develop a full blown enhancement shaman simulator from my sim. Maybe I will, coding is fun . I am interested in your sim's speed, is it more like mine, or like Yo's? Maybe if it's fast, I can be lazy and just ditch my project.




EDIT: I forgot to mention that my simulator supports multithreading. I have core2duo t7700(2.4GHz, 2 cores) and I ran my test with 2 threads.

Your sim (as run on my old T42p laptop) is considerably faster than mine..... probably on the order of 50x.

It is not a perfect comparison. I used a shadow-priest rotation since I don't have enhance-shammy implemented yet. But I expect the speed to be similar. To be honest, I'm more focused on function at the moment. There are obvious opportunities for performance improvements:
(1) It is a discrete-event simulator and i'm allocating/freeing event structures without a custom memory manager.
(2) I'm using double precision floating point numbers instead of the classic approach of 64bit integers with a 0.001 precision.
(3) I didn't implement any thread-support. It is a multi-player sim so it is possible, but I'd have to add mutex locks around all the main target queries as well as the player-to-player aura/buff changes.

I haven't done any profiling, so there may be other low-hanging fruit...... but I doubt there will be any magic fixes.

But even after all that...... There is no way I can approach the performance of a simulator customized for just one class.

Player-event support for handling procs, player AI for the conditional priority list specifying the "next" action, support for vast amount of player synergy affects....... it all adds up even when I'm being careful.

EDIT: But as you mention: Projects like this can be fun! And that is the main reason to do them.

Yes, focusing on the function is a wise thing to do on such a big project.

Ok, let me give you some tips about optimizing.

(1) I am using boost::pool for fast allocation/freeing memory with my events. Before optimizing, I was using the default new/delete. Then I changed to boost::pool and the speed went from 350000x to millions times real time. Boost::pools are easy to use, just make a static pool in a class and overload new/delete(if you are not using multithreading). If multithreading, that can't be used, as sometimes the threads use the pool at the same time, which is BAD. I have an event pool in my simulator class. When using multithreading, I have 2 sim instances, thus 2 different pools. That way I have to explicitly call the constructor though, no big deal.

(2) I am using normal ints in my calculations as I noticed that I can't get the accuracy I want otherwise. I don't know should I use 64 bit integers but I don't think so, because I am not near overflowing. One thing about performance. I don't think it would give you are big boost to change to integers, but one thing you can check is, if you are using casting from float/double to int much. Float/double -> int conversion is a performance killer if it's in loops etc. Google it up somewhere...It flushes the pipeline or something. You can replace it with 2 lines of assembly code.

(3) I am using ZThread for multithreading. It's very easy to use, but you have to take certain things in to account when multithreading(like memory pools). When multithreading, I simply divide the wanted simulation runtime by the number of threads, and then run the different simulations and average the results. Easy to implement.

One thing to try is changing from the default rand() to custom randomize. I use SFMT SIMD-oriented Fast Mersenne Twister (SFMT) . Mersenne twister gives better results AND is much faster than default rand().

Yes, I find it entertaining to squeeze the last drop of performance from my code . If you need help in using those 3rd party libraries, by all means send me a PM. You will see the biggest performance gain from boost::pool. Good luck .

Thanks, Tukez. 99% of my allocations come in just two sizes so I had planned on just maintaining the free-list myself...... but I suppose I could use boost for that. I never even considered the performance implication of rand(). I'll have to check into that.

I disagree that neural networks are the way to go. One thing people want out of a closed form system is understanding of the variables in the equation and I've found it's often quite hard to decipher the output from a neural network.

Besides, closed form Shaman DPS shouldn't be too hard. I think I have a pretty good idea of what it would look like; I just don't have the maths to produce it.

Shaman DPS has 5 cycles: autoattack, windfury, stormstrike, shocks and fire totem.

Fire totem dps is mostly straightforward; however, it would need to be based on the average AP (including all buffs and on-procs including UR, etc).

Shocks seem nearly as straightforward; it would need average AP as above, and it'd be nice to figure out the interaction with the Stormstrike CD.

Stormstrike damage is the most straightforward, though its different attack table (MH miss/dodge/hit, followed by main hand crit roll, followed by offhand rolls, etc) means you can't just add an extra 12 chances to hit per minute.

Windfury is, of course, the real challenge. Windfury can be triggered by autoattack or SS swings and to really accurately model the effect, you need to model both hands separately. You can't just join them, and divide the number of swings by some MH:OH coefficient unless you have a means of computing the coefficient. Theory is that the MH gets a slightly higher chance to proc because the MH always swings first in SS. Also remember that even weapons with the same speed will get out of sync pretty quickly; all it takes is haste falling off between two swings and your weapons are permanently out of sync.

Furthermore, obviously faster, more accurate hits should result in more WF procs, to some limit imposed by the CD. Thus, all the melee damage cycles will feed into each other...however, I don't think you'll need to feed these systems into each other very far to get an accurate picture of the data. When I've toyed with this in simulation, I stopped the sim as soon as my numbers for procrate were stable to 2 decimal points -- that is, that over two cycles of feedback the digits in the second decimal did not change.

So: the challenge is to work out the average windfury procs per hand over time, to use that to adjust average speed due to haste procs, and to feed that number BACK into the AA and SS cycles to find out the average windfury proc rates again, until the average proc rates are precise enough for your taste. The inputs to this system will be weapon speed, crit rating (for flurry uptime), hit rating, expertise and haste. On procs to worry about are all haste procs (DS, DST, mongoose, flurry).

Once you know how many WF swings you have, you can figure out average AP, average crit, and then you can figure damage for everything.

Doesn't seem that hard. But I can't do it.

With ANN, those wf procrates would come from an unknown function. Honestly I don't get what does it matter are the actual calculations unkown or not. Anyway, I decided to try to program a fast simulator, which I prefer to a closed form solutions.


For the simulation, I need to know all the relevant mechanics. You seem have some deeper knowledge on SS and flurry mechanics? Could you help me out with these? If you could write a description from both skills as accurately as possible trying to take all possible variations into account, it would help me a lot. At least flurry is a major pain in the ***.

Question about windfury. It is using 2-roll system, am I right?

Also thing about skill rotations. Do people use same rotation all the time, or do they, for example delay SS after WF CD is off? What if they delay the SS and shock cooldown goes off during waiting? I'm asking this question, because I am trying to design a skill rotation system for my simulator.

If anyone is willing to help me, I would greatly appreciate it. Thanks.

As far as I know, there are three main strategies for shock/ss priority with 6s shocks:

1) Whichever's First -- in this case, you just mash whichever button comes off cooldown first. Easy enough to figure out, this results in adding 1s per 30s (or so, I haven't done the math in a while) to the shock cycle and 1s per 30s (or so) to the SS cycle.

2) Hold SS while WF is on CD -- a more dynamic playstyle; you only strike when WF is off cooldown. Usually, shocks suffer in this style, though some folks will fire one off if there's more than 1.5s left on the WF CD. This is harder to model.

3) Twisting -- the essential rhythm while twisting is shock-WFT-GoA. Many people use the shock CD to ensure their WFT is properly timed. Thus when twisting, there's only room for one shock per 10s cycle without screwing up the that rhythm.

For shamans with 5s shocks, there's no interference between the two cycles. You should be able to work out a twisting cycle with no interference as well, though good luck finding the mana to maintain it.

As I understand it, Stormstrike is a two-roll system, and the off hand doesn't swing if the main hand misses.

psuedocode:
if (checkMHHit()) { //ROLL 1, where "hit" means "not dodged, parried or missed," miss at 9% chance vs l73 mob

checkMHCrit(); //ROLL 2
checkForWF();
if (checkOHHit()){ //ROLL 1 (of offhand)

checkOHCrit(); //ROLL 2 (of offhand)
checkForWF();

}

}

I believe WF also uses a two roll system, each hit is evaluated separately and with a 9% miss chance.

9% + 19% miss chance, for 9% and 28% respectively.

Hit - WoWWiki - Your guide to the World of Warcraft (which I edit any time somebody effs up the Shaman section)

I thought about ANNs, i thought about higher order markov model and hidden markov models, i chose the path of the hidden markov models back then. Good luck with your idea, my mini sim I wrote for verification did some 1k hours (single threaded) per second, so I guess it's not far fetched to get 4-5x the speed with some more optimizations.
The easiest way imho to optimize is simply using some fifo event system, which gets processed then. The most important thing is to keep your individual swing evaluation small (computational wise). You don't need doubles, floats do the trick too and can be optimized way better.
In any case you should post your simulation code for review, since there are many small tweaks necessary (like oh ss not being checked after mh ss miss etc.)

Firstly thanks Toots Hepcat for help.

Yes, I have something like fifo event system in my sim. Well maybe I can't talk about my sim yet, because haven't done much to it yet. Actually I use integers in my calculations. First I tried with floats, but for example weapon speed 2.60 would be like 2.59999. I want them accurate as possible so it would be easier to debug. I will post the code for review of course, but before I even start coding more stuff to it, I need to figure out some things first:

How the heck flurry works? For example with same speed weapons and without parries, does MH and OH stay in sync? Somewhere I read, that they won't get out of sync, if you start attacking before you are in melee range.

I am still thinking about some simple but flexible skill rotation system. I would like to make it flexible enough, that I don't have to compile the code to change skill rotations. As I understand, in WotLK, there could be many possible skill rotations and I really want my sim to have easy maintenance.

Guys, can we get this moved to it's own topic. While I appreciate the fervor and the (eventually) useful results that this will produce, we've moved way beyond "help me with my shaman" and into a highly technical conversation understood by maybe a half a dozen people reading the thread. For those of us that aren't programmers, this last page is about half intelligible and half foreign geek speak. It's probably very worthwhile geek speak, which is why I suggest it gets it's own thread, but still wellbeyond the scope of the discussion the thread was intended for.

Maybe you just should skim those posts then and not worry about the parts that aren't of use to you?

I don't understand half of what they are talking about but I am quite content to read what they write and to learn what I can from it. The original mega-thread had pages and pages of information similar to this and that lead to what we currently know about how to best play an enhancement shaman in the game. The things they are talking about are just the kinds of things that led to Yo!'s simulator and to the Rawr's for other classes and hopefully will lead to more things like that for me and you and all the other shaman playing enhancement to utilize and enjoy.

Edited for clarity

I agree that this discussion will lead to useful places, but the original mega-thread has been turned into a wiki for a reason. If you parse this stuff out into separate threads with more focused topics, it becomes easier to find what you're looking for. From reading the topic title I would never know that the discussion inside has to do with varying computer models to improve simulation. If I were interested in talking about that, I probably wouldn't think to join this thread. If I were coming here looking for help on gear choices/gemming/self buffs etc. I would have to sift through a lot of information that was useless to me in order to find that. I'm not complaining that they're talking about it, simply suggesting that it would be better for everyone if we segregated these conversations a little in the interest of organization. That's part of what makes these forums so wonderful, they are an authoritative source on everything because there is a structure and a plan here, unlike say the Blizz forums where you get a thousand spastic mish-mash topics.

That having been said, as an aside, what is the best personal dps we can expect to see on a stationary fight like Brut? I'm consistantly pushing 2k+, occasionally spiking over 2.1k, and I want to know if that's about as good as it gets. Can anyone else that's pushing hot damage throw their totals out there so I can see how close I am to capping out?