Feature - Implemented Deal with commas in plural typed constants.

[zarqon]

A problem has arisen due to our new friendly warnings. There are 30 items, 34 monsters, 3 locations, and a whopping 50 effects with commas in their names. Now try to specify any of these correctly in a plural typed constant.

Without commas: $effects[ooh sweet!, ooh salty!, ooh bitter!]

Changing "ooh sweet!" to "Ooh, Sweet!" would get rid of this message (zlib.ash)
Changing "ooh salty!" to "Ooh, Salty!" would get rid of this message (zlib.ash)
Changing "ooh bitter!" to "Ooh, Bitter!" would get rid of this message (zlib.ash)

With commas: $effects[ooh, sweet!, ooh, salty!, ooh, bitter!]

Changing "ooh" to "Ooh, Bitter!" would get rid of this message (zlib.ash)
Changing "sweet!" to "Ooh, Sweet!" would get rid of this message (zlib.ash)
Changing "ooh" to "Ooh, Bitter!" would get rid of this message (zlib.ash)
Changing "salty!" to "Ooh, Salty!" would get rid of this message (zlib.ash)
Changing "ooh" to "Ooh, Bitter!" would get rid of this message (zlib.ash)
Changing "bitter!" to "Ooh, Bitter!" would get rid of this message (zlib.ash)

(Odd that "ooh" matches "Ooh, Bitter!" despite 5 matching effects, innit? I was expecting a "multiple matches" error, but either way, that's still an undesirable result.)

The next logical thing to try is quotes around the names: ash $effects["ooh, sweet!", "ooh, salty!", "ooh, bitter!"]

Bad effect value: ""ooh" (zlib.ash)

Veracity has suggested the following to fix this issue:

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 ()

She also suggested this very Feature Request, so I am hereby marking that part of her post Implemented.

 

[Fluxxdog]

Allow integers in plural typed constants

> ash $items[headpiece of the Staff of Ed,ancient amulet,2324]; //2324 is item number for "Staff of Ed, almost"

Changing "2324" 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

With the new work on matching, certain tricks used in the past show a "not quite right" message now, such as using just $items[almost] to list "Staff of Ed, almost => true". One way to alleviate this would be to use the item's hard coded integer value, but this also throws a "not quite right" message. Since integers have only one possible result, it would make sense to allow them to be an exact match, rather than flagging them as "not quite right". Soooooo... FReq!

 

[lostcalpolydude]

This change is as simple as adding a StringUtilities.isNumeric() check in a few places. However, I feel like having scripts use numbers instead of readable item names as a workaround for commas giving that message currently isn't the way things should go. On the other hand, I wasn't planning to look into comma support any time soon, and I think Veracity wasn't up for it either, so maybe this is the best option, given that these messages are in place.

 

[Bale]

zarqon and Fluxxdog have both offered potential solutions to the same problem. I merged these two threads since the problem only needs one solution.

Personally I favor the solution that zarqon and Veracity proffer.

 

[Veracity]

Alternatively, we could "escape" a comma while parsing the string, perhaps:

staff of Ed\, almost -> "staff of Ed, almost"

That would make the parsing a lot easier than having to recognize that we are accumulating characters within quotes.

I'm not enthused about this - it doesn't seem like "fun" coding - but I can't imagine either parsing change is all that hard. I'll see if I can get to it this afternoon.

 

[jasonharper]

Keep in mind that using double quotes to enclose constants that contain a comma will mean that you can no longer have a non-fuzzy match for any item that is actually enclosed in double quotes.

I'm pretty sure that you can already include a comma just by preceding it with a backslash.

 

[lostcalpolydude]

I'm pretty sure that you can already include a comma just by preceding it with a backslash.

> ash $items[staff of ed\, almost,334]

Changing "334" to "sabre teeth" would get rid of this message ()
Returned: aggregate boolean [item]
Staff of Ed, almost => true
sabre teeth => true

Looks like this is already implemented then.

 

[Fluxxdog]

Out of curiosity, is this supposed to work?

> ash $items[Staff of Ed\, almost]

Returned: aggregate boolean [item]
Staff of Ed, almost => true

Edit: Triple ninja'd. Dang.

 

[Bale]

Keep in mind that using double quotes to enclose constants that contain a comma will mean that you can no longer have a non-fuzzy match for any item that is actually enclosed in double quotes.

"

 

[Veracity]

Sweet!

OK, now we just need to make the "friendly message" include the backslash escaping for commas.

 

[Veracity]

> ash $effects[ooh sweet!, ooh salty!, ooh bitter!]

Changing "ooh sweet!" to "Ooh\, Sweet!" would get rid of this message ()
Changing "ooh salty!" to "Ooh\, Salty!" would get rid of this message ()
Changing "ooh bitter!" to "Ooh\, Bitter!" would get rid of this message ()
Returned: aggregate boolean [effect]
Ooh, Sweet! => true
Ooh, Salty! => true
Ooh, Bitter! => true

Revision 12282

 

[zarqon]

Splendid, I believe our friendly messages are all set now.

I would also like to mention that integers do NOT have only one possible match. Consider $item[668]. Using actual names is better.

 

[lostcalpolydude]

I would also like to mention that integers do NOT have only one possible match. Consider $item[668]. Using actual names is better.

I did consider that, actually. That matches item 668 and never checks to see if it matches an item name. $item[64067] just gives an error.