# Java-based Gear, Gem and Reforge Optimizer

### #41

Posted 03 March 2011 - 04:39 PM

New video to show the changes is also up at YouTube - WoW Gear Optimizer - v1.6.3 Multithreading! (HD)

### #42

Posted 12 March 2011 - 04:53 AM

items such as sinertra neck which is technicallly BIS for dps but has tank stats arent detected

### #43

Posted 12 March 2011 - 07:25 PM

### #44

Posted 13 March 2011 - 02:58 PM

I need your help adding more TotFW heroic items. Please post me your armory link if you have one that isn't currently available.

### #45

Posted 05 April 2011 - 07:06 AM

If you have any spec that you'd like to include feel free to post it here and I'll add it.

### #46

Posted 05 April 2011 - 10:57 AM

Required input would be value before softcap, after softcap and softcap rating.

### #47

Posted 06 April 2011 - 09:29 AM

Can you add an option to put in a breakpoint for an additional stat (aka softcap)?

Required input would be value before softcap, after softcap and softcap rating.

Sadly I'm afraid that it isn't. Ignoring for a second how cumbersome it would be to have at least 1.5 times more stat input boxes and cap boxes for the average user, it just isn't feasible from a computational point of view.

The reason is this. Assume a very basic scenario in which, for each slot, you have five valid pieces of gear (consider that the same item, with the same gems, but different reforges, is in fact two items, etc).

Let's assume that none of those items is discarded before firing out the computation that would test each obtainable gear combination, evaluate it (even applying soft caps if you wish), and return the best mix.

That would turn out as 762.939.453.125 gear combinations that must be tested (5^17).

It's pretty obvious then that unnecessary items must be pruned before firing the computation itself.

How? By assigning an actual dps value to each of those items, and then proceed to apply some smart reduction mechanisms.

Hit and expertise are considered "cappable stats", therefore the dps value of an item that has at least one of those is considered an upper bound value, not a fixed one.

Some simple considerations would be, if two items, A and B, dont have cappable stats, remove the one with the lowest dps value.

Another example would be, if item A is worth X dps, and item B is worth Y dps, and X>Y, then B is useless iff B has more of the cappable stat than A does.

Having many more stats go from the semantic of fixed value to floating value would remove even more chances of item pruning and make the optimization unfeasable.

### #48

Posted 07 April 2011 - 12:07 AM

Can you add an option to put in a breakpoint for an additional stat (aka softcap)?

Required input would be value before softcap, after softcap and softcap rating.

Like necro_potence points out - you need to settle for an approximate algorithm in order to do this type of optimization.

Mr. Robot (Mr. Robot - World of Warcraft) can do such optimizations. It uses an approximate optimization algorithm that has been continuously refined over the last couple of months. The results are almost instant, but surprisingly accurate. I have compared our results extensively to tools that iterate through all possibilities, and we are now within an extremely low margin of error of THE optimal result. Usually 0.25% or less. For many classes and specs, you will see identical results to a tool like this Java-based optimizer.

For classes with relevant soft caps... It is actually

**necessary**to take into account soft caps to find the optimal solution. Without support for these types of mechanics, this java-based tool is effectively using an exact method to find an approximate solution. For example, you cannot optimize a frost mage unless you can take into account the 33.5% crit soft cap. You cannot optimize a tank class unless you can calculate diminishing returns and dynamically modify the stat weights. You cannot optimize a shadow priest unless the tool knows that hit=spirit.

An "exact" tool like this is useful for a number of classes, but it is limited in what it can do. It is really only "definitive" for a very specific set of situations (the simpler classes to gear). It still works impressively fast for what it is, though. I would personally like you to list out the specs that this tool actually works correctly for, so that users understand when they can and cannot use it to achieve optimal results.

Follow Mr. Robot on Twitter or Facebook for updates, feature releases, bug fixes.

Mr. Robot is now available on your Android and iPhone

### #49

Posted 07 April 2011 - 08:52 AM

It's not even correct to "override" my haste by either removing or adding some, in case my profile is right before or right after an haste softcap and I wish to compute the other side of the peak, because having more or less haste in a real situation would mean a change to the amounts of the other stats too.

You'd not even be done with a pre and post value. For example, a stat might have multiple peaks. Lets assume that haste till rating X-1 is worth 2, at X (and X only), it is worth 4 because it is adding another whole tick of a dot, at X+1 its value starts to diminish again till Y-1, at Y (and Y only) it is worth 5 (because it adds another extra tick, which is worth more than the previous extra tick because other spells scale with these ticks). What I'm saying is, if you want to be truly truly accurate with weights, a pre and post value is just a bad solution, because it isn't really more accurate in many cases, just slower. To be truly accurate, you'd need as much as 4-5 stat weight boxes and corresponding caps (in some cases at least).

Besides, this whole thing is based on an approximation of scaling values. Ignore for a second the whole caps issue. What you do is compute your weights for the mix of stats that you start from, and use those to test a lot of different mixes. This

**is**approximating to the very core of it, because ideally, every time you swap something you should recompute the weights. And yes, one small pure gem vs non pure gem plus set bonus might not unbalance the proportion between the stat weights, but different mixes of items with totally different reforges will.

Lets just say that, given that there can never be an approximation free solution to the issue in the total sense of the word, I'm happy to know that for the given input data (flawled to its very core, but there is not much we can do about it) the output is the optimal solution.

### #50

Posted 07 April 2011 - 10:17 AM

As pointed out, some stats for some classes have multiple peaks/breakpoints. However, given the gear you have it is highly unlikely that you are able to encounter two of them just by swapping/reforging/regemming. Most breakpoints are at least two digit-% apart, meaning you need to get more than 1500 haste just by gear optimization, which I find very unlikely to be possible given the hit constraint.

Apart from that, I tried Mr. Robot and it seems to do a decent job with the default stat weights. I will definitely try with more depth later.

Just for background info: I wanted to optimize my frost mage, which I normally did with Rawr. However, currently Rawr has a problem with IL dps contribution and therefore undervalues mastery quite a lot.

### #51

Posted 07 April 2011 - 01:43 PM

My analysis has shown that, while in theory stat weights shift with every single change in gear, in practice the shifts are small enough that we CAN optimize gear across a broader range with "coarse" stat breakpoints such as one major soft cap for a stat. (If you go to our home page, you will see a list of articles I have written for different classes which shows this.) The homogenization of stats in Cataclysm has certainly helped to make this technique more effective than previously.

Necro, I am happy to see you acknowledging that everything we are doing with gear optimization is inherently approximate. Simply ignoring stat breakpoints because they theoretically shift too often to find a "truly" optimal solution is a sub-optimal approach! Allowing one break point is certainly much more optimal than none.

An example: Using your haste and DoT ticks example applied to warlocks... you cannot use a gear optimization tool based on stat weights like yours and Mr. Robot to find a BiS gear set for a destruction warlock wearing mostly t11 heroic gear unless you can tell the tool to favor the 7th immolate tick (30% haste). We have recently added another set of preset stat weights on our site to take into account this situation because it is a very significant break point for destruction warlocks. It is even worth sacrificing some hit rating to reach it. Just this one "soft cap" is adequate to force an optimizer to find a very near-optimal solution. Without the soft cap, the solution is significantly less optimal.

Follow Mr. Robot on Twitter or Facebook for updates, feature releases, bug fixes.

Mr. Robot is now available on your Android and iPhone

### #52

Posted 08 April 2011 - 11:28 AM

An example: Using your haste and DoT ticks example applied to warlocks... you cannot use a gear optimization tool based on stat weights like yours and Mr. Robot to find a BiS gear set for a destruction warlock wearing mostly t11 heroic gear unless you can tell the tool to favor the 7th immolate tick (30% haste). We have recently added another set of preset stat weights on our site to take into account this situation because it is a very significant break point for destruction warlocks. It is even worth sacrificing some hit rating to reach it. Just this one "soft cap" is adequate to force an optimizer to find a very near-optimal solution. Without the soft cap, the solution is significantly less optimal.

The fact is that if you only have 1 haste scaling value input-box (filled with the pre-softcap haste weight), and no haste softcap, you will still compute a set that favors the 7th immolate tick.

If an approximation will occur (which it might not at all), it will only start to occur after that breakpoint/softcap/7th immolate tick, therefore the major dps increasing situation (7th tick) will still be met.

Moreover, the approximation will only occur after that 7th immolate tick iff the post 7th tick haste scaling value drops enough to become worse than another stat, let's say crit, which might or might not be the case.

Lastly, the actual amount of "loss" will be the delta between crit.weight and post-cap-haste.weight times the haste rating points in excess of said cap, which should only be a handfull, because to reach that haste level, you would need to stack all haste you could anyway.

### #53

Posted 08 April 2011 - 08:36 PM

At the 372+ item level with currently available gear, once you pick items based on weights with this priority, and then optimize that set to reach the hit cap and then optimize haste, you end up slightly below 30%. If you were to simply weight haste above hit, you would end up with a set with plenty of haste for that extra tick, bit the resulting loss in hit offsets the gain.

You really want to *just* hit 30% haste and take away as little hit as possible. This can only be achieved with an optimizer using a "soft cap" or stat breakpoint.

And this is just ONE case! Look at a class like rogues who have multiple breakpoints for hit. Your current tool is inadequate to optimize this more complex class definitively.

Follow Mr. Robot on Twitter or Facebook for updates, feature releases, bug fixes.

Mr. Robot is now available on your Android and iPhone

### #54

Posted 09 April 2011 - 10:48 AM

Look at a class like rogues who have multiple breakpoints for hit. Your current tool is inadequate to optimize this more complex class definitively.

Won't a tool with support for just one softcap be (almost) as inadeguate? I mean in a real case scenario, not on paper (kinda like the whole I change a gem -> I need to recompute weights).

Could you also provide to me these 372 warlock scaling values (where haste pre cap > hit > haste post cap) so that I could do some test runs, and the way you used to compute them?

There is no intuitive way to compute those with simc or the warlock spreadsheet, nor any "pre-set" collection of those around in the whole warlock forum section. What I'm saying is, I might agree that it would be more accurate and all, but if it's just you and another handful of top skilled ej users that know how to find out those values, while 99.9% of the users will never use the pre and post softcap values because they have no clue about how to compute them, we end up talking "on paper" issues again.

Judging by the sheer percentage of users that are using pre-set scales rathen then their own simc scales, I'd bet that more than 75% of the optimizer users don't have any clue about how to run simcraft or a spreadsheet at all.

Judging by the fact that 1% of the total users are inserting tier/trinket weights (which can be computed with simcraft rather easily, albeit not very intuitively) when they would be relevant, I'd estimate a <1% usage for the softcap haste box.

### #55

Posted 09 April 2011 - 02:41 PM

Our stat weights for warlocks are on the site if you click on destruction and then choose the presets tab in the stat weight section. Click the stat weight editor to see the more advanced view with the information you care about.

I agree that only a few hardcore theorycrafters will try/be able to figure out these complicated weights. That is why we provide defaults and presets on our site. It brings the specialized knowledge to more players. I have shown for many classes now that it is not necessary to have stat weights customized to your character to achieve near-optimal results. For those who do not want to run a simulator, these values are adequate. I would argue the values are adequate for anyone, but that is a different discussion.

Follow Mr. Robot on Twitter or Facebook for updates, feature releases, bug fixes.

Mr. Robot is now available on your Android and iPhone

### #56

Posted 25 April 2011 - 07:47 PM

Virtually all of the modeling being done currently, including this tool (which I use myself), relies on the convention of scaling constants for ratings. Unfortunately, certain aspects of the current game environment behave in markedly nonlinear manners, and so introduce errors when mapped to a linear relationship. Haste is the usual suspect, although certain class features can result in crit rating behaving in this manner over some (not necessarily achievable) ranges. Put more simply: you can construct gear sets for many classes (hunter, for example) such that haste is alternatively the best stat of [crit, haste, mastery], the medial stat, or the worst option of the three. Reforging based on these incorrectly-assumed linear weights will result in drastically different outcomes. In some cases, these errors may be profound. Softcaps do not resolve this problem; while the value of rogue hit may be a series of breakpoints (softcaps) connected by linear segments (and I have no assurance that is true), haste for many, if not all, classes, flatly lacks a linear relationship to dps.

The

**optimized**solution for reforging is to represent dps for a character as an

*n*-manifold, whose dimensionality is determined by the number of independently varying statistics. Taking hunter as an example, when evaluating reforging only -- that is, determining the optimal reforging for a set of gear without alternatives -- potential dps is a 5-manifold determined by agility, crit, haste, hit, and mastery, although maximizing agility before evaluating reforging /regemming / re-enchanting is unlikely to alter the outcome and would allow a reduction in dimensionality. When evaluating gear options, considering agility is unavoidable. Weapon damage is also a factor if weapon selection is to be considered, leading to a 6-manifold. Other classes, such as rogues, may have additional dimensionality (expertise, secondary weapon). By representing the relationship between ratings and dps as an

*n*-manifold, the illusion of linearity is discarded. There are no "scaling factors" and the best gear / reforging solution is the one which produces, from the set of available options, a local maximum.

This "solution" has several problems, however. First, it depends on an accurate and robust simulator to determine expected dps for each set of input points. Second, it cannot directly incorporate tier set bonuses, as those alter the underlying system used to generate each manifold; comparison of a 4T11 gear build versus a 3T11 gear build would require the generation of two manifolds, determination of the respective local maxima, and comparison of the computed values. But third and most importantly, brute force generation of these manifolds very likely constitutes numerically intensive computing.

I believe that shortcuts exist that will allow the "interesting" sections of these manifolds to be computed in something resembling reasonable time, and am working on a preliminary model, but this is a nontrivial directional statistics problem. If someone with a better background than myself in directional statistics and the properties of non-smooth

*n*-manifolds would like to provide input, I wouldn't be sad about it.

### #57

Posted 26 April 2011 - 03:17 PM

I agree that a mathematically ideal solution is going to need more than some "soft cap" breakpoints. That is sort of the main point to my posts in this thread... the site I maintain does not make any claims to be mathematically ideal. We claim to be an approximation with a high level of accuracy. Incorporating a number of the most important stat breakpoints such as hit soft caps allows our approximation to approach the ideal mathematical solution in an extremely efficient manner.

This java-based optimizer is claiming to solve for a definitive solution, but it is not able to do so for many (most?) classes because of the complexity that you are pointing out. Our approximate solution is actually significantly closer to the ideal mathematical solution than this java-based optimizer because we do allow for all the applicable major soft caps.

Follow Mr. Robot on Twitter or Facebook for updates, feature releases, bug fixes.

Mr. Robot is now available on your Android and iPhone

### #58

Posted 29 April 2011 - 07:43 AM

Quoting this post:

The haste thresholds for DoTs (including Corruption) provide a sudden jump in DPET (Damage Per Effort Time) of the spell, not in their DPS (Damage Per Second).

Haste effects the DPS of the DoT itself linearly, i.e. 25% Haste causes the DoT to deal 125% as much DPS it did with 0% Haste.....the haste threshold doesn't have any special consequence for the DPS of the DoT itself.

If DPET is what takes a very big hit by getting over a softcap, and DPS does not, there is hardly any imprecision in the current implementation. DPET changes the priority list of the spell casts, not which item combo is better.

### #59

Posted 29 April 2011 - 07:47 AM

### #60

Posted 29 April 2011 - 07:05 PM

I'm not sure where all the fuzz about these haste thresholds is coming from.

Quoting this post:

If DPET is what takes a very big hit by getting over a softcap, and DPS does not, there is hardly any imprecision in the current implementation. DPET changes the priority list of the spell casts, not which item combo is better.

This depends highly on which spec you are looking at. If you are talking about an Affliction Warlock, you are right that haste thresholds don't matter much.

Now, take the example of a destruction warlock in t11 heroic gear. Adjusting the optimization to prioritize reaching the 30% haste threshold where you gain another tick on Immolate is worth doing, even at the cost of hit rating, because there is a substantial jump in DPS due to the mechanics of conflag. So, for this spec, your current implementation will always produce substantially sub-optimal setups at that gear level.

Other classes with significant haste soft caps are most healers. Damage-dealing DoTs do X amount of damage over Y seconds. Healing HoTs to X amount of healing every Y seconds. So, for a DoT, when you gain an extra tick, the total damage of the DoT remains the same - it is just redistributed over all the ticks. The slight DPS "jump" is due to the fact that when just over a threshold you save a little bit of time by refreshing less often, allowing a few more filler spells. For a HoT, the healing done by each tick remains constant, so when you achieve enough haste for an extra tick, you get another tick at the full value. This increases the healing/execute time substantially.

There are numerous haste and hit soft caps that are very meaningful in the game right now.

I'm not ragging on you just for the sake of it - I just take issue with the way you advertise your tool as "definitive" and making no compromises... when it is not taking into account some very important game mechanics. Your method IS a compromise, since the method you are using is too computationally intensive to take into account all of the applicable mechanics in a reasonable amount of time. Your optimization algorithm works great for specific cases: specs with no significant discontinuity in stat scaling other than the hard hit and expertise caps.

Follow Mr. Robot on Twitter or Facebook for updates, feature releases, bug fixes.

Mr. Robot is now available on your Android and iPhone

#### 0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users