Feature - Implemented Friendly warnings for fuzzy matches in $type[]

[Veracity]

Ah. Are those "plurals"? OK. I was assuming you were talking about plural item names, say, and I couldn't think how an ASH program would present those to ASH itself such that ASH could suggest they be normalized.

Yeah, those should also generate warnings.

 

[Veracity]

> ash foreach f in $familiars[hobo mon, glutton, slime] print(f)

Changing "hobo mon" to "Hobo Monkey" would get rid of this message ()
Changing "glutton" to "Gluttonous Green Ghost" would get rid of this message ()
Changing "slime" to "Slimeling" would get rid of this message ()
Hobo Monkey
Gluttonous Green Ghost
Slimeling
Returned: void

Revision 12277

 

[zarqon]

I've seen them referred to as "plural typed constants", so I assimilated that into my KoLmafia jargon. Is there a better name?

Also thanks! Although now I have to update everything again!

ETA: There are a fair number of items which include commas in the name. This would cause problems when, for instance, specifying several boozes:

$items[Oh the Humanitini, Earth Wind and Firewater, Aye Aye Captain]

Note that I omitted the commas, because otherwise the items wouldn't be parsed correctly. However this will cause warning messages.

I tried including the commas and putting quotes around the item names but that didn't work.

Could we perhaps ignore commas in names?

 

[Fluxxdog]

Ran in to a possibly unique scenario. Cause is obvious. The comma screws with the parser.

> ash $items[headpiece of the Staff of Ed,ancient amulet, almost]

Changing "almost" to "Staff of Ed, almost" would get rid of this message ()
Returned: aggregate boolean [item]
headpiece of the Staff of Ed => true
ancient amulet => true
Staff of Ed, almost => true

> ash $items[headpiece of the Staff of Ed,ancient amulet,Staff of Ed, almost]

Changing "almost" to "Staff of Ed, almost" would get rid of this message ()
Returned: aggregate boolean [item]
headpiece of the Staff of Ed => true
ancient amulet => true
Staff of Ed => true
Staff of Ed, almost => true

Edit: Another interesting issue, if you use numbers, it flags them as erroneous.

Changing "2324" to "Staff of Ed, almost" would get rid of this message     (fluxxlib.ash, line 483)

Using the number directly doesn't seem like it should be flagged.

Edit edit: semi-ninja'd

 

[Veracity]

Looks like somebody would like to make a Feature Request to change acceptable syntax for plural constants...

 

[Bale]

Edit: Another interesting issue, if you use numbers, it flags them as erroneous.

Changing "2324" to "Staff of Ed, almost" would get rid of this message     (fluxxlib.ash, line 483)

Using the number directly doesn't seem like it should be flagged.

It does seem to me that $item[2324] should be either to_item(2324) or $item[Staff of Ed, almost] although that does fail with plural constants.

 

[zarqon]

We could use foreach i in $ints[1,2,3] to_item(i) to avoid the warning messages for plural constants that contain commas but that makes the script harder to read.

Worth considering as a temporary measure if those warning messages annoy you (as they probably should).

 

[Veracity]

I would suggest the following:

- change the parsing of the comma-separated list of objects in a plural constant to allow "" around an object name: $items[ "staff of ed, almost", ...]
- change the "this warning would go away" message for plural constants to put "" around the recommended object name if it contains a comma.
- optionally, delimit object names in the "friendly warning" with single quotes. So:

Changing 'almost' to '"Staff of Ed, almost"' would get rid of this message ()

Not that I am in the mood to go muck with the parser in Parser.parseString( Type type ) to effect those changes, at the moment. Perhaps a Feature Request would be in order.

 

[Razorsoup]

This is fun. Type "ash $items[headpiece of the Staff of Ed,ancient amulet,Staff of Ed, almost]" into the gCLI. You'll notice I replaced the comma with ",". The output will show

> ash $items[headpiece of the Staff of Ed,ancient amulet,Staff of Ed, almost]

Changing "Staff of Ed, almost" to "Staff of Ed, almost" would get rid of this message ()
Returned: aggregate boolean [item]
headpiece of the Staff of Ed => true
ancient amulet => true
Staff of Ed, almost => true

 

[Veracity]

Apparently I should do Unicode decoding of the input string, too, so we can see when people intentionally try to screw things up.

Edit: Is this an improvement?

> ash $items[headpiece of the Staff of Ed,ancient amulet,Staff of Ed, almost]

Changing "Staff of Ed, almost" to "Staff of Ed, almost" would get rid of this message ()
Returned: aggregate boolean [item]
headpiece of the Staff of Ed => true
ancient amulet => true

 

[Razorsoup]

Well, I was trying to see what would happen if I used the character entity for the comma (which I think is ',') instead of the comma itself to see if mafia would correctly interpret it as one item with a comma in it's name instead of two separate items. It did indeed see it as one but still didn't like the provided name.

 

[Veracity]

Yeah. But that is obviously not the "right" thing for a script to have to do.

 

[Palinathas]

I understand and appreciate the warnings, however I still get several warning that are not of the "friendly" type, and I am unsure what is triggering them (so I can either fix myself or pester someone else to fix). I get this after almost every adventure spent in the relay browser:

The string "Giant's Castle (Basement)" no longer matches a location name; use "The Castle in the Clouds in the Sky (Basement)" instead
The string "Giant's Castle (Basement)" no longer matches a location name; use "The Castle in the Clouds in the Sky (Basement)" instead
The string "Giant's Castle (Basement)" no longer matches a location name; use "The Castle in the Clouds in the Sky (Basement)" instead
The string "Giant's Castle (Basement)" no longer matches a location name; use "The Castle in the Clouds in the Sky (Basement)" instead
The string "Giant's Castle (Basement)" no longer matches a location name; use "The Castle in the Clouds in the Sky (Basement)" instead
The string "Giant's Castle (Basement)" no longer matches a location name; use "The Castle in the Clouds in the Sky (Basement)" instead
The string "Giant's Castle (Basement)" no longer matches a location name; use "The Castle in the Clouds in the Sky (Basement)" instead
the knob shaft
the knob shaft (mining)
Multiple matches against Knob Shaft.
the knob shaft
the knob shaft (mining)
Multiple matches against Knob Shaft.
the knob shaft
the knob shaft (mining)
Multiple matches against Knob Shaft.
the knob shaft
the knob shaft (mining)
Multiple matches against Knob Shaft.
the knob shaft
the knob shaft (mining)
Multiple matches against Knob Shaft.
The string "Outskirts of The Knob" no longer matches a location name; use "The Outskirts of Cobb's Knob" instead
The string "Outskirts of The Knob" no longer matches a location name; use "The Outskirts of Cobb's Knob" instead
The string "Outskirts of The Knob" no longer matches a location name; use "The Outskirts of Cobb's Knob" instead

If anyone has any clue what triggers these, please let me know. Thanks!!

 

[zarqon]

It's probably from you having an outdated clover_adventures.txt for BatMan RE, considering that those locations appear exactly that amount of times in the file. I uploaded an updated version to the Map Manager the same day the friendly warnings were added, so the next question is, why hasn't your copy autoupdated yet? Did you disable the update somehow?

 

[Palinathas]

That does seem to be the file. My copy was dated 6/18. I don't recall ever turning off updating. I deleted the offending file, and it auto-updated itself the next turn. Thanks Zarqon! I was going nuts trying to find the offending file.

 

[slyz]

Would anyone mind if I turned this into a hidden opt-in feature?

 

[Veracity]

Why?

The way it is now, every script that uses a constant that might become ambiguous - and hence a hard compile error - gives a message the first time you use the script during a session, and tells you exactly what to fix to future-proof the script.

Seems to me, this feature gives people a chance to fix things BEFORE they become a hard compile error, rather than having it hit you like a meteor when KoL changes content.

So, what's the benefit to disabling it?

 

[Bale]

I believe that slyz's concern is that it is a tremendous help to scripters to catch their potential errors while having every tom, dick and user aware of the issue leads to a bajillion and one error reports for very little advantage. It does get annoying knowing these "not an error" could be fixed several weeks from now without a problem, but we are "forced" to do it right now to avoid troubled posts.

Of course, this is a transitory thing resulting from the fact we're just now adjusting to the change. In the future it will be helpful that it is not opt-in because we might forget to turn it on and it is really damn useful for future proofing KoLmafia.

Of course I could be wrong about slyz's concern, since that's just my own misgivings and conclusion.

 

[Atheist Nutter]

There are three types of script users:
(1) People who write scripts for their own use
(2) People who write scripts and distribute them for others to use (and probably use them themselves)
(3) People who get their scripts from the people in (2)

Type (1) people might be very proactive and paranoid and want to fix errors before they occur, although probably not because they can just fix the errors if and when they come up. Type (3) people can't fix the warnings themselves because they don't write the script (and fixing them locally is pointless). So I can only see this being useful to the type (2) people.

As a type (1) person who doesn't like to fix problems that don't even exist yet, giving me a way to turn this off would be adequate and making it opt-in would be even better.

 

[zarqon]

I don't buy that they're not useful for type 1 people. These people (which includes me) realize that the messages are mostly harmless, and not cause for concern. Plus I think the fact that they only happen once per session per script is reasonable -- if you don't like those messages the first time you run a script, you can change it, but if you don't, it's not going to bug you for the whole session.

More importantly, they help you script. As I was working up the code for OCW's new item turnin function, I had something that included $coinmasters[Dimemaster,Quartermaster]. Seems legit, right? But then:

Changing "quartermaster" to "A. W. O. L. Quartermaster" would get rid of this message

Oops, looks like I was using the wrong name! Without the warning, mafia would have been quietly matching something totally different than I'd intended. It would have taken me much longer to find this bug if I had disabled the warnings.

And for type 3 people: it's only annoying now because locations keep getting changed one by one. That will calm down as the location names finally stabilize. A little patience, and soon you'll forget these warnings ever caused you discomfort.