Feature Matching items of a specific type in ASH.

M

Miser

New member
Certain CLI commands, such as equip, match only items of a certain type, so that for example "equip mayfly" knows to equip the "mayfly bait necklace" and not the "packet of mayfly bait". However, I have found no way to replicate this in ASH. Would it be possible to expose this functionality?

If anyone wonders why I'm asking for this, I'm trying to make a command to more easily equip multiple items at once. So if I want to equip the personal ventilation unit and the mayfly bait from the CLI, I can type "eqq vent, mayfly" and it will equip both items in different slots. This is faster than "equip acc1 vent; equip acc2 mayfly" or something like that. Using "to_item" fails here, and I have to e.g. type "mayfly necklace".
 
Changes have been made in the past to discourage using partial names of items/effects/etc. This would be the opposite of that. There isn't a good reason to rely on fuzzy matching in a script, so this looks like a bad idea.
 
Thanks for your reply.

It wasn't my intent to hardcode partial item names into a script, but to find items based on user input from the script invocation. The script I was writing is meant to be invoked from the command line with multiple equipments as arguments, where using fuzzy matching is useful.

I understand however if you think this feature is unnecessary or harmful.
 
If you want fuzzy matching, then use cli_execute( "equip xxx" ) rather than equip( xxx ).
I understand why you want to stay within ASH, but this is a situation where you can't do what you want by doing so.

I could see having an ASH function: item fuzzy_match( STRING, STRING ) where the first is the user input and the second is a "type" of some sort, but changing the equip() function to do fuzzy matching isn't going to happen.
 
There is already a function to fuzzy match items. It is to_item(string).

Code: 
[COLOR="#808000"]> ashq to_item("Mayfly").print()[/COLOR]

packet of mayfly bait

equip( to_item("mayfly") ) works fine and it isn't even much more troublesome to use to_item("") rather than $item[].
 
Last edited:
Well, perhaps what he wants is to_item( string, string ), where the second parameter is a "filter" - which is passed to the same fuzzy matcher that equip, use, drink, etc. use.

Code: 
	public static final int ANY_MATCH = 1;
	public static final int FOOD_MATCH = 2;
	public static final int BOOZE_MATCH = 3;
	public static final int USE_MATCH = 4;
	public static final int CREATE_MATCH = 5;
	public static final int UNTINKER_MATCH = 6;
	public static final int EQUIP_MATCH = 7;
 
> ash to_item( "mayfly" )

Returned: packet of mayfly bait
Click to expand...
Given that, I'm not sure why "equip( to_item("mayfly") )" would work, since a "packet of mayfly bait" is not equipable.
 
Huh. That *is* interesting. And that, is why I try not to rely on fuzzy matching when I am scripting.
 
Veracity said:
Well, perhaps what he wants is to_item( string, string ), where the second parameter is a "filter" - which is passed to the same fuzzy matcher that equip, use, drink, etc. use.
Click to expand...

Yes, this is exactly what I had in mind. Thank you for putting it much better than I could. Of course, I can do with just the current "to_item", I just have to relearn how much I need to type for each item, and I thought this might be useful for other applications as well.

The reason I can't use cli_execute is that in my script I need to find the equipment slot of the item, so I can ensure that accessories / 1-handed weapons are equipped in different slots.
 
That's no reason that you cannot use the cli_execute.

Code: 
slot s = $slot[acc2];
cli_execute("equip " + s + " mayfly")

Though that is sloppy as heck. Why not just use the proper name of the item?
 
I can equip to a particular slot, but I can't figure out whether a string corresponds to an accessory to begin with. I want the script to work with other types of equipment as well. Also, my script receives user input, and it is inconvenient to always type the full name into the command line.

For example, I might want to write
Code: 
eqq iflail, iflail, conflict, fuzzy slippers, red shoe
in the CLI in order to maximize +nc, and the script should equip each item in a different slot. (I think this example works with the current to_item.)
I have attached the script in its current form, maybe my intent will be clearer that way.
 

Attachments

Quite clear now. I can see why you need to make use of mafia's fuzzy matching to convert text into items. That's necessary in order to check the slots that the items occupy, not just to use the equip command.

Veracity, what do you think about creating that fuzzy_match() function so that he can do a EQUIP_MATCH to ensure he matches equipment? It would improve his chances of matching the right item. He's got an actual implementation for it, after all. No doubt that is the reason equip will match "mayfly" to the necklace even though to_item("mayfly") will match it to the packet. That's just not good enough for his needs.
 
Bale said:
Quite clear now. I can see why you need to make use of mafia's fuzzy matching to convert text into items. That's necessary in order to check the slots that the items occupy, not just to use the equip command.

Veracity, what do you think about creating that fuzzy_match() function so that he can do a EQUIP_MATCH to ensure he matches equipment? It would improve his chances of matching the right item. He's got an actual implementation for it, after all. No doubt that is the reason equip will match "mayfly" to the necklace even though to_item("mayfly") will match it to the packet. That's just not good enough for his needs.
Click to expand...
I've been thinking about this again, now that I have thinking about the "eat" and "drink" commands needing to be able to match on consumables, not items.

The way our fuzzy matching works, we require a sorted array of "canonical names" - lower cased, etc. Given those names, we need to be able to map them back to the "real" name. So, when searching items, if you have "game token", that should match to "game grid token" in the item array, and you'll get back "Game Grid token".

So, what about Darzil's current project to allow item numbers rather than item names? Without that, what should you get when you search for "Staff of Ed"? I don't have an answer, yet, but am watching how it develops.

The thing is, we could & should have multiple "canonical name arrays" - one for each kind of fuzzy matching we want to do. Additionally, we may want to filter the results of such a match, depending on the purpose. Here are some examples:

"item" - search all items, no filter
"inventory" - search all items, filter on inventory
"closet" - search all items, filter on closet
"storage" - search all items, filter on storage.
"accessible" - search all items, filter on those which "is_accessible" matches - inventory, closet (if use closet is allowed), storage (if not Hardcore or Ronin), and so on.

So, the "pull" command would do a "storage" search - any item is allowed, but those not currently in storage will not cause ambiguity. The "closet take" command does a "closet" search, the "closet put" or "autosell" do an "inventory" search, and so on.

"use" needs "accessible", since it will "acquire"

How about subsets of items?

"equipment" - have a smaller "canonical" array with just equipment, or is this a filter?
"hat", "pants", "weapon", "off-hand", "shirt", "back", "accessory", "familiar item" - filters, I assume

"equip" wants the "equipment" matcher and the "acquirale" filter.

How about consumables?

"food", "drink", "spleen" - for use by "eat", "drink", and "chew" commands. These are not just items! It will be nice to have food items + chez snootee + hot dogs + sushi all be matchable.

Non-items?

"skill" - for "cast"
"familiar" - for "familiar"
"thrall", "servant", ...
"outfit"
"effect" - for "uneffect" or "up".

What about "creatable", for concoctions?

So, perhaps we want three arguments:

table: "item", "skill", "effect", "familiar", "thrall", "servant", "equipment", "food", "drink", "spleen"
filter: "accessory", "hat", ... (for the "equipment" or "item" tables)
location: "accessible", "inventory", "closet", "storage" (with "any" as default") (for the "equipment" or "item" tables).

I'm going to work on adding "canonical name" arrays for consumables, soon, so that "eat" will be able to find sushi, for example. I expect that regularizing the fuzzy matching library - which is currently partly in StringUtilities and partly in ItemFinder - will be a natural followup to (or part of) this. And then fixing the CLI commands to use it appropriately, and adding the ASH facility.

There's more design to be done, first.

And comments from y'all, here. ;)
 
Veracity said:
So, what about Darzil's current project to allow item numbers rather than item names? Without that, what should you get when you search for "Staff of Ed"? I don't have an answer, yet, but am watching how it develops.
Click to expand...
I am mainly trying to ensure internal consistency, so we don't get item A with name XXXX confused with item B with name XXXX when passing items between functions.

However, I'm also seeing that what would be good to end up with is something where we use id's internally (where possible, so make some for pseudo-items, use them for items, effects, skills, outfits), and can define datafiles using either name or [id]name where names aren't unique. We then would want something like ItemFinder or your Canonical name arrays for the user interface side, and the ability to specify items/effects etc uniquely by name or id using ash data types.

I think the work I'd doing should end up with the internal and ash side.

I think we may want, at some level, some context sensitive handling. I'm not 100% sure where we'd prefer it, maybe in the ItemFinder / Canonical name array, and maybe we'd want to switch it on or off somehow. This would then recognise Staff of Ed appropriately, either because only one is in the database, or because only one is in the ItemFinder / Canonical name array. Ditto for some other things, like the Staff components and A Little Bit Evil. Basically those things that we can only have one of at a time. We'd have to rebuild it upon dropping Avatar path or changing class after one.
 
You must log in or register to reply here.
Back
Top