possible to add more item mods for the search?

[Torcrob]

Hey first of all thanks for the great program, wouldnt know how to handle my standard stash without... but while searching for some things i noticed, that for example the crit multiplayer mod doesnt work for the search (maybe since the critmulti mechanic got changed ingame?(increased / to multi)) ; aswell as that alot of the mods for jewels are not listed/recognizeable by the dropdown/searchfunction. maybe its possible to add those to the listing? would love to be able to search for my legacy critmulti amys and jewels without looking through all of em... again great work, much thanks

edit: and maybe enchants? dont know if that would work similar..

[ericsium]

At least part of this has already been fixed with #388 and should be part of the next release.

[DaneelTrevize]

Crit multi, flat added life as found on jewels, and a few other popular mods are/will be added by PR #493 and #500 .

There seem to be far too many possible Abyss jewel mods to justify added them all to the current dropdown filter. Which would warrant a place? Should we combine some into pseudo entries such as 'conditionally add damage to spells'/'conditional increased attack speed'?

[ericsium]

One think I was thinking about doing at some point was instead of hardcoding the mod text for most of the attributes was to just generate them based on the items the user had in their stashes. You can take that idea and run with it if you like.

[DaneelTrevize]

For that, I'm thinking there'd still want to be a fuzzy modline matching internally when building the list, to auto-group all similar mods e.g. 'add x damage type while holding a shield'. By defining the substring/pattern to match on, each hit could then be added in their entirety to a corresponding pseudo/group filter entry (and checked against for all remaining-to-be-loaded modlines), which should hugely save on the size of the UI dropdown and thus the work of the QCompleter every time the user interacts with the dropdown.

Any pseudo filters that don't end up with any matches could either be never added to the dropdown list, or put at the end in a section indicating they have no results, or in a different dropdown/UI area to reduce the lists' size.

But reviewing this original issue description, Enchants would remain a different, awkward list to conveniently display, at least for those lab runners that generate many listings which presumably would have few repeats, given the size of the pool. For now, the PR'd enchanted-or-not status & filter might have to do.

[ericsium]

I haven't noticed any need to optimize or sort the mod list as QCompleter filters the list of current mods very quickly. I would assume it would do the same for hundreds of mods. That said, it would be straightforward to just add a few options to either include or exclude large groups of mods brought in by say jewels or enchants.

[DaneelTrevize]

I don't even have hundreds of tabs, and have missed most leagues across the years of playing POE, yet have over 20k items in Standard atm, and while the load time is dominated by waiting on GGG's API rate-limiting, I fear that a dropdown for every unique mod line would be ridiculous, and have elsewhere experienced UIs crawling & tearing when attempting to scroll such elements. I might be able to test this sometime this week, but it still seems best to assume a more complex grouping feature/not just loading up 1 huge dropdown would be best for UX.