This project is read-only.

Mutually exclusive items

Topics: Rawr.Base.Items
Feb 3, 2010 at 1:36 PM


I'm trying to find the right way to select between mutually exclusive items.  In most cases, it doesn't matter, as you can only equip one of them at a time anyway.  However, in the case of rings and trinkets, it can cause problems.

One example is the Ashen Verdict reputation rings.  You can only have one of them at a time, but there is a quest to swap back and forth at any time. I'm trying to decide between two rings:

Swap Quest: A Change of Heart
Ring 1: Ashen Band of Endless Vengeance
Ring 2: Ashen Band of Endless Might

I also have a few other rings obtained from other sources, and I'm trying to find the best combination.  However, I don't know how to tell Rawr that I can only ever obtain one of the Ashen Band rings.  If I mark both as available, Rawr will recommend I wear both.  If I evaluate upgrade on one while wearing the other, again, it recommends I wear both.

How can I tell Rawr to only consider one of them at a time?

Feb 3, 2010 at 2:21 PM

It is not possible to do this at the moment. The best way would be to first mark only one as available and optimize with it and then repeat this with only the other ring marked.

Feb 3, 2010 at 2:29 PM

Many thanks for the reply. =) I was mostly afraid that I was missing something blatantly obvious, as is my wont. =)

Feb 3, 2010 at 8:37 PM

I was actually just going to pose this question to the devs myself :)  We may be able to tie it in to how we are dealing with Unique(type) gear (ie, that you can't have both normal and heroic versions of an ICC trinket/ring).

Feb 3, 2010 at 9:30 PM

I was considering such a solution myself also. Basically have a int[] UniqueIds listing the ids that are considered "the same" for the purposes of uniqueness stored on the items. Having it null and Unique true can be interpreted as was now for backwards compatibility. The main question though is where would we populate the data for this from. One easy option is not to and just provide it as a feature for users that want to modify their item cache themselves for whatever specific purpose they are trying to solve.

Feb 4, 2010 at 3:43 PM

I think it would be beneficial for us to do this with the Heroic-Unique ICC loot when loading an item from the DB.  if ((Item.Slot == Trinket || Item.Slot == Finger || Item.Slot == OneHand || Item.Slot == TwoHand) && (Item.ItemLevel >= 251 && Item.ItemLevel != 258)) CheckItemDBForHeroicUnique(Item); // possibly replace the ILvL check with a source check to filter out quest rewards

CheckItemDBForHeroicUnique(Item i) {

 // Get list of items that share a name with i.  If one is 264, and another is either 251 or 277, then populate their UniqueIds



This could be either as a post-process to updating the item DB, or called after each item that meets the if-else case

Feb 4, 2010 at 9:28 PM

Wouldn't this code work pretty much the same way as the Dragonseyes code does right now? If you try to equip more than one it just disables both. The rest is a matter of lists to check, filled with item Id's (string names would be performance intensive, harder to check and prone to typo's).

Feb 4, 2010 at 9:49 PM

I'd prefer it to work the same way as current Unique does. I don't think we need to do anything more than that.

Feb 4, 2010 at 10:14 PM

Agreed.  The problem with Dragonseyes is that they are a unique solution.  We don't want to have dozens of Unique(Deathbringer'sWill) Unique(Saurfang'sCold-ForgedBand) Unique(DeathwhisperFangedSkull) type settings.  That's not very performant.

The reason I was using names is because it makes it automatable.  We don't want to build a list of all of these items by hand when the rule is pretty easy to follow.  If they have the same name, fit into one of the multi-equip slots (MH,OH,Trinket,Ring), and their ilvls are one of (251, 264, 277), they fit this bill.  If in the future (possible 3.4 or come Cataclysm) they continue down this path of unique, we can expand the logic.

One thing that may make this easier is if Wowhead/Armory include the unique info; we can add an attribute called UniqueName or UniqueID based on how this data is presented.  Regardless, I agree that tying this in to our current Unique implementation should be sufficient.