price queries for non-trivial items

[Xeverous]

The intial syntax idea to query item price looked like this: $divination(10, 100). It is very good for trivial items that have only 1 property (base type name): cards, prophecies, fragments, fossils and few others.

But some items have multiple properies, where each specific combination of them can significantly impact the price:

• gems: quality, level, corrupted
• bases: ilvl, influence
• maps: tier

The current idea is a functional-language-like syntax which allows to apply multiple filters to one query: $bases | ilvl(x) | influence(shaper) | price(10, 100).

Current plans for behaviour:

• The expression should still return an array of strings
• It should be an error if some filters are missing (eg no influence specified for bases)
• The order of filters should have no impact. All of tested items must satisfy all filters.

Things to discuss:

• Should some filters be optional (eg corrupted)? Or should we require the code to explicitly specify that we do not care (eg | corrupted(_))? I would favor "explicit better than implicit".
• Which item types should require which filters? (see the first list in this post)
• Name this | price(10, 100) feature somehow? "Filter" is too conflicting with everything else.
• The current idea still has some code duplication:

x = 86
BaseType $bases | ilvl(x) | influence(shaper) | price(10, 100)
ShaperItem true # How to avoid this? The same condition is already in the query.
ItemLevel x     # How to avoid this? The same condition is already in the query.
Corrupted false

[Xeverous]

Old syntax idea - getting rid of code duplication, also reusing already present filter condition syntax:

Rarity <= rare {
	ItemLevel 86 {
		ShaperItem true {
			BaseType $bases(100, 999999) { Show }
			BaseType $bases(10, 100) { Show }
			BaseType $bases(0, 10) { Hide }
		}

		ElderItem true {
			BaseType $bases(100, 999999) { Show }
			BaseType $bases(10, 100) { Show }
			BaseType $bases(0, 10) { Hide }
		}
	}

	ItemLevel 85 { [...] }
}

Notes:

• $query(min, max) no longer needs | filter(expr)
• query will be informed of all conditions stated previously
• queries will check if they have all conditions (eg ilvl, influence for bases; lvl, corrupted for gems) and error otherwise - they will only output base type names if conditions are narrow enough

Open questions:

• how to deal with ambiguous items (eg uniques sharing the same base type)?

[Xeverous]

After some discussions on https://www.reddit.com/r/pathofexiledev/comments/f5113m/, the problem has been solved perfectly by introducing new conditions which follow the syntax of existing conditions:

	Autogen scarabs
	{
		Price >= 20
		{
			SetTextColor $color_sacrifice
			SetBorderColor $color_sacrifice
			SetBackgroundColor $color_white
			SetFontSize $font_scarab_top
			SetAlertSound $alert_scarab_top
			MinimapIcon $icon_scarab_top
			Show
		}

		Price < 20
		Price >= 10
		{
			SetTextColor $color_sacrifice
			SetBorderColor $color_sacrifice
			SetBackgroundColor $color_white
			SetFontSize $font_scarab_mid
			SetAlertSound $alert_scarab_mid
			MinimapIcon $icon_scarab_mid
			Show
		}
	}

The new Autogen and Price conditions work just like real filter conditions (they can be inherited but not overriden), except they fill the filter with data obtained from poe.ninja/poe.watch APIs. Additionally, just after the parse tree is formed all autogenerated conditions can be checked to detect invalid blocks (eg scarabs which has Sockets specified).

This is already implemented and documentation has been updated.