Bug Stat Experience Modifiers written oddly in certain tracking preferences

[phreddrickk]

The preferences nextStillsuitMods, currentStillsuitMods, _mummeryMods, and presumably certain other mods have a quirk about how they express certain numeric modifiers. Here's an example value of a nextStillsuitMods provided by @SSBBHax:

Experience (Muscle): +11, Experience (Mysticality): +9, Experience (Moxie): +7, Item Drop: +110, Food Drop: +100, Damage Reduction: 24, Initiative: +40, Spooky Damage: +9, Spooky Spell Damage: +15, Hot Damage: +3, Hot Spell Damage: +5, Cold Damage: +3, Cold Spell Damage: +5, Stench Damage: +6, Stench Spell Damage: +10, Sleaze Damage: +3, Sleaze Spell Damage: +5, Weapon Damage: +27

Experience (Muscle) isn't formatted the way mafia's numeric modifiers are--the actual name of the modifier is Muscle Experience. And a quick test tells me it's not an alias:

> js numericModifier("Experience (Muscle)")

Returned: 0

> js numericModifier("Muscle Experience")

Returned: 69.2615

To my knowledge, the experience mods are the only ones misreported, and these prefs are the only ones misreporting them. But there are a few other preferences that track modifiers like this: _birdOfTheDayMods, _citizenZoneMods, and yourFavoriteBirdMods are the ones I can name off the top of my head. A quick wiki search suggests that neither of these ever give statted experience modifiers and are probably safe, but if we find that there are other modifiers formatted differently in prefs than in the rest of the code, we'll want to check those too.

 

[Ryo_Sangnoir]

All of these have a "Tag" different to their "Name". I don't know what this means (apart from behaving exactly as you've seen: "name" is what is passed to $modifier[], "tag" is what appears in the data files).

Sporadic meat / item drop, Familiar experience, percentage stat experiences, familiar tuning are also affected.

These mods also don't work with split_modifiers, but were intended to. I guess I could just change it to use tags instead.

 

[phreddrickk]

All of these have a "Tag" different to their "Name". I don't know what this means (apart from behaving exactly as you've seen: "name" is what is passed to $modifier[], "tag" is what appears in the data files).

Is tag only used in data files? would updating the data files to use the name instead of the tag (and changing all of those tags) be a good solution? or would it make more sense to make prefs and functions use the name instead?

These mods also don't work with split_modifiers, but were intended to. I guess I could just change it to use tags instead.

That part feels more unambiguously like a bug than what I've reported, which is more of a weird point of friction than a definite bug.