Feature Expand to_stat()

[Winterbay]

I'd like to request that to_stat(string) work on at least mus, mys and mox apart from the full stat-names.
Seeing as these are the most common way to see these stats it would be a great addition to that function (really any amount of letters above 1 is significantly different from the other two).

Thank you for considering this.

 

[Veracity]

You want abbreviations so that you can type a couple fewer letters - once - into your scripts? I can see why you'd like that for cli commands that you will be repeatedly type into the gCLI, but I've never seen the point of abbreviations (including substring matching for $item[] and $skill[] and such) in scripts.

 

[Theraze]

I think the problem is people who type mox or myst or such into preferences, as opposed to the script writers, and then complain that the script is not working properly. It's end-user error. But looks as if the script is the problem...

 

[StDoodle]

Well, there's also the spelling of mysticality to contend with. Or is it mysticallity? I can never remember...

 

[Theraze]

One L, I think. It's the 'ity' of mystical. Not a 'lity' thing. Don't think that 'lity' even makes sense as a suffix...

 

[Winterbay]

You want abbreviations so that you can type a couple fewer letters - once - into your scripts? I can see why you'd like that for cli commands that you will be repeatedly type into the gCLI, but I've never seen the point of abbreviations (including substring matching for $item[] and $skill[] and such) in scripts.

As stated by Theraze it started when I looked at the autobasement script that reads a lib variable after a complaint and it turned out that having "myst" as your combat stat didn't convert to mysticality when sent through to_stat. It's not a big deal, but would be nice to have.

It could also potentially be useful in CLI-aliases when you don't want to type the entire stat for something I guess, but I guess you could do a switch-case on that instead if you wanted to.

 

[zarqon]

I agree with Veracity when it comes to $<type>[], but I don't think the same holds true for to_<type>(string). Currently ZLib vars are normalized by type using these functions. If a user typed "zlib autobasement_combatStat = myst" for example, it would be normalized to "none". It would be nice if mafia could instead normalize it to $stat[mysticality] rather than $stat[none]. These will be entered in the CLI.

Presently, this one autobasement variable is probably the only commonly used $stat Zlib setting, but there will probably be more to come.

Further, one of my current projects is adding standardized functionality for handling comma-delimited lists of mafia types into ZLib. One of the things I'm doing is normalizing these lists, which involves first detecting the type. These lists may be entered by users as script parameters, they may be entered by users as ZLib script settings, they may be hardcoded into scripts -- there are plenty of applications and sources. If to_stat matched on reasonable substrings it would definitely make the type detection more robust, and less prone to user error.

While I'm at it, I'd like to_element("heat") to match $element[hot], but that's not a particularly big deal.

 

[Bale]

I've never seen the point of abbreviations (including substring matching for $item[] and $skill[] and such) in scripts.

However, there is substring matching for those fields. Why not for $stat[] also?

[COLOR="#808000"]> ash $item[sonar-in][/COLOR]

Returned: sonar-in-a-biscuit
plural => sonars-in-a-biscuit
descid => 415379536
levelreq => 0
fullness => 0
inebriety => 0
spleen => 0
notes =>
combat => true
reusable => false
usable => true
multi => false

[COLOR="#808000"]> ash $stat[myst][/COLOR]

[COLOR="#ff0000"]Bad stat value: "myst" ()[/COLOR]
Returned: void

This is not intended to be a complaint. I just want to know if there is any particular reason for those cases to be treated differently?

 

[zarqon]

Substring matching is helpful for omitting crazy characters like trademark symbols or in the bugged items, apostrophes if they screw with your editor's highlighting, or simply to whip up test scripts faster (you can rely more on your memory of item names).

Substring matching is unnecessary for $stats, $elements, $classes, and possibly others because none of those reasons apply.

 

[fronobulax]

Substring matching is helpful for omitting crazy characters like trademark symbols or in the bugged items, apostrophes if they screw with your editor's highlighting, or simply to whip up test scripts faster (you can rely more on your memory of item names).

+1

I am too lazy to figure out how to enter the trademark symbol into a string that will eventually be parsed as an item.