Feature - Implemented Fuzzy matching of the names of speakeasy drinks

ereinion

ereinion

Member
I saw that the new content thread was closed, so I'm making a feature request here.

I tried drinking a Lucky Lindy from the gcli today, and it failed until I matched the name completely (bar capitalization). Could some sort of fuzzy matching for the names of the speakeasy-drinks please be implemented?

Code: 
[COLOR=olive]> drink lucky lind[/COLOR]

[COLOR=red][lucky lind] has no matches.[/COLOR]

[COLOR=olive]> drink lucky l[/COLOR]

[COLOR=red]lucky lighter is not an alcoholic beverage.[/COLOR]

[COLOR=olive]> drink lucky lindy[/COLOR]

Visiting Speakeasy in clan VIP lounge
You gain 4 Adventures
You gain 1 Drunkenness
You lose some of an effect: Ode to Booze
You lose 500 Meat
 
Maybe not. Fuzzy name matching isn't only for items; we do it for Pasta Thrall types, for example. PastaThrallData.java does this:

Code: 
		// Do fuzzy matching
		List<String> matchingNames = StringUtilities.getMatchingNames( PastaThrallData.CANONICAL_THRALL_ARRAY, type );
		if ( matchingNames.size() != 1 )
		{
			return null;
		}

		String name = matchingNames.get( 0 );
We could easily make canonical name arrays for speakeasy drinks (and hot dogs) and attempt to match the user input with those before doing general item name matching.

Now, if we wanted to integrate the speakeasy drinks with items, in case your abbreviation names a speakeasy drink and also a regular booze item, yes - we need pseudoitems for the speakeasy drinks.
 
I'm been thinking on this more. The UseItemCommand - which is what does the "drink" command - is complicated. It starts out by seeing if you the item is an exact match for what's in a Cafe (Chez Snootee, Microbrewery, Hell's Kitchen) or a clan vendor (Hot Dog Stand or Speakeasy). If so, it gets it from there and is done. If the item cannot be found in one of those places, it looks it up in the item database, filtering based on command (drink gets booze, eat gets food, etc.), doing fuzzy matching. There is then a complicated loop in which it will try to find things in inventory, or acquire them, or what have you.

Speakeasy drinks have actual item numbers, as it turns out. So, presumably we could use the fuzzy matching for items, filtered by booze, to allow it to find "lucky", say. But consider: what if you ask for "thermos"? Is that a "thermos of "whiskey"" or a "thermos full of Knob coffee"? For that matter, if I am in Bad Moon and say "drink 1 Imp Ale" - or in Canadia or gnomes and ask for what happens to be the daily special at Chez Snootee or the Microbrewery - are you SURE that you want to buy the item from the Cafe rather than using an item you have in inventory? That's the way it works now.

We could rework how this command works - and hopefully make the code a lot clearer - to search for any items that are in the item table - which will include Speakeasy drinks - and understand that some such items cannot actually appear in inventory. That may already Just Work; can't you "eat <sushi item>"? Actually, that probably works because SUSHI is a creation method and we are willing to eat it via creation. We'd still need to dispatch to the Clan Lounge to get speakeasy drinks - or hot dogs, once we make them pseudo items.

In any case, this could be fixed to work correctly for Speakeasy drinks without doing the whole registering pseudo-item thing.
 
Interesting, I suspect we may need to change the way they are handled in a few places now. They are tradeable and discardable (but can never be traded or discarded), and I suspect the code that checks if they are items and only if not checks if they are Speakeasy drinks will also need to change.

Will look into the latter, anyway
 
Yeah. I think this is a foreshadowing of the kind of issues we'll have if we ever do pseudo-items (negative item numbers, or what have you) for Cafe offering, as proposed elsewhere.

The various Sea maps are also "tradable and discardable" but cannot appear in inventory. I see that we have a method - ItemDatabase.isVirtualItem - which only has those maps, at the moment. I am sure we should add the Speakeasy drinks to those. Perhaps we could add a boolean - AdventureResult.virtual - which is initialized to the result of that method, and the places where we check for an AdventureResult should be "item != null & !item.isVirtual()" or something.
 
Have moved the Speakeasy VIP/BadMoon/number remaining checks to DrinkItemRequest.maximumUses from Maximizer. Let me cut out a larger section of Maximizer code, as (I hope) the other checks are already handled correctly (Jarlsberg/KOLHS/Inebriety).

I think I'd like (for virtual items, I like that idea - maybe we can (when we give them pseudo numbers) add all concoctions that don't have item numbers, and speakeasy drinks, to those) things to show in Item Manager as Hot Dog (1 possible), Speakeasy Drink (Y meat, X possible), and Restaurant as (Y meat). Currently Hot Dog just shows (1), Speakeasy drink (Y meat, 0 current), and Restaurant as (Y meat). So we'd move it to virtual items showing cost (if there is one), and number possible (if limited).
 
Last edited:
For what it's worth you cannot do "eat <sushi>" or at least couldn't when I last tried it (for the sushi.ash script). You can "eat" the basic fish meats but for the rest you need to call "create <sushi>" for it to eat it (which confused the hell out of me before I realised that was what I had to do).
 
Revision 14838 does fuzzy matching of speakeasy drinks. It does this before going on and looking for other drinks, so if you type something which uniquely matches a speakeasy drink but also might match a non-speakeasy drink, it will take the speakeasy drink.

That's not perfect, but I decided to get this in now do that people can do:

drink glass of "milk"

even though the actual name uses HTML character entities.
 
You must log in or register to reply here.
Back
Top