It's too early to complain about shadow priest DPS relative to other classes. Mindflay's change has not been implimented, and no DPS class has had it's abilities or numbers finalized. At least wait until the major passes have been completed before you decide shadow priest DPS is too low and that there won't be any raid spots for them.

Meltface has exactly the right idea of how to go about this subject.

Caligula, whining does not have a place on EJ boards per this thread.

Since you are confused about paladin and shamans, please refresh yourself on wrath changes for those two classes, particularly the part about raid-wide totems and paladin buff changes.

There is a discrepancy between the math I presented and the SimCraft results you presented. Without understanding why this discrepancy exists, we can't claim either result is accurate.

Since it's a heck of a lot easier to look over my fairly brief post than it is to screen & validate the largely uncommented source code of the entire SimCraft program, the obvious answer is to see if we can find something wrong with my math. Failing that, simply saying "I trust SimCraft" isn't really any different than say "God made it so" in an evolution vs. creation debate.

If this was a case of comparing two pieces of gear under BC raiding rules, I'd happily defer to SimCraft. The mechanics are well-established and the program has been used enough that hopefully most of the bugs of any significance have been discovered and corrected.

In the case of comparing two different builds based on WotLK rules that didn't even exist two weeks ago and potential mechanics that we may not fully understand, it makes no sense to trust SimCraft beyond very broad comparisons. For example, you'll notice that I skipped over the mana regeneration issue - while noting that Smite was much less sustainable and lack of Meditation was a problem. The reason I did this was that there is no accurate way to predict what constitutes reasonable gearing, buffing and casting patterns in WotLK raids. You can certainly run a lot of numbers, but those numbers would be meaningless because the basic data you're using is so flawed.

I'm not saying that SimCraft is a bad program. I'm just saying that its results don't constitute a valid argument in this case.

Doubt is good. Doubt leads to verification which in turn leads to better accuracy.

To help you on your journey, this link will take you to the trunk of the source code repository.

There is a class hierarchy:

• action_t
  • spell_t
    • mage_spell_t
      • ...
    • priest_spell_t
      • mind_blast_t
      • shadow_word_pain_t
      • ...
    • ...
  • attack_t

The majority of talent effects are encoded in the constructor of each spell/attack (ie: mind_blast_t). These are easy to find since each class has its own file. There are also cascading calls to target_debuff() and player_buff(). Start from a specific spell and work your way up the class hierarchy to see how the various buffs and debuffs are combined.

To see general mechanics, an inspection of sc_action.cpp is a good place to start. The sc_spell.cpp and sc_attack.cpp provide unique replacements to certain action_t methods in order to handle the different way in which spells (two-roll) and attacks (attack table) are resolved.

Out of all the class/spec combos, Priest/Shadow is certainly the most well tested..... and so also the most trusted. I'm not saying it is bug-free, but at least I am able to verify BC-level support against WWS reports.

I used to have an option to cancel at the 2nd tick provided that a higher dps spell just came off cooldown....... but with the new coeff change and the added ability to crit, I assumed that it just wasn't worth the complication. Hmm..... I have an idea for a cleaner implementation..... I'll put that back in.

It looks like there were some changes to deep-Disc that I missed. I'll put those in shortly. Modeling Reflective shield is easy because modeling some virtual incoming damage is easy. The difficulty will be creating something reasonably easy to specify: How much damage? Pulsed on intervals or direct? Need to support cooldowns, ie no damage for time X, followed by some amount of damage for time Y.

EDIT:
Fair enough.... I'll go over your post more carefully. Perhaps it will lead to a bug fix in my program! As to "largely uncommented"..... You're breaking my heart. 90% of the time, the need for comments represents a flawed design and/or a poor implementation. If the code is not easily understandable then I have failed one of my major objectives.

This statement makes me wonder how much professional programming you have done, if any. Good documentation is crucial for code readability, especially when the reader is not the author and/or has not worked on said code for a long period of time.

Edit: Read some of the code, it is pretty straightforward. I still stick to my original statement however.

Ouch!

If there are portions of the simulator that you honestly feel are difficult to understand, please identify them and I will attempt to improve it. I'm quite serious. I welcome criticism. There is 18k lines of code and I've only implemented half the classes..... I'm hoping to get some talented help, especially at the interface level.

I would agree with your assertion that documentation is helpful..... even essential. My particular pet-peeve has to do with inline code comments.

Sometimes the complexity of a portion of code is something you have no control over due to critical performance issues or simply reliance upon a poorly designed API. In these (rare if you're careful) cases, a block comment can be very useful.

However, it has been my experience that most comments provide very very little extra information that cannot be encoded in meaningful variable/function names and good code structure. Comments are not "free money". They add more noise to the screen and bloat the code such that the flow of the reader's eye is interrupted, obscuring enclosures, and reducing the amount of function you can fit on one screen.

I've had to re-train many many green-behind-the-ears college graduates. Every time they add a comment I make them go through the exercise of explaining why it is necessary..... and at the end of that exercise they more often than not go back and change the code.

The comments that truly drive me nuts are of the form "I am eating an apple" and "Now I shall defecate in the toilet". You don't need to tell me you're eating an apple.... I can -see- it. And you don't need to tell me you're in the crapper.... I can -smell- it.

Agreed.

Anyway, I looked at your numbers and I don't understand how you get to your final scaling conclusion (the D/S and H/S = A+B*X numbers). Can you flesh that math out a bit?

Independant of that, I took your scaling numbers and plugged them into my own spreadsheet. I took a fixed casting time of 1350s (it fits both rotations well) and then found the number of casts per spell, translated that to a total damage done. D/S won outright, so I think something may be wrong in one of our time allocation methods. I tried my best to follow the base assumptions of no crit effects and 0 haste.

Yes, a 22 minute fight is excessive. Divide the total number of casts by 4 for both sides if the time window is a problem (5.5min fight).

For reference, I used:
Spell - Casts / Time Spent casting / % CastTime

D/S
SW:P - 1 / 1.5 / 0.1%
VT - 90 / 135s / 10%
MB - 180 / 270s / 20%
SWD - 112 / 168s / 12.5%
MF - (1350 - 1.5 - 270 - 168) = 258 / 774s / 57.5% * Rounded Down

** Yes, I know they don't add to 100%, SW:P taking 0.111~% kinda messes that up.

H/S
SW:P - 75 / 112.5s / 8.5%
VT - 90 / 135s / 10%
MB - 180 / 270s / 20%
HF - 135 / 270s / 20%
SWD - 112 / 168s / 12.5%
S - (1350 - 112.5 - 135 - 270 - 270 - 168) = 198 / 396s / 29% * Rounded Up

I then multiplied the number of casts by the Base + Dmg*Scale and came to the following results:
@ 0 SD
D/S - 1919435 - 748dps
H/S - 984959 - 729dps

@1000 SD
D/S - 1837070 - 1360dps
H/S - 1635753 - 1211dps

@2000 SD
D/S - 2663705 - 1973dps
H/S - 2286547 - 1693dps


My sanity check was D/S @1600 +dmg, which came to 1728dps, which is in the ballpark for current D/S builds (although using different mechanics, etc).

Anyway, using the scaling numbers presented in your post, I came to the opposite conclusion. The only obvious discrepancy I could think of would be in the time allocated to casting each spell.

EDIT:
Did not see the 2nd post with the updated spec. Will input that once time allows.

EDIT2:
5/17/49 added

SWP - 1 / 1.5s / .11%
SWD - 112 / 168s / 12.5%
MB - 180 / 270s / 20%
VT - 90 / 135s / 10%
HF - 135 / 270s / 20%
MF - 75 / 112.5s / 8%
S - 198 / 396s / 29%

@ 0 = 747dps
@ 1000 = 1257dps
@ 2000 = 1767dps

Still below the D/S build from what I can tell.

You're attacking this backwards. When you get a fault, you start by eliminating those possibilities that are easiest to eliminate.

We'd likely start with the settings on the program - I noted spell hit issues above, and there's also the fact that a Shadow Word: Death glyph is used (Shadow Word: Pain is used as well, but is likely irrelevent due to auto-refresh) which I didn't account for.

We'd then proceed to the assumptions I made. I made no pretense that I was generating 'real' dps. So I'd expect a significant discrepancy between the dps for my various builds and the dps generated by the program - my expectation would only be that the ratio between the builds for the various methods would be relatively similar.

Only once we've eliminated the simple explanations do we proceed to validate the program itself - clearly the most difficult task. And, frankly, a pretty unnecessary one. If we haven't found the issue by the time we've completed the above two steps, we're going to give up. Unless you're planning on writing some checks, whatever bugs exist in the program will ultimately be found when people start comparing WWS reports against expected values from the program - and not by reviewing the code. We know it works for BC and, frankly, it isn't worth the effort to make sure it works perfectly for some bizarro talent comparison in an interim beta build of WotLK.

This is mainly a product of a radical ramp-up on Reflective Shield scaling. In BC, Reflective Shield scale at 11.5% coefficient/sec. In WotLK, it scales at 65.06%/second. While these numbers are somewhat illusionary because you can't actually spam-cast PW:S, it does make Reflective Shield one of the heaviest-hitting "nukes" in the Priest arsenel before considering all those raid buffs/debuffs that will inevitably have no impact on how dangerous your Reflective Shield is.

I suspect you're confusing implementation comments with design comments. An implementation comment would look like:

if (a == b) {b = a}; // If A and B are equal, set B equal to A

This is obviously pretty pointless (yet surprisingly common). If someone needs that level of explanation, they probably shouldn't be reading the code in the first place. A design comment is something more akin to:

int list::sort (int iterations) // Perform the given number of iterations of a non-recursive heap sort on the list, returning a completion code.
{...};

Much of the design of your program you don't need to explicitly call out because anyone reading it is probably already familiar with the basics of WoW. You don't need to reiterate how to calculate spell coefficients or go into detail on how various mechanics work because anyone reading your code presumably already knows.
But there are many, many issues where design does matter and is up to programmer choice. For example, let's say we want to ask whether to refresh Vampiric Touch earlier at the expense of wasting some Shadow Word: Death cooldown time due to an expiring Improved Spirit Tap proc. Your code resolves this question somehow. But I have no idea how - or even where to look - because there's no design documentation lighting the way.

More importantly, when I review the code, I have to redo all the work you put into thinking up what could happen because you never listed all these scenarios. Sure, I can come up with the above oddity. But you already thought about that - and a hundred other scenarios that I probably won't think about in the process of writing the code. Without design documentation, I can't follow that critical thought path.

In any case, I doubt that we'll ultimately be seeing Holy/Shadow hybrids as the preferred dps spec for raiding Priests - something will change in the interim. I started with a curiosity about whether the significantly upgraded Holy Fire could compensate for the loss of some Shadow talents given that the amount of specifically Shadow damage dealt was no longer relevant, not seeking to prove either side of the argument in particular. The fact that I ended up with a result that at first said damage was comparable (if hideously mana inefficient) and then a revised build indicated even more damage was fascinating.

Side note: I can't seem to get the tool to cast Mind Flay as little as possible, but still often enough to refresh Shadow Word: Pain. I either end up spamming Mind Flay or spamming Smite, and can't get the quirky "Mind Flay once every 18 seconds" rotation.

There is much truth there..... but I have the good fortune of working with very talented people so I place a considerable value in peer reviews.

There were a number of reasons I specified in my previous post. The most dramatic ones being CoE, Haste Rating, and the passive Haste from Swift Ret and Wrath of Air.

I think we are at least near the same page if not actually on it..... I understand your point even if I disagree with your particular example.

The intent of sc_action.cpp was to provide not only a functional framework for all attacks and spells but also provide the documentation of how an action unfolds. Making the secondary purpose well known (beyond the fact that it is the root super-class) would be valuable documentation.

My primary purpose in creating SimulationCraft was to help curious people like yourself.

The action list is a simple priority list with conditionals that return ready=true/false. Mind Flay is only limited by mana availability. I'll need to add a special conditional that you can call out that will only return true if SWP is going to shortly expire.

Look at the Frost Mage for some more interesting action lists.

I've chopped up your post a bit, but hopefully you can still follow.

I allocated 0% casting to SW:P in a D/S build. While a trifle unrealistic (it's unlikely you'd be able to perfectly time your cast 1.5s before the fight started), it let me treat SW:P as a constant addition to all other dps. Basically, I calculated how much dps SW:P did and added it to the entire cycle for D/S.

For actually casting it, I had a result of 1.5 / 18 = 8.33%. Close enough.

For Mind Blast, I had a very different result. 1.5 / 5.5 = 27.27%. 20% = 1.5 / 7.5. While the conflicting cooldown/refresh issue I discussed would cause the cycle to change, I'm not sure how you could calculate Mind Blast's cycle as being radically different while everything else seemed to match.

For Holy Fire, I had 1.5 / 10 = 15%. Did you include Divine Fury (0.5s less casting time) in your calculations? That would probably be the big issue, since Smite isn't really all that much better than Mind Flay and is enormously less efficient. 20% of casting time at 75% of the actual dps of Holy Fire would make a big dent.

In terms of comparison to the tool, I have some thoughts:
1. Holy does get less return on crit since you're recasting SW:P and Holy Fire has a lower-than-normal return on crit (although the 5/17/49 build I later shifted to addressed much of this).

2. Haste breakpoints can cause wild swings in damage. If you're just chain-casting Fireball, haste is pretty much the same as "X% more damage". When you're interleaving all sorts of cooldowns and refresh rates, shifting even minor amounts of haste can cause wild swings in damage due to being able to 'fit' the spells together differently. More to the point, two different casting structures have dramatically different haste breakpoints.

3. Spellpower discrepancies. I handwaved these away, but the numbers I originally posted were so close that it probably does bridge the gap for most levels of gear.

4. Spell hit discrepancies. I already mentioned this, but Shadow gets +3% more spell hit than Holy does in any build. If the talent only increased spell hit, I'd say it would be worth skipping, but the cost reduction - although not part of this analysis - is probably worthwhile.

5. Curse of the Elements. As noted in the response, not taking this into account was probably a huge deal since it provides a 10% boost to Shadow but not Holy. I treated basically all non-Priest effects as neutral between the two specs (or close to it), but this isn't remotely neutral. It does strike me as odd that they specifically left Holy damage out of all of these spells. I guess they just don't like Paladins.

Huh? 1/.97 = 3.1% to all spell damage. And that's not accounting for the little extra time we all spend fumbling around after a SWP resist, or worse, a VT resist, or any number of mechanics that make resists have a worse effect than (1-resist%)(DPS) shows.

The new Misery (patch 8905) at 3/3:

Your Shadow Word: Pain, Mind Flay and Vampiric Touch spells
also increase the chance for harmful spells to hit by 3%, and
increases the damage of your Mind Blast, Mind Flay and Mind
Sear spells by an amount equal to 15% of your spell power.


I'm still not sure exactly what they mean, but it looks okay anyway.