Improve searching in crafting menu

[Brambor]

This is an aggregation of issues with searching in the crafting menu.

Problems and their possible solutions

search cancel - fixed by #77782

Problem

You cannot cancel the search when you write a bad prompt.
This results in long waiting.
Inability to cancel search on realizing it is badly written.

Solution

Add cancel search button. List the button under the search progress.

Alternatives

Add Are you sure?.
But that probably causes more time loss than searching again. - Be more annoying.
See the time it takes on my PC in problem search by clothing layer/cover.

---

search by clothing layer/cover - fixed by #78346

Problem

Not being able to filter clothing in the crafting menu.

Usecase: I need close to skin clothing for my head (Under armour)

Solution

Search by clothing layer (close to skin, normal, outer, ...) (idea by ... cannot find it now...)
Search by what layer body part it covers (HEAD, TORSO, ...)
Note: things like bows can be equipped on the torso, it is ok to show them in the search.

Workaround

Search prompt d:close to skin,d:HEAD (takes 1m29s = first part 1m25s + second part 4s)
Search prompt d:HEAD,d:close to skin (takes 2m50s = first part 1m23s + second part 1m27s)
Waiting for over a minute and with no option to cancel is too much.

---

Filter: `m:no` is cluttered with recipe groups - fixed by #64627

Problem

Filtering recipes that aren't memorized returns all recipe groups on top. Filter: m:no. (From @dom4op).
It is cluttered by recipe groups.
Recipes in recipe groups that are memorized are still shown.
Meanwhile m:yes yields no recipe groups.

Solution

Don't show recipe groups, only recipes.

Alternatives

No response

---

Cache results of `d:some item description` - fixed by #77914

Problem

The player searches for Close and then specifies further by Close to skin.
This is slow despite the logical inside that the second is a subset of the first.

Solution

Hash the last X results and if the new prompt would result (R2) in a subset of the previous result (R1), search only on R2 instead of the whole database. (R1 is a result that has been hashed).
Hash just searches for item descriptions. That's the only slow part. In other words, searches in form of d: X where X is the desired description of an item with no special characters.
Invalidate hash once the crafting menu has been closed. (I believe no ticks can pass while it is opened so nothing can change).

Alternatives

Implement everything the player needs to search for.
Notably all keywords like

• covers head
• close to skin
• normal layer
• this item can be used to perform reach attacks)

---

Additional context

There might be more, I will try to update this. Also, the clothing ideas are mostly not mine.

[dom4op]

Weird, search functions always shows results instantly for me. There is no wait time. However, "m:no" filter is kinda broken. It clutters search results with those blue categories, all of which are marked as "not memorized" for unclear reasons. Which makes the entire "m:no" filter useless, unless you combine it with another filter. Still, I would like an option to comfortably navigate all unmemorized recipes at some point.

[Brambor]

Weird, search functions always shows results instantly for me. There is no wait time.

Every search returns nearly instantly for me. Except for anything searching description, like "d: Close". The UI even warns that these are slow.

Mind rechecking that you indeed need to wait for it to return? I wrote this entire comment while searching "d: Close"

[Brambor]

However, "m:no" filter is kinda broken. It clutters search results with those blue categories, all of which are marked as "not memorized" for unclear reasons. Which makes the entire "m:no" filter useless, unless you combine it with another filter. Still, I would like an option to comfortably navigate all unmemorized recipes at some point.

I looked into it. m:yes returns no category for me. m:no is less cluttered than yours but importantly: categories show recipes that are memorized, which is directly against the filter. Thanks!
It looks like m:no returns EVERY recipe category.

[dom4op]

Mind rechecking that you indeed need to wait for it to return? I wrote this entire comment while searching "d: Close"

Yes, you're right. The wait time is indeed significant, and you can't cancel it midway.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. Please do not bump or comment on this issue unless you are actively working on it. Stale issues, and stale issues that are closed are still considered.

[Brambor]

Apparently, cancel doesn't need multithread, code example from Snup on discord:

https://discord.com/channels/598523535169945603/598535827169083403/1297828320746143755