[LOOTFILTER] FilterBlade - editor, with lootgeneration & more - optimized for NeverSink's filter

"

NeverSink wrote:

It's a bit tricky to explain.

Spoiler

The filterblade load procedure is:

1) Load selected filter (latest version) - the econ-filter is selected here
2) If you're loading a save, modify the filter based on the operations written in the save.
3) Whatever things you do on filterblade afterwards. Such as move items, show/hide, use the filterblade sorting/economy tools

Operations happening in 3 have priority over 2, have priority over 1.

So if you move something in 2 or 3, it'll have priority over whatever econ-versions are doing. If you move a single item on filterblade, to a different tier and save, your tiering decision will have priority over the tiering decision of the econ-tiering. This is useful, if you wanna create exceptions for certain items.

For instance, if you move bramblejack to T1, every time you load, it'll stay in T1, but you'll be receiving the latest version of the filter and all the econ-decisions, except that one.

I generally do not recommend to use the "auto-tier" feature on filterblade with econ-tiering versions, unless you know what you're doing.

The econ version come with different tierlists. The following tierlists are currently affected: Uniques Divination Uniquemaps Shaper Elder Generalcrafting Fossil Incubators Prophecy Scarabs Oils.

Note currency is NOT currently auto-tiered, due to several concerns. This will likely change in the future, when I'll have enough data to know that this works as intended.

I won't go into detail as to how the improved algorithms work exactly, since it'll be a very lengthy and highly technical explanation. I intend to make a post/video about it in the upcoming months. However, the procedure is opensourced. If you're a developer, check out: https://github.com/NeverSinkDev/FilterPolishZ

In the future, I also intend to add a way to visualize what exactly the difference between different versions is. However this is a bit of a technical challenge. It requires loading two filters in parallel and comparing and visualizing lots of data.

"

DivineChampion wrote:

"

NeverSink wrote:

...

Bugreport: multiple selectors of the same type in one rule doesn't work, which makes a lot of rules across item filter non-functional.

In section "[0710] Helmets" following rule has 3 selectors of type "HasExplicitMod" and it doesn't show rare helmet with "Xopec's" prefix:

"

Show # $type->expl->rare
Identified True
DropLevel > 50
Rarity Rare
Class "Helmets"
HasExplicitMod "Dauntless" "Indomitable" "Unassailable"
HasExplicitMod "Blazing" "Seething"
HasExplicitMod "Abbot's" "Necromancer's" "of Ephij" "of Haast" "of Lioneye" "of the Assassin" "of the Blur" "of the Genius" "of the Gods" "of the Godslayer" "of the Ice" "of the Jaguar" "of the Leviathan" "of the Lightning" "of the Maelstrom" "of the Magma" "of the Phantom" "of the Polar Bear" "of the Polymath" "of the Savant" "of the Titan" "of the Virtuoso" "of the Volcano" "of the Wind" "of Tzteosh" "Puhuarte" "Seraphim's" "Xopec's"
SetFontSize 45
SetTextColor 255 190 0 # TEXTCOLOR: Rare 75+
SetBorderColor 0 240 190 240 # BORDERCOLOR: Special Base
SetBackgroundColor 0 75 30 255 # BACKGROUND: Rare T1
PlayAlertSound 3 300 # DROPSOUND: Unique
PlayEffect Blue
MinimapIcon 0 Blue Diamond

This rule shows the helmet only after i comment first two "HasExplicitMod" selectors - so 3rd one which has "Xopec's" as parameter finally applied.

This bug globally breaks explicit mod filtering across all item filter, so it doesn't work properly at the moment.