Fuzzy matching change

Fuzzy matcher.

With the recent changes to fuzzy matching in the CLI I find myself wishing it just worked the way it used to.
I assume that the ash still has fuzzy matching.
Would it be possible to write a namespaces script which replaced all the cli commands so that they used fuzzy matching in the ash and thus magically the CLI would appear to work as it used to?
Would this work for CLI scripts?

Re: Fuzzy matcher.

Ash does not have fuzzy matching now as well - Most of the ash commands that exist in cli merely work as wrappers for their cli equivalent, they effectively call the cli command internally, so - no this would not work !

Tom  

Re: Fuzzy matcher.

What are you missing?

Just to check, is "alias mmj => magical mystery juice" a CLI command that I can put in a login script?

I spend a lot of time in the relay browser with the gCLI, and while I generally rely on substring matching, I do use a few fuzzy things like "use 1 mmj." I don't have a list of these abbreviations in my head. But if whenver I bork on one, I can easily add it to an "on login" script (implied by Veracity's post), all will be well in my little world.

Alias once, a file will get generated which should remember them forever.

Edit: Simple abbreviations like 'mmj' should pass the fuzzy match filter now.

[quote author=holatuwol link=topic=1554.msg7385#msg7385 date=1204143539]
Alias once, a file will get generated which should remember them forever.[/quote]
In fact, until the revision I just checked in - 5833 - I don't think that re-aliasing worked; KoLmafia would apply the first alias to the command which attempted to define it a second time.

Re: Fuzzy matcher.

[quote author=tebee link=topic=1554.msg7377#msg7377 date=1204124637]
Ash does not have fuzzy matching now as well - Most of the ash commands that exist in cli merely work as wrappers for their cli equivalent, they effectively call the cli command internally, so - no this would not work !

Tom
[/quote]

What about things like string_to_location("castle") or $location[castle] or string_to_item("bitch")?
Will these still be resolved with fuzzy matching?

Please read page 1 for details on the difference between fuzzy matching and substring matching. =) Substring matching has not changed at all; fuzzy matching is what kicks in when substring matching fails.

Okay I read the early posts again and I'm sorry my previous examples were not good ones.
If I were to use string_to_item("disclover") would that return the item disassembled clover?

string_to_item() uses the same logic used by the CLI to figure out which item you're referring to. So the answer to your question is 'no', you can't use ASH to bypass any of the changes being made to how the CLI is parsing items.

I'm still in the process of refining fuzzy matching to match its most common uses while still minimizing the side-effects of bug reports (it started out as something extremely strict; currently, it's something that is still likely to result in bug reports). So, if you list your most common expected fuzzy matches, that will give me something to base the changes on.

[quote author=holatuwol link=topic=1554.msg7385#msg7385 date=1204143539]
Alias once, a file will get generated which should remember them forever.

Edit: Simple abbreviations like 'mmj' should pass the fuzzy match filter now.
[/quote]
Thanks Holatuwol. Between these two things, I don't expect any usability difficulties. (too bad I can't say the same about your problem of erroneous bug reports).

[quote author=holatuwol link=topic=1554.msg7403#msg7403 date=1204226143]
string_to_item() uses the same logic used by the CLI to figure out which item you're referring to. So the answer to your question is 'no', you can't use ASH to bypass any of the changes being made to how the CLI is parsing items.

I'm still in the process of refining fuzzy matching to match its most common uses while still minimizing the side-effects of bug reports (it started out as something extremely strict; currently, it's something that is still likely to result in bug reports). So, if you list your most common expected fuzzy matches, that will give me something to base the changes on.
[/quote]

Thankyou for your answer. My initial reaction of panic and dismay at this change was due in part to not knowing there was substring matching (that isn't changing) and thinking that full names would need to be used.
Before reading this I was just starting to think that the answer was probably going to be no, but with some fuzzy matching and a few aliases the cli would be quite usable, then something funny happened in my HC run...

I typed: "use 5 ointments" (instead of ointment) and mafia dutifully attempted to buy and use 5 forged identification documents. I had to laugh. How ironic.
;D heh,heh,heh, oh wait... my meat :-[

Yeah, those are the cases I'm trying to prevent. =) So far, most of the cases are handed, but there are a few edge cases I'm having trouble with.

My first thought would be to check both the typed string length vs. potential match string length & amount of whitespace typed vs. match, but I don't know what java's string-parsing functions are like overhead-wise so I wouldn't be surprised if this has been considered and dismissed. Just a thought from someone who doesn't really know what he's talking about.