Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reused Saved Searches using insaved: #10668

Closed
DHager opened this issue Aug 2, 2024 · 4 comments
Closed

Reused Saved Searches using insaved: #10668

DHager opened this issue Aug 2, 2024 · 4 comments

Comments

@DHager
Copy link
Contributor

DHager commented Aug 2, 2024

Proposed change

Context

Currently it is possible to "Save Search" a filter string, and some of them are both reusable and non-trivial. For example, this one for weapons that are capable of stunning Overload Champions, either due to innate breaker:* properties or else because they are able to benefit from seasonal mods or else because they can be used to trigger particular elemental effects.

/* s24overload */ breaker:overload or (-breaker:any (is:handcannon or is:sword)) or exactperk:voltshot

Proposal

A new filter type insearch: which allows a previously saved search to be referenced without manual retrieval and copy-paste construction in a separate text editor. For example, these two lines would be equivalent:

is:arc insearch:"s24overload"
is:arc (breaker:overload or (-breaker:any (is:handcannon or is:sword)))

Design considerations

Cycles

Searches using this feature are essentially trees, and must be prohibited from following an edge that would create an infinite loop. For example, suppose there are three saved searches:

  • /* alpha */ insearch:beta power:=2000
  • /* beta */ insearch:foo
  • /* gamma */ insearch:beta

And the user enters a search of: insearch:gamma or is:weapon

Resolving everything is effectively a depth-first search, and by maintaining a stack of saved-search names, we can reach alpha and determine that insearch:beta is not legal because beta is already on the stack.

Once detected, I'm not sure what the best way to handle this is. This error can either invalidate the entire search, or the repeated insearch:beta can be treated a value which always resolves to a boolean for all search items.

Searches which don't yet exist or were removed

If there is no matching saved search, I suggest treating it the same as whatever happens when a cycle is blocked.

How does this fit into your workflow?

This would allow me to more-easily combine and use custom saved searches, such as....

Example: Nightfalls

Listing weapons that will be beneficial for handling the champions of a weekly nightfall's champions and also taking advantage of its elemental-surge or weapon-type-overcharge modifiers:

(insaved:s24barrier or insaved:s24overload) (is:solar or is:arc or is:rocketlauncher)

Without this feature, I would need to retrieve both of those saved searches, add parenthesis, and copy-paste them together manually, which is slower, error-prone, and hard to read, ex:

(/* champbarrier */ breaker:barrier or (-breaker:any (is:pulserifle or is:submachine))) or (/* champbreaker */ unstoppable or (-breaker:any (is:sidearm or is:scoutrifle))) (is:solar or is:arc or is:rocketlauncher)

Example: Armor infusion

This search shows armor I probably want to focus on infusing, along with armor I might sacrifice to make it happen. It prioritizes legendary armor and exotic armor where I either have only one of them or where I've chosen to masterwork it fairly highly.

/* priority infuse armor */ is:armor -notes:#raidonly -tag:junk ((tag:infuse power:=2000) or (power:<2000 (is:exotic (count:=1 or masterwork:>=9))))

If I get a bunch of drops on my Warlock and want to focus on those, this feature would make it convenient:

insearch:"priority infuse armor" is:warlock

Example: Weapon infusion

This saved search shows weapons which is a higher-priority to infuse up to a new cap, along with weapons I might sacrifice to make it happen. It also excludes tag:infuse weapons that I want to keep around a little longer before infusing because I may have use for them with a Deepsight Harmonizer, depending on my luck in upcoming drops.

/* infuse wepset */ (is:weapon power:<1990 (kills:>500 or notes:#boss) (notes:#pve or notes:#shield)) or (is:weapon tag:infuse -(is:craftable -is:crafted -is:patternunlocked deepsight:harmonizable))

With this feature, complex filters are more maintainable, and interesting chunks can be reused elsewhere.

  • /* reserve for harmonize */ (is:craftable -is:patternunlocked deepsight:harmonizable)
  • /* infuse wepset */ (is:weapon power:<1990 (kills:>500 or notes:#boss) (notes:#pve or notes:#shield)) or (is:weapon tag:infuse -insearch:"reserve for harmonize")

Example: Weapons to grind levels on

I want to preferentially use weapons that need to be leveled up in order to apply enhanced perks, defined in a saved search like:

/* needs xp */ (is:enhanceable -is:enhanced weaponlevel:>0 weaponlevel:<17) or (is:crafted -is:exotic weaponlevel:<17)

However I also want to make progress on some saved bounties or a weekly challenge that involves certain weapon/element choices. With this feature, I could write:

insearch:"needs xp" (is:sidearm or is:autorifle) (is:arc or is:kineticslot)

@bhollis
Copy link
Contributor

bhollis commented Aug 2, 2024

I think this is a reasonable, clever idea. My main concern is that it continues to expand on the "fringe" of search use cases - even just naming saved searches is probably only used by a handful of extremely knowledgeable users. I'm hesitant to significantly increase the complexity of search for such a small population.

There's another concern, which is that this makes one search dependent on another - what happens if the original search is deleted? What happens if two searches are saved with the same name?

@DHager
Copy link
Contributor Author

DHager commented Aug 3, 2024

I think the most important use-case is the anti-champion weapons thing, and that could be done by making the breaker: filters smarter... However there are some significant challenges behind that:

  • The system needs to know that innate breaker status is permanent, ex: Wish Ender has intrinsic anti-barrier, so Overload Bow will do nothing.
  • It would need to recognize which seasonal-artifact mods are important, what breaker-status they are for, and what kinds of weapons they empower.
  • It would somehow need to resolve the problem of Seasonal Artifact mods being both dynamic and per-character.
    • Option A: Act without regard to the status of Seasonal Artifact mods, just assume all are enabled for any character, and it's the user's responsibility to realize their breaker:overload weapon isn't working because they didn't change the Seasonal Artifact on the specific-character they are playing.
    • Option B: The filter only considers Seasonal Artifact mods that active for all characters at the same time. This prevents "WTF it isn't working" bad experiences during combat, but may easily confuse players doing inventory management.
    • Option C: The filter gives different results depending on which character DIM believes is currently being used, which could confuse players even if it's perfectly accurate. ("It showed before I swapped characters, why isn't it showing now?")
  • Note: Echoes Act 2 showed that the Seasonal Artifact can change mid-season/episode, when it gained a new bottom row of choices.

Another spin-off filter might be something like is:levelingup, to filter for weapons which are either crafted or which have taken the first step in being enhanced, but have not yet gained enough weapon-levels that all perks/perk-columns can be upgraded.


what happens if the original search is deleted?

I assumed that would be either an error state like when entering is:foo... While that doesn't give an explicit big red warning stripes visual effect, I notice now that it does block saving a search, so there's some kind of error-flag logic going on.

What happens if two searches are saved with the same name?

Hmmm, I hadn't considered that, I guess it does allow for duplicate labels.

@bhollis
Copy link
Contributor

bhollis commented Aug 5, 2024

I think it makes sense to have search keywords for breaker-applicable (considering the artifact) and the "needs leveling" logic. I believe #8914 is the start of the first one.

@bhollis
Copy link
Contributor

bhollis commented Sep 6, 2024

Closing because I think this is too complicated (from a user standpoint) to add.

@bhollis bhollis closed this as not planned Won't fix, can't repro, duplicate, stale Sep 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants