This project is read-only.

Results dialog - miss the old text style

Topics: Rawr.Base.Optimizer
Jul 27, 2009 at 4:44 PM

I find the old text-based optimization results dialog much easier to interpret than the new side-by-side graphical version.  Of particular note are the times that Rawr suggests I swap the positions of rings or trinkets, or equivalently swap the gems in two pieces (or even three) pieces of gear.

An ideal solution would be to add an user interface option to choose the preferred results display: graphical or text.

Jul 27, 2009 at 6:09 PM

Or, we can have it populate all that empty space around where it says the new optimized gear score. Please a textbox that can scroll and we're in business.

Also, on a similar note dmleach touched on, can we find some way to make it not swap gems around? If the total bonus from these is the same having a Solid in the helm and Guardian in the Wrist and vice-versa, I'd like to make it just stay the way it was so I dont have to manually go back and change them to what they were while keeping the other optimization changes.

Jul 28, 2009 at 1:21 AM

Can you provide an XML example of a time it suggests you swap the position of rings or trinkets this should NEVER EVER happen now. Indeed that was specifically removed way before the graphical report was implemented. The reason is that the output from the optimiser specifically checks to see if the only change is to swap slots and if so it simply doesn't report the change.

Swapping gems in items can be for a huge variety of reasons, socket bonuses being a biggie. However sometimes it just says to swap gems when its identical unfortunately this is just how a GA works there's not a lot more you can put in there to fix that.

Did you really find that long lists of items saying it was swapping gems around was better?

Jul 28, 2009 at 2:12 AM

It'll never swap items between slots anymore, but it will indeed still swap gems where it doesn't matter, if there is any other upgrades as well. We don't have an obvious way around that at the moment, but it's definitely on our radar in the 'we'd like to fix that' category.

Jul 28, 2009 at 2:38 AM

A workaround would be once the optimize has completed, run an additional check for swapping gems back to original spots without changing end result.

How you would do that.... i leave to the experts

Jul 28, 2009 at 4:46 PM
Edited Jul 28, 2009 at 5:03 PM

We would basically have to add an O(n^2) algorithm, with n mapping the slots being changed by the optimizer.  Pseudocode:

Character tempCharacter; Character originalCharacter; Character optimizedCharacter;
int optimizedScore;
for (j=0; j<numOptimizedSlots; j++) {
	if (originalCharacter.EquippedItem(slot[j]).ItemID != optimizedCharacter.EquippedItem(slot[j]).ItemId) continue;
	for (k=j+1; k<numOptimizedSlots; k++) {
		if (originalCharacter.EquippedItem(slot[k]).ItemID != optimizedCharacter.EquippedItem(slot[k]).ItemId) continue;
		tempCharacter.equip(slot[j], originalCharacter.EquippedItem(slot[j])); tempCharacter.equip(slot[k], originalCharacter.EquippedItem(slot[k]));
		if (tempCharacter.OverallScore == optimizedScore) {
			optimizedCharacter.EquipGemmingTemplate(slot[j], originalCharacter.GemmingTemplate(slot[j]));
			optimizedCharacter.EquipGemmingTemplate(slot[k], originalCharacter.GemmingTemplate(slot[k]));

This assumes that we can do all of these features, obviously.  Enumerate through slots that are optimized, compare itemIDs based on slot, access gemming template used on each slot.  I haven't worked enough with Rawr.Base to know if we can do this though.

Jul 28, 2009 at 6:17 PM

It's a bit more complex than that. It's quite possible and I've seen it a few times that there are cyclic changes of gems and not just pairwise.

Jul 28, 2009 at 6:29 PM

If we may, I'd really like to leave this thread as a discussion of the old text-based results dialog and move any discussions of the quirks of actual results to other threads.  As I mentioned in the OP the textual results are particularly nice for finding swap cycles, but that's not the only advantage.  In general I find the text-based results easier to follow and make changes.  All the suggestions were displayed on a single dialog with both the old and new gear, gems or enchants readable.  The new interface can only be read by hovering the cursor over each slot to see the suggested changes.

Jul 28, 2009 at 6:41 PM

Both the text, and 'new' dialog are obsolete at this point; we only really care about feedback about the 'new new' dialog that is a part of Rawr3:


Jul 28, 2009 at 7:03 PM

That's much better!  What I missed was the textual side-by-side that explains what is currently in the slot and what is suggested to be in the slot.  I'll look forward to Rawr3 eagerly!

Jul 28, 2009 at 7:19 PM

"It's a bit more complex than that. It's quite possible and I've seen it a few times that there are cyclic changes of gems and not just pairwise."

Hmm... well, the algorithm still works, it would just need to be modified to be O(n^n), which still isn't terrible considering that N is just the number of slots where the recommended optimization is just a gem change and not a gear change.

The problem I just realized in the algorithm is that it only assumes that this issue arises when the items stay the same but the gemming has changed.  However, it doesn't include what happens in the case where it's telling you to put a DragonsEye in the a NEW piece of gear that gives the same socket bonus as the old one (such as a player who needs a single 27hit DE gem and two 27agi gems, and it goes from AGI in chest/shoulders and hit in bracers, to AGI in bracers and new gloves, and hit in chest).

I guess really it's a minor annoyance at best, though.  The human behind the machine can still recognize the changes.


Jul 29, 2009 at 4:28 PM
Edited Jul 29, 2009 at 4:29 PM

Is there a feature list somewhere for Rawr 3.0? Is there a tentative release date target? That optimizer screen is sex.

Jul 29, 2009 at 5:30 PM

No, not yet.

Aug 1, 2009 at 12:56 PM

Gemming logic:

Ideally we want the optimiser to handle gemmings with non-important swappings as identical, to remove degrees of freedom and make the whole optimisation faster. (The GA should work with the number and type of gems, not where they end up being placed as the unique DNA strand). But then determing which socket bonusses gets met, become computationally intensive and probably negates the speedup this would have given us.

The simplest way to optimise the number of gemming switches is to add a penalty function to the gear optimisation process. Each gem swap subtracts X from the final score. (Even better is if you base X on the cost of the particular gem, but that becomes realm specific and fluctuating). Keeping X a small constant like 0.1 should probably be good enough. The smallest socket bonus or using incorrect gems should still be more important than a gem swap.

Alternatively, if we are afraid we miss the optimal, we can 1st run the optimiser as normal and remember the score. Then run a few generations with the GA only being allowed to swap gems and applying the penalty function. (You can then still check that the score ignoring the penalty function didn't drop).

To do this algorithmically, without just using a blind optimisation, would be a bit more effort to code, but would probably be something along the lines of:

Group  and count the gems used in the optimiser result. This is the group of available gems.

Most important is meeting socket bonusses. Check for each obtained socket bonus what was the old gemming and whether those gems are in the list of available gems, if so assign then and remove from the available gems.

Those gems used for socket bonusses and not matching previous, will need to be new gems. If one 1 type of gem matching socket color in available list, assign that slot and remove from the list. If more than 1 matching color, you probably have have to try each option.

Then iterate over the non-socket bonus items, assign those where the old gemming matches something in the available list.

The remaining open gem slots are new gems and where you slot them in doesn't matter.  (If you where trying multiple options for meeting socket bonusses, the count/cost of this would be the cost of this try).