Bug Bad match for candycaine when parsing inebriety.txt

[Crowther]

Personal build: r11436

I'm not sure this counts as a bug, but it's certainly unexpected behavior.

The drink "candycaine" never existed as an item, but is in inebriety. It matches "candycaine powder", which confused my script.

Attached is part of my script showing how I ran into this problem.

 

[Fluxxdog]

http://kol.coldfront.net/thekolwiki/index.php/Candycaine

 

[Darzil]

Well, as Fluxx shows, Candycaine existed (sort of, it was never a physical item).

However, your script appears to be finding "candycaine powder", rather than "candycaine" in inebriety, resulting in : Not a drink: candycaine powder.

Is your bug that candycaine powder appears to appear in inebriety, despite not being a drink ?

 

[Veracity]

Not everything in inebriety.txt is an item. Your script does this:

    int [item] inebriety;
    file_to_map( "inebriety.txt", inebriety);

Everything which is not an item - including things that you can currently get, such as petite porter - will map into $item[none]. The exception would appear to be candicaine, which, because file_to_map does fuzzy matching, gets converted into $item[candicaine powder].

So, which is the bug:

1) your declaration of the map for reading inebriety.txt as

int [item] inebriety;

rather than

int [string] inebriety;

2) the fact that file_to_map() does fuzzy matching when reading items, rather than requiring that you have a fully specifified canonical name for the item.

1) is certainly a bug, since the first field of inebriety.txt is NOT an item - it is the name of a kind of booze, which may or may not be an item. (Note that fullness.txt is also like that, since it includes, among other things, sushi).

2) might be a bug as well. We do fuzzy matching converting strings to other data types, since the string might have come from user input, and that is when fuzzy matching is intended to be used, but allowing non-exact names for items in ASH program text or data files seems like it is being (too) tolerant of sloppy code.

 

[Bale]

> ash print(to_item("candicaine"))

Candicaine
Returned: void

> ash print($item[candicaine])

Candicaine
Returned: void

Just sayin'. I do understand why people would feel that fuzzy matching on a text file would return the same result.

 

[Veracity]

OK. So you are saying that the only bug is #1 - a bug in the script, not in KoLmafia's fuzzy matching.
I can agree with that.

As I said, the first field of inebriety.txt and fullness.txt is a string - the name of a consumable - not an item. The consumable MIGHT be an item with an item number, but is is not guaranteed to be such.

Actually, now that I look at your test, I see that "candicaine" is, in fact, an item. It's a Happy Medium drink. Let's try it with the actual non-item in question.

> ash print(to_item("candycaine"))

candycaine powder
Returned: void

> ash print($item[candycaine])

candycaine powder
Returned: void

It works the same in both cases. I am sure that that reading from a text file does that, too. Especially since that is what the OP reported.

I am confused about what you are "just saying". Help?

 

[Winterbay]

I find it interesting that the same commands used gives different results for Bale and Veracity. Why is that? (At least I can't see any difference in the commands used while the result varies...)

Edit: Ahh, the difference is in the spelling of candycaine...

 

[Veracity]

That is correct.

Candicaine is item #5632. It is a siphoned spirit from the Happy Medium.
Candycaine was a drink offered in Crimbo Town in 2005 and 2006. It was item #-5. Which is to say, a pseudo item.

If you try to coerce "candycaine" into an item, it does not find an exact match on the non-item #-5, since that's not in the data files, but, instead, fuzzy matching returns item #5413 - "candycaine powder".

Which is to say, fuzzy matching is working correctly.

Edit: Look at this:

> ash ( to_string( to_item( "candicaine" ) ) == "candicaine" )

Returned: true

> ash ( to_string( to_item( "candycaine" ) ) == "candycaine" )

Returned: false

You can tell that fuzzy matching kicked in for "candycaine".

> ash to_int( to_item( "candycaine po" ) )

Returned: 5413

> ash to_int( $item[ candycaine po ] )

Returned: 5413

You can also tell that ASH does fuzzy matching even in $item constants. That surprises me. I could have sworn that we it do exact matching a while ago, since not using the exact name in a script is, basically, laziness; I can see the point in user input, but putting a fuzzy string into a script is begging for trouble when a new item is introduced that invalidates the fuzzy string.

I could have sworn we fixed that. I remember the discussion. Huh.

Edit 2: Well, perhaps I was remembering disallowing non-ASCII characters in $[] constants. The ASH parser just calls DataTypes.parseValue( type, input, false ) to parse those constants. That is the function which is also used to parse user input and in to_item() and such, so it does fuzzy matching.

Fixing ASH to disallow fuzzy matching for $[] constants would undoubtedly cause screams of outrage, at this point.

 

[Catch-22]

I am confused about what you are "just saying". Help?

I believe Bale was under the impression that $item["candicaine"] does not produce a fuzzy match, which is true (it exactly matches). I think he was confused though, as OP was talking about $item["candycaine"] which fuzzy matches to $item["candycaine powder"].

Perhaps a way to declare that the item should not be fuzzy matched is in order? Similar to how searching for a term in "double quotes" in the mall tab doesn't get fuzzy matched. $item["\"candycaine\""] looks very damn confusing though. Anyway, once that is done, you could make file_to_map use non-fuzzy matching when populating the map.

 

[Bale]

Well that settles my misunderstanding. Thanks for explaining the difference between candicaine and candycaine.

Fixing ASH to disallow fuzzy matching for $[] constants would undoubtedly cause screams of outrage, at this point.

It would, but I think I'm pretty much immune to that now. Once in the past I got in trouble when a new item was added to the game so since then I try to always use the full name of items and locations in my constants. That's why none of MY scripts broke when KoL added flameface's castle to the game and suddenly $location[castle] became ambiguous.

Actually, that is a pretty good argument for disallowing fuzzy matching for constants. It would save us from spontaneously broken scripts whenever KoL adds new items and locations. The price is that most scripts would break now.

 

[Theraze]

We've already put warnings into scripts that boolean functions returning void will become an error... why not present an aggravating (different A word choice ) message every time the fuzzy matcher gets used in ASH? Scripts will keep working, but we'll get an explicit "script needs to get updated" message, and we can turn off the fuzzy matching entirely in a major release or two.

 

[Catch-22]

I actually use fuzzy matching a lot (due to laziness), although I probably wouldn't in a production script.

 

[heeheehee]

I use fuzzy matching in scripts mainly because I'm too lazy to write a major mode for ASH, and apostrophes in literals tend to break highlighting all over (so I type "$location[Giant Castle]", e.g.). So yeah, I'm also in the "lazy" camp, but with slightly different motivation.

 

[fronobulax]

I'd love to say no fuzzy matching in ASH because it makes scripts robust and unambiguous but as long as there are items in KoL that use characters I cannot remember how to generate from my keyboard, I know I will fuzzy match rather than figure out the escape codes I need to embed in a script or when I am manually editing an external file with, for example, item names, that will be read and processed by ASH.

 

[Veracity]

ASH already rejects non-ASCII characters. Perhaps you mean that you cannot remember HTML character entities.