Feature - Implemented Wiki lookup by category

Theraze

Theraze

Active member
Was some pondering happening on the Relay board and I thought I might put together a patch that allows for doing a lookup for a specific type of item. This may not always pull up the right item in case of familiars with same-named monsters, the Black Cat in particular being the one I tried, but even if it fails in that way, the pages have a redirect to the proper familiar page. Worst case, if you try to do a lookup that's obviously wrong, like "lookup effect o.a.f." it will just do a regular search, as it would have before. However, "lookup item o.a.f." gives you the familiar item, while "lookup familiar o.a.f." does now give you the familiar itself. This change only catches the lookup command if the first word is one of the following: effect, effects, familiar, familiars, item, items, skill, skills. If the first word is anything else, it just passes the lookup through normally. As well, it currently doesn't add the familiar or skill database to normal searches, only using them if they're requested especially.

I used ifs because the category names were different lengths, and I didn't necessarily want to break off the first word if it wasn't actually a category search. startsWith let me match a variable length string, and all I needed to know for that was the string I was matching and what it was matching against. After I matched the specific string, I then removed that string (and its trailing space) from the parameters, and passed the trimmed string to the search.

Edit: As an additional change, to add in searching through the familiar and skill databases, all that needs to be added is to put
Code: 
lookuptype == 0 ||
into the beginning of their checks, before the current
Code: 
lookuptype == 2 (or 4)
sections. I left those out for now from the default search, because that wasn't existing functionality, and I wasn't sure about primacy... which order people wanted them in.

Edit: This version is not what you actually want. The better version that actually will do Familiar lookups is below... Pulling this download after 3 looks. :)
 
Last edited:
Isn't there also a Black cat monster? (Okay, the "lookup monster" command might be a bit tricky, since you'll run into issues with monster bait. I'd suggest maybe having some way to distinguish between a specification of datatype and part of the unit's name. Perhaps a $ in front of the datatype?)
 
Yes... finding the Black Cat monster is currently an issue with familiars and the way the KoLwiki works, in that familiars have each word capitalized, while other article types don't.

Currently you can't search monsters by category... well, not automatically. I suppose we could add that as another lookup type, if people like. Think the database should search in exactly the same way as the other additions.

As it stands, if your lookup fails to find an item or effect, or whatever category you're checking explicitly, with whatever name, it'll do a normal wiki search for the name, so it'll still be found. A failed category lookup is exactly the same as doing "wiki <search>" right now... Though a failed familiar lookup may eventually (in a few hours, if my brain cooperates) capitalize each word, which might screw up normal searches, or not, depending on the specific bizarre capitalization used on the KoLwiki.
 
Okay... here we go. New version of the patch that does the following:
SkillDatabase
- Made toTitleCase( string * ) a public function since it didn't conflict with anything and is great for calling familiars and other items that have every word capitalized
- Fixed a bunch of 8-space/tab issues from when someone with a bad text editor fixed new skill prices
WikiLookupCommand
- Added category lookups if you begin with one of the 4 category names: effect(s)/familiar(s)/item(s)/skill(s)
- Made it so that if you run a familiar category lookup, it automatically converts your search to title case, so that the redirect should actually link you to the proper familiar entry in the Wiki

For those who are curious, I did look into a monster search, but it proved resistant. The only monster lookup function appears to be findMonster, which returns a Monster type, not a list or string. Anyways, unless there's a same-named monster and item or effect, it redirects to the monster when it fails the prior search...
 

Attachments

Updated this, finally. It's currently my only uncommitted code and so I figured I'd take another whack at it. Finally got familiars fully sorted out, the skill check fully works, and so I got bored/intrigued and threw in outfits and monsters as well. So lookup monster principal takes me straight to the Principal Mooney wiki page. And no debug messages for screwing up and doing invalid (or not yet included in mafia) bits... it just throws your search to the wiki, like before.

Categories: Effect(s), Familiar(s), Item(s), Skill(s), Outfit(s), and Monster(s).

Trivia:
Original patch was submitted a bit over 3 years ago (2010-09-09 as compared to 2013-09-18).
The new patch is currently measuring at about 550 bytes smaller than the original patch, despite having two more categories. And, y'know, working. :)
 

Attachments

Fun bit. Mafia capitalizes all monster names. The wiki actually follows KoL's capitalization scheme which is what ends up in the session logs. Since mafia itself doesn't follow KoL's capitalizations, we don't know if we should capitalize monster names or not when we're trying to go to the wiki. Here's a version that does a lowercase search. It still fails on any monster that's capitalized, like the foodie giant, but at least it doesn't fail to find the filthy hippy or end up on the wrong page for the black cat monster.

Edit: Darzil and lost updated mafia's datafiles to follow KoL's capitalizations. This means that the lowercase patch is now not needed. Removing it.
 
Last edited:
I consider the wiki's "feature" that searches are case-sensitive to be a bug/unfeature, but I suppose that's out of our control.
 
At least in the search bar, if you enter it in all lowercase it will get you to the page, unless it has a lowercase at the beginning of a word but not all of them (e.g. "This Will Work", "This won't Work", "this will work").
 
Well, as of r12687, the post 5 patch should properly search monsters, since Darzil and lost worked to fix up monster names to match KoL's capitalization.

And that's not a bug/unfeature, since otherwise the Black Cat (familiar) and black cat (monster) would be overlapping, or require a disambiguation page. It's much better to be able to target the one you want directly. And with the post 5 patch, you can.
 
It would be nice when looking up the Crown of Thrones by hand to not need to worry about capitalization, given the lack of overlap.
 
Theraze said:
And that's not a bug/unfeature, since otherwise the Black Cat (familiar) and black cat (monster) would be overlapping, or require a disambiguation page. It's much better to be able to target the one you want directly. And with the post 5 patch, you can.
Click to expand...

You're welcome to your opinion, but no reasonable search engine relies on case sensitivity. The wiki should not have this unfeature just because KoL itself has it. Moreover, edge cases should be worked around, rather than the reverse. I cannot count the number of times I've typed in the name of a noncombat just to have the search fail because I did not capitalize it exactly.

I've learned that I should just use google to search the kolwiki because its lexer is actually sane.
 
Of course, if/when mafia actually has a noncombat store, you would be able to use this to go straight to the desired noncombat. If there was a to_noncombat() function or something similar that can query through it. That would just be search-type 7. Or 8. Or whatever we'd be up to. :)
 
"Things like This" is supposedly being fixed, although I haven't heard anything of it for a few weeks, so I don't know. In the mean time, some redirects were created (but no more should be added just yet), but if you feel you absolutely need one, go ahead. Make sure the redirects are all lowercase.
 
Updated this after Veracity's tweaking of the wiki lookup code. It's still my only uncommitted code. Still no debug messages for screwing up and doing invalid (or not yet included in mafia) bits... it just throws your search to the wiki, like before. With Veracity's updates, location searching now works... lookup location min camp takes me straight to the wiki page for the mining camp, for example. :)

Also, if you don't specify the category, it will just search items and effects. This could be tweaked if preferred... for that matter, it could be set through a user-configured preference so that people can decide which categories they'd like it to auto-check. But for now, it's hardcoded to keep everything nicely in a single file.

Categories: Effect(s), Familiar(s), Item(s), Skill(s), Outfit(s), Monster(s), and Location(s).
 

Attachments

Yesterday (or the day before) had some updates to the WikiLookupCommand file that broke merging in the category lookups. If memory serves, it was to make it not url encode and fix some other weirdness that the KoL wiki does, where they're less than accurate.

Anyways, here's the updated version.
 

Attachments

Broke again with the changes to the Effects. Updated again. Checked into using the ItemDatabase rather than ItemFinder, but that makes the fuzzy search break and lookup item elec knife will no longer find the electric boning knife, which is sad and one of my favourite parts of this.
 

Attachments

Nifty, thanks! It does make more sense to use readable names rather than the ints, but when I was first coding this up 4.5 years ago, I was still relatively new to Java and working in a different mindset. Heh. Anyways, hope this ends up being as useful for other people as it's been for me. :)
 
Did find one bug created by the change from the ints to strings. lookup flask hol used to fuzzy match to search items or effects for an entry matching flask hol... finding the flaskfull of hollow.

Now, when you lookup flask hol, it looks for an item or effect named hol, and discards the 'flask' part of the name. Specifically, this:
Code: 
		if ( index != -1 )
		{
			type = parameters.substring( 0, index ).toLowerCase().trim();
			target = parameters.substring( index + 1 ).trim();
		}
		if ( type == null || ( !type.startsWith( "effect" ) && !type.startsWith( "familiar" ) &&
			!type.startsWith( "item" ) && !type.startsWith( "skill" ) && !type.startsWith( "outfit" ) &&
			!type.startsWith( "monster" ) && !type.startsWith( "location" ) ) )
		{
			// No type specified
			type = "item or effect";
		}
Obviously what it does is looks for the first space and trims that as the type and discards it from the parameters. Unfortunately, it does it whether or not the type is actually a valid type... so if we're looking for a two+ word entry, we lose the first word. The easiest solution would be something like this:
Code: 
		if ( index != -1 )
		{
			type = parameters.substring( 0, index ).toLowerCase().trim();
		}
		if ( type == null || ( !type.startsWith( "effect" ) && !type.startsWith( "familiar" ) &&
			!type.startsWith( "item" ) && !type.startsWith( "skill" ) && !type.startsWith( "outfit" ) &&
			!type.startsWith( "monster" ) && !type.startsWith( "location" ) ) )
		{
			// No type specified
			type = "item or effect";
		}
		else if ( type != null )
		{
			target = parameters.substring( index + 1 ).trim();
		}
to only strip the first word if it matches one of your valid lookup entries, and not if you're trying to find a multi-word item.
 
You must log in or register to reply here.
Back
Top