Filtration ♦ Item Filter Script Editor ♦ [ v1.2.2 ] ♦ Updated 2019-09-11

Updated to v0.2 - the new version is now available on the GitHub page here: https://github.com/ben-wallis/Filtration/releases

07/06/2015 - 0.2
♦ Tweaked the item preview display to have 3px of padding allowing bright borders to be displayed correctly.
♦ Added click-to-toggle functionality for Show/Hide summary items as per suggestion from Antnee.
♦ Changed Replace Colors dialog to initially populate both the New and Old colors with the existing colors when launched from the right click menu.

Show/Hide is perfect. However, one thing I noticed when I saved the file is that it removed all my tags. In my script, specific blocks have a tag behind the show/hide line and behind some RBG values, like this:

"

Hide #Gear - One Hand - Maces
Rarity Magic
Class Mace
SetTextColor 120 120 230 #Magic "Junk"

However, when I save using filtration, all my tags are gone. I use these tags for quick editing purposes, and a lot of folks are starting to use them in their own efforts as well. Would you be able to accommodate this type of tagging?

Edit: I believe you should have a look at my filter page, particularly the SmartBlock customization stuff. I believe you could incorporate this into your tool, which would allow very quick and concise editing on the fly.

A tab with a UI option list for specific filters could be incorporated. In my filter, there is an index which looks like this:

"

### Show #Quality Flasks
### Show #Utility Flasks
### Hide #Life/Mana Flasks in Maps
### Hide #Obsolete Flasks

Each of those lines corresponds to a set of blocks in the script. For example:

"

Show #Quality Flasks
Class "Life Flask" "Mana Flask" "Hybrid Flask"
Rarity Normal
DropLevel < 66
Quality >= 10
SetTextColor 225 225 225

Show #Quality Flasks
Class "Life Flask" "Mana Flask" "Hybrid Flask"
Rarity Magic
DropLevel < 66
Quality >= 10
SetTextColor 150 150 255

...the reason is simple; by using search and replace in a text editor, I can toggle whether or not quality flasks are shown or hidden. (I search for "Show #Quality Flasks" and replace with "Hide #Quality Flasks") There are some pretty large portions of the script that can be turned on/off in this way.

These blocks could be represented as checkboxes in the UI when a specific filter is loaded. So, if I did this in the index...

"

Show #//Quality Flasks

...and added a slash to the appropriate blocks...

"

Show #/Quality Flasks
Class "Life Flask" "Mana Flask" "Hybrid Flask"
Rarity Magic
DropLevel < 66
Quality >= 10
SetTextColor 150 150 255

...that block would appear as an entry in the UI with a checkbox, with the #Quality Flasks description. It seems somewhat trivial, but consider how many of these toggles I have in my own script and how vastly the behavior could be modified by a simple list of checkboxes.

So, the reason that comments on the same line as block items are stripped out is that right now when you load a script into Filtration each of the Show/Hide blocks are run through a translator which takes text in, and converts it into a C# object. These C# objects are stored in a List to make up a Block, and these blocks are stored in a List to make up a Script. (As an aside, your Section/Line/Block diagram was one of the original inspirations for creating Filtration, as it made it clear how easily you could represent an item filter script in an object-oriented design.)

So you end up with a hierarchy something like this:

"

Script
--Block
----BlockItem Show/Hide
----BlockItem SetTextColor
----BlockItem SetBackgroundColor
--Block
----BlockItem Show/Hide
----BlockItem Rarity = Normal

Whilst it would be easy enough to take a comment at the end of a BlockItem and store it in the BlockItem class, due to the fact users of Filtration can add and remove BlockItems at will, there's no guarantee that the comment will continue to exist after they've finished editing.

The exception to this issue is the Show/Hide BlockItem - there is no way within Filtration for a user to ever remove that BlockItem from a Block. One Show/Hide BlockItem is added during translation, and when a new Block is added, and they cannot be removed. This means that comments after the Show/Hide line could reasonably be assumed to be immutable (unless the containing Block was deleted).

So, that said - your idea about being able to quickly toggle groups of Blocks between Show/Hide based on their shared "BlockGroup" represented by the comment after the Show/Hide line - that's absolutely feasible, it'll require minimal changes to the Block class and translation layer, and the only real work will be adding in the UI to handle it (including allowing you to add new blocks to existing BlockGroups).

As for comments after other BlockItems, it seems that in your script you only use them for color BlockItems in order to allow quick replacement of colors throughout a script. Seeing this in multiple peoples filters was the reasoning behind the creation of the Replace Colors tool within Filtration - it allows you to quickly replace color combinations throughout an entire script based on an existing Block. This pretty much negates the need for such comments against BlockItems - the color categories are included in your Script description, and to replace them a user just has to scroll to a block of that color and right click > Replace Colors.

Let me know if I've missed/misunderstood anything, and what you think of my comments above. I really appreciate the detailed feedback btw - this kind of thrashing out of "metadata" storage within scripts was something that I had anticipated would come up, so it's good to get it sorted early on.

"

AtomYcX wrote:

(blockitem description)

Makes perfect sense.

"

AtomYcX wrote:

As for comments after other BlockItems, it seems that in your script you only use them for color BlockItems in order to allow quick replacement of colors throughout a script. Seeing this in multiple peoples filters was the reasoning behind the creation of the Replace Colors tool within Filtration - it allows you to quickly replace color combinations throughout an entire script based on an existing Block. This pretty much negates the need for such comments against BlockItems - the color categories are included in your Script description, and to replace them a user just has to scroll to a block of that color and right click > Replace Colors.

Let me know if I've missed/misunderstood anything, and what you think of my comments above. I really appreciate the detailed feedback btw - this kind of thrashing out of "metadata" storage within scripts was something that I had anticipated would come up, so it's good to get it sorted early on.

Yep, this is a vastly superior way to do replace colors. Though having a similar grouping for tagged colors might be useful, I could live without the color tags. Overall I'm really excited for what's to come!

Great work!

I really like the idea. I will test it today after work.

free bump!

Wow, this is an amazing tool. I'm using Antnee's filter and found this tool b/c he mentioned adding support for Filtration to the filter.

All I can say again, is, wow. So simple, so powerful, so straightforward.

Only suggestion I can make is when picking a color under the list of "standard colors", include the exact colors used by default in game? Example: "Magic Blue" "Rare Yellow" "Unique Orange" etc so that players can easily go back to a default color. Maybe this is already the case, I honestly can't tell if the blue listed under "standard colors" is the exact same blue used in-game. Although I suppose by simply not assigning a color via the filter, then the default color applies?

Also, changing fontsize doesn't change the preview. Default font is 35 I believe, perhaps having font size default to the standard value in the input box? What I mean is that when I click "font size" the number displayed is 0, instead could be 35 to start with.

"

lalib wrote:

Only suggestion I can make is when picking a color under the list of "standard colors", include the exact colors used by default in game? Example: "Magic Blue" "Rare Yellow" "Unique Orange" etc so that players can easily go back to a default color. Maybe this is already the case

That's a good idea - I'm pretty sure the ColorPicker control I'm using should support that - the colors you see there in the "Standard" view of the ColorPicker are the defaults for that control, and they seem to be completely random. Added to the to-do list.

"

lalib wrote:

Also, changing fontsize doesn't change the preview. Default font is 35 I believe, perhaps having font size default to the standard value in the input box? What I mean is that when I click "font size" the number displayed is 0, instead could be 35 to start with.

Yeah font size doesn't affect the preview currently - mainly because I haven't tested it in-game to see what size 35 looks like in-game compared to what size 35 looks like in WPF, I imagine some sort of conversion will be required to attain parity. And of course, in cases where players run PoE in a window, or at full screen at a different res from their desktop, such a representation of font size will be incorrect anyway. I'll have a play around and see what I can do :)

Development Update

May as well give a quick update on development whilst I'm bumping this post anyway - there should be a new release at the end of this week. The first major feature in this release will be a UI overhaul, Filtration now uses AvalonDock - a docking framework based on the way that tools such as Visual Studio do their window management. It basically means tool windows and the like can be hidden and floated, and docked at different parts of the screen, and you'll also be able to view filter scripts side-by-side if that's what you wish to do.

The second, more important feature though is support for "Smart Blocks", or "Block Groups" - these are features of some existing loot filter scripts (Antnee's and Muldini's for sure - there may be others) which allow you to "toggle" specially designed blocks which represent items that different players are likely to have a different view of whether they wish to have shown or hidden. As it stands, the way players make these changes is by doing Find & Replace with a text editor. The next version of Filtration adds the Block Group Browser tool - Filtration now automatically reads all BlockGroups from a script upon load and displays them in a hierarchical treeview, allowing players to show or hide these BlockGroups at any depth level in a single click. This makes the changing of scripts that support this functionality vastly more accessible to players who might not want to spend a lot of time manually editing scripts.

Preview screenshot: http://i.imgur.com/Cqm57Ri.png

This tree view is a bliss. Nice job, Ben. I am very excited to see the next evolution.

I was wondering about another thing:

As of right now it's quite easy to switch between Show/Hide. I imagine it's even easier using your tool. Would it be possible to toggle between "highlight" and "show"? Your tool would need to be aware of all the visual/audio modifiers (kinda guess it is already on some level) and comment/uncomment them.

Commenting rather than removing them leaves the option to add them back easily.

Exmaple:

Show #Leveling Specials - Quartz Sceptre
BaseType "Quartz Sceptre"
LinkedSockets 3
ItemLevel <= 25
SetBorderColor 210 0 0

This gets highlighted by a stark red border (SetBorderColor 210 0 0). But rather than hiding it alltogether, the option to merely show it without any kind of highlighting could be beneficial.

Thoughts?