Feature - Implemented Wiki lookup by category
- Thread starter Theraze
- Start date
Bale
Minion
Whoa. That sounds so dirty!
Theraze
Active member
Okay. If we're leaving this bug in for now, people just need to be aware that the first word in a multi-word search is irrelevant if it's not a valid type. So to find flask hol in items or effects, lookup flask flask hol. Or lookup blah flask hol. Or lookup whatever flask hol. It all works the same. 
First word, if not a valid type, is simply trimmed away without being kept.
First word, if not a valid type, is simply trimmed away without being kept.
Theraze
Active member
tldr: no.
Long answer: Well, the code example I gave in post 20 would have only trimmed off the first word if it was a valid category. In post 23, I was merely saying that the current behaviour is a change in how multi-word searches happen, and telling people what they can do to work around the change. The better fix would be to do something similar to post 20, but until then, people can still search for multiple-word items and effects without using a category if they're aware of how to do it.
Long answer: Well, the code example I gave in post 20 would have only trimmed off the first word if it was a valid category. In post 23, I was merely saying that the current behaviour is a change in how multi-word searches happen, and telling people what they can do to work around the change. The better fix would be to do something similar to post 20, but until then, people can still search for multiple-word items and effects without using a category if they're aware of how to do it.
Wait a minute - this "passes the search string on to the wiki"? Rather than "passing the resolved item/effect/familiar name, munged to be Wiki-findable, on to the wiki"? And you say the fuzzy matcher gets two results - but the command doesn't say "that is ambiguous among the following", instead it just passes ... "the search string" ... to the Wiki?
I wish I'd paid more attention to this; that user interface seems suspect.
I wish I'd paid more attention to this; that user interface seems suspect.
Theraze
Active member
If it doesn't match something uniquely, it passes whatever you searched for to the wiki. This is not new behaviour. The difference is that if, for example, you search for something that would match both a single effect and item, you can actually get the item - the effect search doesn't override your ability to item-search.
As it worked before, it would search effects and see if it would uniquely match on a single entry. If it failed to do so, it would search items and see it if it would uniquely match on a single entry. If either succeeded, it would pass that search to the wiki - effect first, if both would have matched. If both failed, it would pass your unmodified search string to the wiki.
As it worked before, it would search effects and see if it would uniquely match on a single entry. If it failed to do so, it would search items and see it if it would uniquely match on a single entry. If either succeeded, it would pass that search to the wiki - effect first, if both would have matched. If both failed, it would pass your unmodified search string to the wiki.
So, if it matches an effect AND an item, it passes the string to the Wiki and leaves it to its whim which one you get.
So, if I have this right, here are the options, as you see them.
lookup item NAME
lookup effect NAME
lookup familiar NAME
If any of the above uniquely match something of their type, we take the full name of the object and pass it to the Wiki - including applying Wiki page name rules - and disambiguation rules, if that name also matches another category.
If they do NOT uniquely match within that category, it does ... what? (I would say that the user friendly reaction would be to list the ambiguous matches and let the user try again with a less-ambiguous search string.)
lookup NAME
This looks up in ALL the tables. If there is only a single match, it behaves as if that type had been specified.
If there are multiple matches - either in a single table, or across multiple - it punts to the Wiki, and you get whatever the Wiki thinks you want. Which, as in the case of "13", may or may not be what you want. Heck, maybe you really DO want random Wiki pages. In which case, why should we look in any of the tables? Why not just pass the string through and let the Wiki resolve it?
What IS your intended usage of the "no type specified" lookup?
So your assumption is, if you don't specify a type, you want an item. Unless it matches an effect. In that case, you want an effect. Unless it matches both an item and an effect, in which case, you get whatever the Wiki gives you, which is an item.
So, if I have this right, here are the options, as you see them.
lookup item NAME
lookup effect NAME
lookup familiar NAME
If any of the above uniquely match something of their type, we take the full name of the object and pass it to the Wiki - including applying Wiki page name rules - and disambiguation rules, if that name also matches another category.
If they do NOT uniquely match within that category, it does ... what? (I would say that the user friendly reaction would be to list the ambiguous matches and let the user try again with a less-ambiguous search string.)
lookup NAME
This looks up in ALL the tables. If there is only a single match, it behaves as if that type had been specified.
If there are multiple matches - either in a single table, or across multiple - it punts to the Wiki, and you get whatever the Wiki thinks you want. Which, as in the case of "13", may or may not be what you want. Heck, maybe you really DO want random Wiki pages. In which case, why should we look in any of the tables? Why not just pass the string through and let the Wiki resolve it?
What IS your intended usage of the "no type specified" lookup?
Theraze
Active member
Before, effect would always win. If both matched, the item was irrelevant. I was stating how it was before you could specify. As it worked in my patch, it would continue the default behaviour (effect first, then item, then pass on the unmodified search if neither directly matches) if not specified. Not sure which Darzil committed as his tiebreaker... looks like he kept it in that way.
The new options are:
lookup item NAME
lookup effect NAME
lookup familiar NAME
lookup skill NAME
lookup monster NAME
lookup location NAME
lookup outfit NAME
We could search through all of the groups for a unique match if we wanted. My first goal though was not to change default behaviour for people who didn't want to change things, but only give new options for people who did want that. It's nice to be able to go straight to the ceramic outfit page, for example.
The new options are:
lookup item NAME
lookup effect NAME
lookup familiar NAME
lookup skill NAME
lookup monster NAME
lookup location NAME
lookup outfit NAME
We could search through all of the groups for a unique match if we wanted. My first goal though was not to change default behaviour for people who didn't want to change things, but only give new options for people who did want that. It's nice to be able to go straight to the ceramic outfit page, for example.
Last edited: