The multi threading is really awesome. Even unreasonably large potential gear sets (5+ per slot) with every gem possible can be analyzed in under ten minutes on my quad core.

When I was stress testing the performance I noticed an item with a stat set for a gem bonus, but no gem slots, which it refuses to calculate unless it's fixed. Gloves of Smoldering Touch (Ignis-10, gloves)

I think the results page could use a couple of improvements. The graphical display is a little hard to read (the white text/boxes used for prismatic gems/slots on an off-white background is annoying). In any of the result types there doesn't seem to be any indication of what the socket bonus is on each piece, although the Graphical and Plain text outputs clearly show what color each socket is.

Glad you like it. I've tracked down the Nitro Boosts error and that'll be fixed later this evening. In the meantime you should be able to force it to be used by deselecting both of the other foot enchants with Engineering selected. I will include the Relentless weapons in the next update as well.

I've fixed the Ignis gloves error, so that won't be an issue in the future. I'm glad you like the multithreading - there are significant improvements in the gemming methods as well in addition to multiple threads, and that is what results in such drastic improvements in calculation time (along with the aggressive gear trimming).

I agree that the graphical results screen is far from perfect. Perhaps I'll mess around with it at some point to include more information, but I'm wary of crowding the screen too much and making the window absolutely gigantic. Thanks for the feedback regardless - I definitely know that the prismatic text is a bit hard to make out. Including the socket bonus value might not be that difficult to do gracefully and it would add some additional value to the results screen.

Let me know if you have any additional problems. Thanks as always.

Edit 1: New version is up with those fixes. Let me know how it works out.
Edit 2: I fudged something up, hang on momentarily.
Edit 3: Problem fixed - I fat fingered something when messing with item lists that caused a crash. If you downloaded the corrupt version, you can resolve any further issues by deleting the directory "Documents and Settings/All Users/Application Settings/DKOptimize/DK Optimize/2.5.1.0" and all its contents.

Having an issue with the new version. (2.5.1a)

While calculating DW frost, I'd often mark the weapons I don't have a pair of to be unique to avoid the program picking it for both main and off hand slots. This doesn't seem to be working at all now. Further, if I save the items to be specifically main hand, that information gets ignored as well.

Without this ability, using this to calculate DW sets without a matched weapon set is essentially impossible.

I believe I've fixed this. Let me know if the problem persists, but I'm fairly sure that I caught the condition that was resulting in the problem.

Link: http://dkoptimize.googlecode.com/fil...mize_2.5.2.zip

Was trying this out with the latest update, works a lot faster than the 40+ hours it seemed to want to take before. Great idea, and great work. One thing I noticed however is on weapons calculations, it seems like it's over-valuing weapon speed. For instance with unholy 2-hand blood presence stat weights placing [Marrowstrike], [Ironsoul], and [Edge of Ruin] over [Betrayer of Humanity] even though the Betrayer hits harder. In both pawn and lootrank.com Betrayer comes out on top when I plug in the same unholy 2h blood presence stats.

I've looked at these four items and can only come to the conclusion that the program is accurately evaluating the weapons. Betrayer of Humanity comes out a full 160 points or so lower than Edge of Ruin, the highest valued weapon. If you disagree with the weight for 0.1s weapon speed then of course these results don't apply - but I must come to the conclusion that the program is behaving correctly.

Weapon	Score
[Betrayer of Humanity]	10050.15
[Marrowstrike]	10142.8
[Ironsoul]	10194.23
[Edge of Ruin]	10217.3

I did not consider expertise racial for any of the weapons. I was able to duplicate this result in Lootrank. You should note that the Weapon Speed field on Lootrank is a score per 1s speed, whereas the value listed in DK Optimize is ostensibly per 0.1s. When you do the conversion the results are identical. Let me know if that doesn't answer your question.

Edit: I spoke with Kahorie about this issue and will be making some changes to the optimizer in the near future. In the meantime divide weapon speed weights by 10 to get accurate results.

I was unable to find any Tier-9 weights for Blood in the Blood topic post, which hasn't been updated since the end of September. I'm also worried that those weights are slightly out of date at this point, but I was also unsuccessful in contacting the owner of the thread - he / she didn't respond to my PM. As such if someone has weights that are more up to date for Blood and / or include T9 weights, I'd be more than happy to incorporate them into the next version of the Optimizer as default values.

Now then, regarding the weapon speed issue - I've updated the program to handle the value for weapon speed as a value per one second of weapon speed. So, a 3.5 speed weapon will have a value (for speed) of speed_weight * 3.5. Previously this was a value per 1/10th second, which it turns out was incorrect. This has the effect of devaluing weapon speed a bit, but it doesn't have much effect at the high end since most of the weapons are the same speed.

I'm unable to do a test install here at work so please let me know if the new version doesn't install / run correctly for any reason. Here you go:

Link: http://dkoptimize.googlecode.com/fil...mize_2.5.3.zip

As always, let me know if there are any issues and I'll correct them ASAP. Thanks.

There doesn't appear to be any graceful way to use Rigid Dragon's Eyes. The odd hit value (34) can be useful when trying to force hit cap without going too many points over the cap.

Nice upgrade. I'll give you my opinion though. I think the interface would be alot more efficient if the Item Selection section took up most of the screen since after you set up the weight stats and character info you only interact with the item section. I'm applying weight's to the interface based on what sections get used more. The item's section wins. Maybe you could make buttons that bring up the other sections interface and handle it that way. Leave the stat weights and items sections as the main screen, but maybe in plain text list the other settings in a small box somewhere.

There seems to be another issue with the optimizer. For some reason when I use the same gear set, same gems, same race, same spec (for spell hit, expertise, etc.) the stat weights greatly change the outcome time.

I am using the preset 3.3 unholy 4pc set of weights, and it calculates in roughly 20 seconds. Then I simply swap the preset weights to 3.2 unholy 4pc blood presence and it gets to about 50%, then it sits there for hours on end (let it run while I watched a couple of movies). When I look in my task manager it's pushing 99-100% CPU Usage, but the progression % does not increase, and the time to finish just keeps going up.

edit: Tested with Blood (?) preset and it takes about 25 minutes to run, Unholy 3.3 4p takes about 30 seconds, Unholy 3.3 no 4p takes about 25 seconds, 3.2 unholy 4p and no 4p both take multiple hours to run (BP and UP). Any idea what could cause this?

I'll try and take a look at this, but it would be helpful if you could send me the *.dko file that you used to duplicate these results so I'm sure I'm working with the right gearset to generate the problem. The issue almost must lie with the interaction of the weights for cappable stats (Hit, SpHit, Exp) vs. Strength / Crit / Haste, but it's not apparent at first glance. Additionally the fact that it calculates halfway and then freezes is disturbing - I know why that might happen, but it's odd that it would be so extreme.

Again, if you can get me the save file you used to generate these problems I'll gladly take a look and see what I can find. Let me know if you have any other issues in the meantime.

Edit: I can duplicate the 'freezing' effect under certain conditions, but I can't duplicate the problem where it gems half of the sets but doesn't gem the rest. I could really use your save file, so let me know if you can't get it to me and we can figure something out.

Reader be warned, wall of explanation text incoming.

Alright, so I'm fairly certain that I've tracked this down. Ironically enough the situation has reversed from previous versions of DK Optimize. Having Melee Hit being weighted above Strength is going to make calculations FASTER when forcing the melee hit cap. This should make sense, since the situation more closely mirrors the actual optimal set. Before going into the specifics of why this is the case, I'll note that in all of the 3.2.2 Unholy weights, both Strength and Melee Hit are weights at 3.050 APE. In the other weights that you tried, Hit and Strength are not so closely valued, which results in a faster calculation. As proof of concept I ran the file that you sent to me "as-is" and with the Melee Hit weight increased to 3.051 APE. The "as-is" test freezes around 56% gemming completion as you stated in your initial report. However, the test with the modified weight (increased by only 1/1000th) completes in under 2 minutes on my dated test machine.

The reason for this is the method by which the simulator determines what gems to use and how this interacts with elections to force the various hit and expertise caps. Prior to actually gemming a single item, the simulator creates a large, multi-dimensional matrix representing the selected gems, possible socket colors, and all combinations of hit and expertise up to the various caps possible for the calculating character. For each combination of hit and expertise, the matrix is populated with the best 'matching' gem for that level of hit and expertise and the best 'non-matching' gem. For example, below the melee hit cap a yellow socket will usually end up with a Bold Cardinal Ruby as the best 'non-matched' gem and an Etched Ametrine as the best 'matched' gem. This process is repeated for each combination of hit and expertise. It's not computationally cheap, but since it is only done once prior to calculation, the actual time that it adds is negligible.

One more thing to note is that turning off the option to force melee hit (as it is ON in your file) also causes the simulation to complete. This is because of how this 'GemValidityMatrix' (to steal from my code) interacts with hit and expertise cap forcing. The trivial example is to force melee hit with a single red socket and gear that has 244 hit, you need a Rigid King's Amber. However, under weights where Melee Hit <= Strength, the only gem that is ever optimal in a red socket is the Bold Cardinal Ruby (It is both the best 'matched' AND 'unmatched' gem). Under normal circumstances you would not have any hit/exp combinations for which King's Amber would be set to valid for red sockets. For hitcap forcing scenarios, though, the optimizer goes back AFTER finding the optimal gems for all circumstances and looks at all situations where hit is less than the specified cap. For each situation it says 'In addition to my already selected valid gems, also flag the best gem that contains > 0 hit rating as valid'. This is the key here. It doesn't matter how poorly hit is weighted, the optimizer will still flag these gems as valid below the hit cap so that the cap can actually be reached. The end results is that forcing hit cap results in a larger number of gems being valid at values of hit below the cap, which results in larger complexity. This is, in a nutshell, why hit cap forcing takes longer to calculate.

Alright, so the first thing that was happening was that forcing hit cap was increasing the number of permutations that had to be gemmed when below the hit cap. The second thing happening was that Melee Hit = Strength was causing some problems (increased complexity). When these two weights are equal, the number of gem permutations that are noted as valid increases dramatically due to the parity these two statistics. For example, rather than having a clear 'best' gem for a blue socket (matched) in either the Vivid Eye of Zul or Sovereign Dreadstone, both gems must be considered for all hit combinations < hit cap - 10. Note that the best 'unmatched' gem is also going to have to be BOTH Bold Cardinal Ruby AND Rigid King's Amber. This type of additional gemming dramatically increases the overall complexity. Any situation in which these two stats are not EXACTLY equal will not have this problem.

Finally, I can address the reason that it calculated partially and then stopped. I've already shown the two contributing factors to overall complexity to be forcing melee hit and the equal weight of hit and strength. The deciding factor, then, in overall gemming time for a given candidate set is driving by two things. The first of these is number of sockets in the gearset. Each additional socket increases the total complexity of the gemming calculation exponentially with an upper bound at the number of gems that are valid for that socket at 0 hit and 0 expertise. This number is usually 2-3. The huge numbers of sockets on 258 ToGC gear contribute to long calculation times. The other reason that hit cap forced calculations can go long, and the reason I suspect is the culprit for your pausing here, is that the complexity of gemming sets increases drastically the further below the required hit cap they are pre-gemming. Since forcing the hit cap increases the number of valid gems below the desired hit rating, it takes significantly longer to iterate over the necessary combinations to reach the hit cap if the set starts out further away. Once a set is gemmed to the hit cap in iteration, fewer permutations need to be checked, so the process proceeds much more quickly. What I suspect is happening is the calculation is lurching along at a reasonable pace until it hits a set with significantly less hit on it than the previous sets, and combined with the redundant gems from the strength and hit weights being equal it ends up grinding this set essentially forever in gemming where neither factor by itself was quite enough to do it. I'm not sure what to do about this off the top of my head, but it shouldn't be too hard to put in some kind of failsafe 'ditch it and move along' option as a last resort.

As a note - turning off the forcing of melee hit cap results in a set with 266 hit using the Unholy 3.2.2 4T9 BP weights anyway, but I am unsure about the other three 3.2.2 weight sets. Regardless I hope that is helpful to you. The easiest solution to reduce the complexity of the calculations (and eliminate redundant gems) is to make the hit weight <> strength weight, since that will slim the validity matrix down. It's an interesting situation that we ran into this, given that hit and strength were exactly equal in these weights. It's also possible that I've missed an additional factor, so if someone else has problems, please let me know.

I hope that helps, and let me know if you have any further issues. I'm eagerly awaiting the release of Icecrown gear, at which point I'll work to release an updated version with new items and up to date weights as quickly as possible.

TLDR Version: Having Strength = Melee Hit and forcing a hit or expertise cap will greatly increase the time it takes to compute results.

I was wondering why the AP Stat weight was set to 0 on some of your preset?

Good catch. I think that I glossed over entering an AP weight when updating these sets last time. Either way, in the system we use (weights primarily from Kahorie's Sim), AP always has a weight of 1.00. I'll have those updated in the next release, which will also include new / up to date 3.3 weights for ICC.

As a small progress report - I've got the known items from 3.3 entered into my local copy of the program, but I'm probably going to wait on a more complete loot list before releasing the Icecrown iteration of the optimizer. One thing that I'm a bit unsure of it how to value the proc on the Saurfang trinkets, so if anyone has seen any discussion on those that I've missed, please feel free to point me in the right direction. The case may simply be that we don't know how the proc works yet, though, and that would be okay.

Thanks again for catching that mistake.

After a bout of extreme boredom, I entered a ton of the known loot from 3.3 into my local save. Should anyone want to fool around with it, you can find it Here. No promises on anything there, though.

The new items aren't showing for me. I copied your file into the proper folder and I can see the items when i manually view the xml file, but the program doesn't display any of it. Anyone know why?

I've just uploaded an updated version of DK Optimize. I didn't get a chance to test the compiled version for any last minute bugs, so please let me know if it doesn't work. This version features full Tier 10 support and several updated weight sets - let me know if any of that doesn't seem to be functioning correctly.

Features:

• Added full support for Tier 10.
• All currently known Icecrown Citadel items are added.
• Added 3.3.0 weight sets for Unholy and Blood. Still waiting on Frost.
• Added auto-sorting at the item editing screens to ease the process a little.
• Updated save files to be 3.3.0 compatible. Your files will automatically be upgraded.
• Several small (very minor) bugfixes / optimizations.

It's altogether possible that there are errors in some of the data entry for the known items. As always, let me know and I'll endeavor to fix them as quickly as possible. If you have any problems at all I'll try to get right on it - I realize that this tool needs to be very usable right out of the gate for 3.3, so I'll be making daily (if not more frequent) updates when problems are found.

Download Link: DK Optimize v2.5.4 (~624 KB)

Hi Zerack and thanks for updating your tool, it works perfectly.

The only issue I had was with adding an items, I successfully added the cloak from Algalon Quest (10 man version) but after I save it it can't be found in the selection list. I could do that easily with the previous version.

I'm unable to duplicate this bug. I've opened a fresh install of DK Optimize, added a test cloak with a few stats, saved the items and closed the program. When I re-open DK Optimize the cloak is present. Can you please describe for me exactly what steps you are taking? Please note that items are sorted by iLvL in the item entry screen now, so your item may be moving around when you re-open the screen.

Let me know if that was the problem, or if the issue persists.

That was no bug, I just didn't try to relaunch the program, it works. Thank you.

To be clear - restarting the program should not be a prerequisite for the item to appear. I'll look at my local copy today and make sure that everything is working as advertised. I can't imagine the small changes I made introduced a bug like that, but one can never be sure.

Edit: I've verified that there is no error. After adding an item in the Master Item List and saving, the item appears both on the main screen and again in the item list if it is reopened. The program does not have to be closed for the item to appear after entry. If you are still having problems, let me know.

Found a minor error with the chest piece "Castle Breaker's Battleplate" it has three sockets instead of two, red blue yellow, and a socket bonus of 8 strength instead of 6.