Bug - Fixed Cannot handle modifiers for effects/items whose name differs only in case

Veracity

Veracity

Developer
Staff member
There are three, so far:

Items:

sweet tooth
industrial strength starch
Knob Goblin perfume

Effects:

Sweet Tooth
Industrial Strength Starch
Knob Goblin Perfume

We convert names to the "canonical" name when storing/looking up modifiers. StringUtilities.getCanonicalName does this:

Code: 
			canonicalName = StringUtilities.getEntityEncode( name ).toLowerCase();
I suppose I can why we want to convert UTF characters into entities, but the lower casing is what causes the issue for the three item/effect pairs I mentioned.

I wonder what would happen if we indexed modifiers by the actual name that appears in modifiers.txt, complete with upper and lower case letters - and with HTML entities exactly as KoL itself uses them.

- would that break anything for internal uses of modifiers? I.e., do we every look them up with canonicalized names, or do we always use real item/skill/effect/etc. names?
- how about ASH programs? You can call numeric_modifier, boolean_modifier, and string_modifier with a $item, $effect, (or $skill or $familiar) and that uses the "to_string" method to get the (non-canonical) name. The thing is, you can also pass in a program-generated string.

I'm tempted to just make the change and wait for the howls of rage. ;)
 
Fluxxdog

Fluxxdog

Active member
To be honest, I thought everything tried to stay as close as possible to KoL-style with things like trademark being used as ™ (i.e. Ben-Gal™ Balm) because of limitations.
 
Veracity

Veracity

Developer
Staff member
We use HTML entities in our datafiles (rather than Unicode characters, say) because that is what KoL itself uses. I guess I don't understand the point you are trying to make.
 
ckb

ckb

Minion
Staff member
Not everything matches between KOL and Mafia. The recent speakeasy is a good example. This results in this:

Code: 
string [string] sekol;
sekol["glass of \"milk\""] = "glass of "milk"";
sekol["cup of \"tea\""] = "cup of "tea"";
sekol["thermos of \"whiskey\""] = "thermos of "whiskey"";
sekol["lucky lindy"] = "Lucky Lindy";
sekol["bee's knees"] = "Bee's Knees";
sekol["sockdollager"] = "Sockdollager";
sekol["hot socks"] = "Hot Socks";
sekol["flivver"] = "Flivver";
sekol["sloppy jalopy"] = "Sloppy Jalopy";

This was done to match inebriety.txt entries to the KOL html.

I am ok with changing things to be more strict, but for sure it will break a lot of scripts.
 
Veracity

Veracity

Developer
Staff member
Yeah, the speakeasy things are not (currently) real "items", so you have to use a string. I think I added the " to modifiers.txt for them - incorrectly, as I can see in ClanLoungeRequest.

As part of this, I would be happy to normalize the name for them in modifiers.txt to agree with KoL's strings.

Edit: Actually, those basic speakeasy drinks have no modifiers and therefore do not appear in modifiers.txt, so I misremembered. How exactly is 'glass of "milk"' vs. 'glass of "milk"' visible to your script?
 
Last edited:
Veracity

Veracity

Developer
Staff member
OK, here is an example of current behavior:

> ash numeric_modifier( $item[ Mr. Accessory ], "Muscle" )

Returned: 15.0

> ash numeric_modifier( "mr. accessory", "Muscle" )

Returned: 15.0
Click to expand...
If I stop canonicalizing the string before looking it up, the first one will continue to work - since converting a $item to a string results in the correct capitalization - but the second one will fail.

You say that "for sure it will break a lot of scripts". Is that so? Seems like scripts that look up modifiers for items, effects, and skills using $item, $effect, and $skill will continue to work with no changes, but scripts which have hardcoded strings of the names of such which differ from the actual names by capitalization will break. Are there really "a lot" of scripts that do that, or do most scripts pass in the appropriate data type?
 
lostcalpolydude

lostcalpolydude

Developer
Staff member
Feel free to ignore this post if it's unrelated, but since you're looking at modifier code...

Slicked-Back Do is both an effect and an intrinsic, with identical capitalization. There's another thread for that somewhere.
 
Veracity

Veracity

Developer
Staff member
Yeah. And there are also the six effects all named "A Little Bit Evil". We have a kludge for that, which I don't especially like.

I think that "multiple objects with the identical name" is a different issue from "multiple objects with identical names, save for capitalization", so I don't think I'll address it here, but, yes - that is a problem.
 
ckb

ckb

Minion
Staff member
Veracity said:
Edit: Actually, those basic speakeasy drinks have no modifiers and therefore do not appear in modifiers.txt, so I misremembered. How exactly is 'glass of "milk"' vs. 'glass of "milk"' visible to your script?
Click to expand...

Actually, because these are not in modifiers.txt, I read in and parse inebriety.txt to get details about the drinks. Then I feed this parsed info to string_modifiers() to get effects and modifiers if necessary.
This was the only way I could see to get it to work without hardcoding the info into the script because these drinks are not real items.

I am actually not sure if a lot of scripts will have this problem, but thins single one of mine will :)

If we can get all the Mafia data files to standardize to match the KOL strings (capitalization included), then this would probably solve most issues.
 
Veracity

Veracity

Developer
Staff member
Revision 14204 no longer canonicalizes names before looking up modifiers.
Let's see what happens.
 
Veracity

Veracity

Developer
Staff member
ckb said:
If we can get all the Mafia data files to standardize to match the KOL strings (capitalization included), then this would probably solve most issues.
Click to expand...
Yes, inebriety.txt and fullness.txt and spleenhit.txt all canonicalize the item names. I think those are good candidates for Not Doing That, too.
 
ckb

ckb

Minion
Staff member
Also, I think the features requested in this thread would help things too, so I could skip the need to parse psudo-items differently.
 
Fluxxdog

Fluxxdog

Active member
Veracity said:
We use HTML entities in our datafiles (rather than Unicode characters, say) because that is what KoL itself uses. I guess I don't understand the point you are trying to make.
Click to expand...
Ah, I see, you're not copying the text, but the HTML itself. We read a little TM but mafia first sees the ™. I misunderstood the point you were making. Thank you ^^

You know, that gives some items essentially 2 names, an HTML (true name) and a Readable (nick name). Didn't think of it like that.
 
Veracity

Veracity

Developer
Staff member
ckb said:
If we can get all the Mafia data files to standardize to match the KOL strings (capitalization included), then this would probably solve most issues.
Click to expand...
Revision 13211 does this for fullness.txt, inebriety.txt, and spleenhit.txt.

I did it for actual items, speakeasy drinks, sushi, and old Crimbo Cafe offerings. Also for the Chez Snootee. Hmm. Forgot the micromicro brewery. I'll fix that.

Let me know if you find things I forgot.
 
D

Darzil

Developer
Nice one, I guess we'll have to change the reporting when new foods are fine to do so also rather than making them lower case. Should be a quick change.
 
Veracity

Veracity

Developer
Staff member
I'm going to mark this Fixed, since the issue I reported no longer happens. Which is not to say that we are done finding things that I broke; I fixed ModiferExpressions just this morning. But when people find issues, they will make new bug reports, rather than understanding that they are a side effect of fixing this bug, so, there is no point in keeping this one open any more. :)
 
You must log in or register to reply here.
Top