Malleus, that's correct. At 245 resistance (what Melaar would have with the LW Bracer enchant, cloak enchant, head enchant and totem) you would expect to see a minimum resist of 20% and an average resist of 33%. Instead, if you hover over the tooltip for the resistance, you get a minimum of 30% and an average of 43%. Plus the survivability for NR appears to be off by the same factor; it looks like basically it's health * potp * NR average, which is wrong for the same reasons as above.

Would it be feasible for the Additional requirements section of the optimizer to include armor penetration? I know it's going away in the next expansion but that's still a ways away, and with feral cats getting a lot of mileage out of it I'm looking at how much I can get and at what cost in trade-offs.

I've been expecting Rawr to switch to recommending Arpen gems any time now when I get upgrades, but it still doesn't do it, even with custom epic gemsets including it and marking it available individually. Getting a lot of Deadly Ametrine recommendations but I think that's as much socket bonus as anything.

I'm not quite sure if this is the right place for suggestions, but it would a nice feature if there was a way to manually enter sep values derived from other sources (like simcraft, different sheets or even own calculations) because the item comparison part of Rawr with all the filters, bars and options etc. could be still incredible usefull even when the calculation part of the module isn't finished like in case of Wlocks (or someone just want to use different calculation tools).

It's impossible. Rawr does not use stat weightings at all in its core calculations.

Which version of Rawr are you using? The current version is updated for 3.2.2, so the ArP Nerf might be affecting you. In previous versions of Rawr, the optimizer recommended gemming for ArP in gearsets well below the gear level you're at for me; but now recommends gemming for agi in the same sets.

What does the relative stat values page show? Is agility ranked above ArP or vice versa?

Also, did you try adding ArP gemming templates?

Perhaps he should have re-phrased the request: In place of "sep" say "dps formula whose inputs are relevant stats" instead.

I fully understand that Rawr does not currently accept a "dps formula". However, my naive understanding of the app gave me the impression that the Optimizer was reasonably isolated from the individual modules. The modules themselves are the black-box providing the "dps formula" given a set of talents/glyphs/gear. To be clear, I'm not actually making a request but rather trying to satisfy my curiosity.

Of course, the primary word in that paragraph is "naive".......

Optimizer is indeed isolated from the models in that it they're a black-box to it, yes. It can't do anything on its own, it just tries tons of inputs to the black box, to try to find the best output. It doesn't do any calculations on its own.

There appear to be some inaccuracies with stat calculations in the protection paladin model. For example, my ingame and armory read:

2,457 stamina
38.93% block chance without holy shield
68.93% block chance with holy shield
2,789 block value

After doing a straight import from armory to rawr with no buffs enabled apart from toughness from mining, and setting target level to 80, rawr presents:

2,450 stamina
38.97% block chance without holy shield
54.66% block chance with holy shield
2,795 block value

It appears that rawr might be applying diminishing returns to block rating - when I use a naked character enabling holy shield gives 30% block as it ought to.

Rawr is using information from patch 3.2.2. So there could be discrepencies because of that. What I would suggest is to put on 1 item at a time and compare it RAWR. Also make sure your target level is set to lvl 80. Most models are set to default to lvl 83 which does diminish some stats.

Block percentage does not diminish per mob level, nor does 3.2.2 include any changes to block mechanics or Holy Shield. Also, I'm fairly certain that the ProtPaladin module does not include the changes to Ardent Defender from the last patch, and thus is still strongly flawed for gear comparisons.

Download - Rawr - Release: Rawr 2.2.16

Tour of Rawr Movie! - YouTube - Tour of Rawr

Recent Changes:
v2.2.16.0
- Switched back to 3.2 ArPen rating conversion, since 3.2.2 still looks to be a bit out. Will release a new version as soon as 3.2.2 actually comes out.
- Rawr.Warlock: Crashing fixed! Joy! Sorry that took so long.
- Rawr.DPSWarr: Fixed a bug where dps values would come up as NaN in certain cituations. Improvements to Boss handling features. Updated default gemming templates.
- Rawr.Mage: Update PTR mode to latest 3.2.2 mechanics. Fix for resilience relevancy.
- Rawr.ProtWarr: Added support for 2T9, and a couple more trinkets. Added threat/damage from Deep Wouds
- Rawr.TankDK: Fix for blood threat numbers being way off.
- Rawr.DPSDK: Added support for 3.2.2 PTR changes.
- Rawr.HolyPriest: Added support for 2T9 and 4T9.
- Rawr.ShadowPriest: Added support for 2T9 and 4T9. Added 3.2.2 changes.
- Rawr.Elemental: Fix for T9 bonuses.

Download - Rawr - Release: Rawr 2.2.17

Tour of Rawr Movie! - YouTube - Tour of Rawr

Recent Changes:
v2.2.17.0
- Fix for crashing bugs in Rawr.TankDK and Rawr.ProtWarr.
- Fix for not being able to load priest files saved with previous verisons of Rawr.
- Rawr.DPSWarr: Added support for Execute spam under 20%. Improved performance. Added a comparison chart for ability DPS/damage. Fix for 2T8 calculations.
- Rawr.Warlock: Tons of updates to spell damage and talent calculations. Should be more more representitive of actual results now.
- Rawr.Tree: Fix for T9 set bonuses.
- Rawr.TankDK: No longer crashes. Joy!
- Rawr.Enhance: Fixes for EnhSim export. Updated default gemming templates.
- Rawr.ProtWarr: Support for new 3.2.2 Critical Block. Fix for crash on loading protection warriors from the Armory.
- Rawr.Elemental: Fix for T9 bonuses. Fix for Flameshock periodic damage calculations.

I have been looking at options for a mates warrior, he kept telling me he would get errors opening old version of his gear in the new version and would have to reload from armory and start from scratch.
I am now getting an error trying to open the file I saved after loading it from armory yesterday with the 2.16 version, he is now logged out in his tank spec and gear now so I am stuck.

The following is the error it gives me, after I shut it down and restart it if I try and open the character again it opens but the lists show the Paladin and Deathknight pieces as well as the Warrior ones.

Will yell at the warrior devs to make sure they maintain backwards compatibility...

You're missing the point though. Sometimes I want to use my own item weights, and it seems like it would be pretty trivial to set that up in Rawr. Just make a "DPS model" which consists of (A*spellpower + B*crit + C*haste), etc., where all the coefficients are user-specified. Call it Model "Custom" or somesuch. This would let me make use of the powerful Optimizer functionality even when I want to tinker with some of my own numbers.

I think the idea is that if you're replacing the model calculations the optimizer accepts with simple stat weights, it sort of defeats the purpose of the optimizer. I don't really see any advantage over using the various "loot rank" tools out there (on Wowhead, etc.) if all one is doing is scoring gear based on its stat "rankings"... with the possible exception of looking for the most efficient way to be just hit capped with those weights, or something. Still, that's such a simple task that it doesn't seem worth developing a Rawr model to me when (again) many websites already have tools to list gear based on stat weights. I'm guessing you're not going to find too many interested developers, leaving aside whether such a model is outside the Rawr "philosophy" or not.

There's a single case I can think of - that you don't trust the usual model, whether it's because it's incomplete or you prefer a different model that the developer chose not to implement. For a while, Rawr and WrathCalcs had different enough implementations that they could get different results. I'd never have used weights myself, but I can understand why people would.

No, Rawr could not support this, and I would be strongly opposed to anyone trying to make it do so.

Instead, you should ask yourself why you want to use your own weights, and solve the problem that causes that.



Looks like they messed with the built in filtering for DPSWarr, and screwed it up somehow. Will try to get them to fix it for the next version. This is just in DPSWarr, right?

Oops, delete me! Sorry.

While in the end I will defer to your expertise, I must also admit that after glancing at Rawr.Elemental I can't help but think that it would be pretty easy for me to hack that in the direction Arawethion was pointing.

However, it's your party, so you get to set the rules! I've certainly exercised my prerogative in SimulationCraft from time to time. And anyway, all joking aside, I agree with your position: Rawr.Custom is not worth the investment.

To be clear: While stat weights are regularly abused, I also believe that they can be effectively employed to make gearing decisions. Stat weights are merely the slopes of the DPS surface at a given point P1. Consider a point P2: How far from P1 can we place P2 before the slopes start to break down? If the gear choice is infinite then you are piss out of luck. If the gear choice is limited, even re-gemming may not move P2 far enough to make the "stale" stat weights produce a sub-par result.

This is the crux of the matter and why I believe you are correct to resist this direction. Development resource is finite. Just because something -can- be done does not mean it -should- be done.

There are two reasons (that I can think of) for wanting to use your own weights:

(1) You believe a particular Rawr module mechanic is flawed. But.... Why not invest the time making the module better and serve the entire community?

(2) You trust the Rawr module mechanics in the context of the scenario for which they were designed, but you wish to change the scenario slightly. For example, perhaps you are a caster who is suffering during movement fights, forced to frequently cancel casts and you want to weight Haste a little heavier. Perhaps you are having difficulty reliably burning down must-be-killed-now adds and want to weight Crit a little lighter to reduce RNG factors. etc etc

Rawr already provides optimization controls in the form of constraints (ie: keep my avoidance at X% etc). Providing stat-specific weights that work in concert with (not in place of) existing Rawr modules may allow users to perform custom gear optimization for their unique perspective. These weights would, of course, all default to 1.0. Increasing or decreasing these weights merely adjusts the signature of a gear set prior to passing it to the module for evaluation.

I well understand (and agree with) the root of your dislike for stat weights. They have been woefully abused, and the scale factors published in our SampleOutput wiki pages have perhaps perpetuated the problem even further. However..... Stat-weights in the form of "hints" may provide some useful functionality to an already exceptional tool without perverting its guiding principles.

I agree, they make good hints (and that's why Rawr does have a chart that displays them).

(1) I vehemently agree with this. If you think a model is doing it wrong, clearly state why, and work on making it better.

(2) This is the same as (1) to me. If you think there's a situation like you describe that the model doesn't handle, make the model handle it. In the example you describe, add some sort of movement time %, and perhaps a fragmentation system, so that you can logically describe the problem to Rawr, and have Rawr solve it. That is infinitely better to me than just "I keep having to cancel casts to move, so lets bump the haste weight from 1.6 to... Oh, lets se... 1.8 sounds good, sure, lets do that." I'd much rather see something like "I had to move at 17 random times during that fight, and I each time, it took an average of 4sec of movement." as the input, and let it appropriately calculate things from there. Your inputs may still be imprecise, but the user at least understands the imprecision of their inputs in that case.