This project is read-only.

Gemming Optimization

Topics: Retired
Jun 6, 2008 at 8:36 AM
Rawr appears to treat identical combinations of gems as if they were different. It's checking every gem Permutation, rather than every gem Combination. For example, an item with two red slots... it can create one item with +12 spell damage in the left slot, and +6 damage, +5 hit in the right slot... and a second item where the two gems are reversed. This dramatically increases the number of gem possibilities that it has to check, or means it's missing actual unique gemming combinations.

Obviously gems in different color slots matter, but when there is more than one slot of a particular color, Rawr needs to change how it processes gems somehow, so that it treats items with the same gems as identical, no matter which side the gem is on.
Jun 6, 2008 at 9:25 AM
Are you sure? I think the duplicates are removed during filtering.
Jun 9, 2008 at 2:52 AM
Well, I'm absolutely certain that two items were created in my itemcache, with the same gems, but on opposite sides. I almost never edit gems manually; both gemmings were created during an optmization run (with different talents selected). It's possible that it does not repeatedly consider the same gemming during optimization, but it can still create duplicate items due to choosing a different gemming pattern for some reason than it did during a previous optimization run.

But the fact that (for example) gemming has indeterminate order (for example, on an item with identical red slots, the odd-gem-out might be in the left, center, or right) indicates that duplicate gems are very likely to be considered, and/or duplication testing is inefficient.

To test for duplication, you need to sort the order of the gems within identical slot colors. But since the gemming routine (that creates a set of gems for the optimizer to consider) does not create sorted gemmings that means that the routine that tests for duplicates must have to sort them itself... and that's assuming that it is properly detecting duplicates at all. By only creating sorted gemmings (for example, always in the order of blue, green, yellow, orange, red, purple left to right) for consideration, you could skip the sorting step when checking for duplication. That would likely save a lot of processing.
Jun 9, 2008 at 3:39 AM
Effectively identical gemmings, or effectively inferior gemmings, are not considered by the optimizer. Which gemming in a tie that it does use is largely random, however, meaning that yes, you can end up with duplicates like that in your itemcache
Jun 9, 2008 at 4:02 AM
Actually initial gemming is deterministic. The likely cause where the alternative was introduced was during a mutation operation.

Performance of the initial filtering is not an issue at all. I'm profiling the application regularly and the filtering is dwarfed by other things. At least I haven't seen the app stall for any noticeable amount of time before progress bar starts moving.
Jun 12, 2008 at 1:01 AM
So gemming is determined prior to the bar moving? That makes sense, and explains the long pause when I have many items selected.

I thought it might indicate a problem, but I'm glad to see I was wrong.