Bug - Fixed Undesirable Fuzzy Matches

Just because you asked me to, Ver

Currently "cast canta" matches "Inigo's Incantation of Inspiration" instead of "Carlweather's Cantata of Confrontation", and apparently a CCS of "noodles" now chooses "noodles of fire" instead of "entangling noodles".

Not the most likely matches, I think.

Fuzzy matching has always been a problematic two edged sword. These are far from the first confusing matches, they're just of interest because they are matches that have been dependable for a long time, until now.

I suppose for canta, it could choose the start of a word as being preferable to the middle of a word, but there's no possible rule for thinking that noodles is more likely to mean entangling noodles. If anything, noodles of fire is a more likely match since it is matching the very first word in the name.

If it matters -- personally, I would rather have a consistent system than a system with exceptions.

I would prefer a system where mafia doesn't guess at which one you mean, and instead complains about it being ambiguous. Also, for familiars, "pixie" matches coffee pixie over green pixie. "tongue" matches Tongue of the Otter over Tongue of the Walrus.

What's the problem with that? So you know which one a given string matches and you can be more specific if necessary. This is a potentially automation-breaking change you're proposing. Mafia suddenly complaining about things that it used to match to the user's satisfaction would be just as annoying as a user_confirm() popup for version checking.

So it's better that the addition of Inigo's to KoL break anything that uses "canta" by casting the wrong buff instead of stopping and saying that "canta" is ambiguous? I think writing a script that you plan to use on a regular basis that doesn't use the entire name of items/buffs/whatever is a bad practice, because kol will eventually update and mafia will punish you for it. If there was formerly one match, and now there are two potential matches, both answers are wrong for mafia to pick. To rephrase what you said, Mafia suddenly doing stuff that a user really doesn't want it to do would be more annoying than a user_confirm() popup for version checking.

Yes, and if it's KoL's fault that's fine. They're always breaking mafia anyway.

If I've been typing "cast canta" for the past year, and it cast cantata just the way I want it to, and then suddenly it start's casting Inigo's, I consider that to be mafia's fault, not KoL's fault. Mafia's guessing at which skill to cast makes the "cast" command less useful.

Edit: If I used KoL's chat command of "/cast canta" for a long time and suddenly it becomes ambiguous (I just use Inigo's today), KoL tells you it's ambiguous and doesn't cast anything.

zarqon said:

Yes, and if it's KoL's fault that's fine. They're always breaking mafia anyway.

Click to expand...

That's an interesting take on it. It's also wrong.

In-game: "/cast cantat" produces "Too many skills found, be more specific: Inigo's Incantation of Inspiration, Carlweather's Cantata of Confrontation."

By your logic, KoL would be breaking itself, which is clearly not true in this case. It's on the user to be more specific.

Mafia not handling things the same way as KoL is an issue on Mafia's end, not KoL's. KoL already has a system in place for that.

If you had a KoL chat macro that was like.. "/com" = "/cast musk && /cast canta" Then it would no longer behave like before in KoL, it wouldn't do what you wanted, because a slight game change made "/cast canta" ambiguous. There is a system in place to handle it, it doesn't guess or assume it knew what you meant if what you said was an ambiguous statement, even if it wasn't before.

One suggestion I made to CDM in-game was whenever an ambiguous /cast or /use came up, the game should produce the output, but with some clickable links to use the item or cast the skill that way, so it'd have "Too many skills found, be more specific: Inigo's Incantation of Inspiration, Carlweather's Cantata of Confrontation." with the two skills being links, when you click on one of them, it casts that skill, so you don't have to re-type it. Mafia could consider doing the same thing when you tell it something ambiguous. An easy fix when someone inputs something ambiguous. Also they can figure out a better way to say what they want to say, and have it not be ambiguous.

I'm all for fuzzy matching picking an unambiguous choice, but simply picking one when there is ambiguity is wrong.
I believe there are some CLI commands dealing with items that behave that way already. Skills should too.
(Skills AND items should presumably behave that way in a CCS, too, but you get immediate feedback there if the wrong choice were chosen, without actually using the item or skill.)

My opinion (which has now been slightly misrepresented) is simply that users should not be protected from their own ambiguities at the cost of abort errors. But as I'm clearly in the minority on this, I shall gracefully bow out.

*gracefully bows out*

I think it's fair that mafia should try to avoid doing anything that might not be intended. In case of ambiguity, it's better to ask for a clarification than to keep running, especially since the changeable nature of KoL means that something unambiguous today could become ambiguous tomorrow (as happened with noodles and inigo).

Ok, so HOW exactly should it ask for clarification for CCS actions? Keep in mind that any number of ambiguities can exist at the moment a CCS is initially loaded or saved, which is the point at which the actions are parsed. Do you really want to be stuck in an uninterruptible series of dialog boxes?

For CCS actions, I am content to let it pick any - or even "attack". You can see what was wrong immediately when you save it.
For "cast" from the CLI, I think it should tell you when something is ambiguous.

The CLI should fail to act, like the in-game chat macros.

The CCS, there are several options (including leaving it as it is) but if I were doing it, I'd probably make it work as now when parsing but highlight lines with a possible ambiguity in (say) red. With significantly more effort, you could have a drop-down to disambiguate but I'm not sure if that is really worth doing.

Ok, in r8235 an ambiguous skill like "cast cantat" or "cast tongue" will print a list of matches and generate an error. In a CCS, an ambiguous or unrecognized skill will turn into a "note" action that you can edit to fix the problem, rather than an "attack" that leaves you with no indication of what you were originally trying to do.

I have no idea how we're supposed to mark bugs as fixed in this brave new world of forum-based reports.

jasonharper said:

I have no idea how we're supposed to mark bugs as fixed in this brave new world of forum-based reports.

Click to expand...

There's a "Bug - Fixed" prefix that you could set for the thread, along with some others that look useful.

I'm not seeing any option to change the prefix on an existing thread...

You sure jason? You should have the option to edit it.

It's under Administrative at the top of the thread, click edit thread and you should be able to change it.

r8322

I neglected the final hyphen when trying to use the chef-in-the-box I had on-hand and mafia went into trying to use a clockwork chef for me. Having buy from mall disabled saved me from undesired purchases, an ambiguity check would have been preferred...