Loot filter XML technicalities/improvement suggestions

Bug Reports
1

Disclaimer

These aren’t disturbing gameplay, but things I’ve found while examining the XML generated by the game when creating loot filters. I’m looking into this because I may create some tooling for it outside the game. So consider this more of a code review than anything else. If you would consider ‘fixing’ these points, it would be nice to know once tooling has been made, because changes like these are ‘breaking’ (and thus better now than later).

Typos

  • AffixCondition.comparsion ⇒ comparison
  • AffixCondition.comparsionValue ⇒ comparisonValue
  • LevelCondition.treshold ⇒ threshold

Inconsistent casing

In general all nodes should begin with a lower case character, and mony do, but not all. For example

  • ItemFilter ⇒ itemFilter
  • Rule ⇒ rule
  • Condition ⇒ condition
  • EquipmentType ⇒ equipmentType

Additionally all values are in uppercase, except those for ClassCondition.r.eq.

Inconsistent ‘list’ solutions

Affix and equipment conditions have a list of int and/or EquipmentType, whereas rarity and class conditions have a space separated singular value. Furthermore I suggest renaming SubTypeCondition.type to SubTypeCondition.types (plural) to match with the rest (subTypes, affixes, rules, conditions).

Usage of ids instead of (technical) names

Only EquipmentType, ClassCondition and RarityCondition at this moment use understandable names (besides the operations such as LESS_OR_EQUAL). The rest all use an id, such as

  • filterIcon
  • filterIconColor
  • Rule.color
  • affixes.int
  • subTypes.int

From an integration point of view (and technical understanding) it would be nice to have a technical name instead of such an id. For example affixes.int[501] = VITALITY.

Inconsistent nested naming of condition values

From a technical point of view, it seems easier if things are named the same if they do the same thing. For example AffixCondition has comparison and comparisonValue (I already corrected the typo here), but LevelCondition has type and threshold (also corrected typo here). I suggest the following for consistency

  • LevelCondition.treshold ⇒ comparisonValue
  • LevelCondition.type ⇒ comparison
  • SubTypeCondition ⇒ add comparisonValue and put type and subTypes under it
    Also add a fixed <comparison>ANY</comparison> to keep it consistent with the rest
  • RarityCondition.rarity ⇒ comparisonValue
    Also add a fixed <comparison>ANY</comparison> too keep it consistent with the rest
  • ClassCondition.r.eq ⇒ comparisonValue
    Also add a fixed <comparison>ANY</comparison> too keep it consistent with the rest
2