-
-
Notifications
You must be signed in to change notification settings - Fork 645
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
Comments
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? |
I think the most important use-case is the anti-champion weapons thing, and that could be done by making the
Another spin-off filter might be something like
I assumed that would be either an error state like when entering
Hmmm, I hadn't considered that, I guess it does allow for duplicate labels. |
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. |
Closing because I think this is too complicated (from a user standpoint) to add. |
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 thatinsearch:beta
is not legal becausebeta
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)
The text was updated successfully, but these errors were encountered: