ZLib -- Zarqon's useful function library

Code: 
> ashq import zlib; my_defstat().print()

Running ZLib version: r31 (current)
1710
It looks like importing like this works if there aren't any quotes at all in the same line.

When you did
Code: 
> ashq import zlib; setvar("spaaace_othergoal", $item[none]);
Mafia tried to import spaaace_othergoal.ash
 
Hmm... I'm not sure I completely follow how the new version of check_version() works, and I'd really like to keep the version in std_lib closer in functionality to yours. 'Course I also plan to do a couple other things with it as well, but meh. Anyway...
 
All that changed was that instead of using daily properties, it now uses an external map, indexed by what used to be the property name, which contains the remote version number (current version) and the date last checked (today_to_string()). ZLib will load this map only once per ZLib instance. Using this map, it doesn't check once per multi, it checks once per mafia installation, which saves both server hits and player time. Other benefits include: 1) version information is easier to find, and b) mafia properties (which I believe are all loaded into memory while mafia runs) are a bit slimmer.

If you have any specific questions about how it works, I'd be happy to answer them.

Bale's UR is still using the clunky old versioning as well. One of these days I'm going to post a smaller, ZLib-powered version of that script in his own thread, with the exact same name and version. Sweet revenge! ;)
 
Well, my two concerns are:

1) Ok if I use the same data file? Seems a shame not to, but I don't want to "steal" someone's code / solution without permission.

2) It looks like you're implementing some basic "is this newer" checking... I have thoughts along those lines, specifically checking various "levels" (major, minor, etc.) as well as release type (stable, dev, alpha, beta) and allowing the script to only "nag" if certain criteria are met. (Eg "don't warn for beta, alpha or dev, just number revisions, etc.). The big problem is this would require a "standard" format for posting and for checking a "stable" vs. a "dev/alpha/etc." version. Any thoughts?

3) I'd love to merge these back at some point. I've already made use of one new zlib var, "max_delay" which the user can use to limit how long scripts delay for during version checking. Other than that and finishing something for point #2, that's all the big stuff I can think of.
 
zarqon said:
Bale's UR is still using the clunky old versioning as well. One of these days I'm going to post a smaller, ZLib-powered version of that script in his own thread, with the exact same name and version. Sweet revenge! ;)
Click to expand...

Yeah, I've been planning to switch over to the new system. It's not a priority though. Honestly I think all of UR needs a serious refactoring to a system that accounts free rests, nuns, shower, healing spells, etc as recovery options in the same map as items so that I can deal with it as a whole, instead of a ton of special cases.
 
1) Yes, of course. ZLib is non-proprietary. :)

2) I could see a setting allowing users to specify the degree of alerting they want. The user would be alerted for updates in number groups up to group n, i.e. if their setting was '2', they would be alerted when 1.3 changed to 1.4 (group 2) but not when 1.3.1 changed to 1.3.2 (group 3). The default would probably be 2, and script authors could take advantage of this to make changes which are cosmetic, trivial, or experimental only advance groups higher than the default. I believe script authors are more or less conforming to the 4-group standard which fronobulax put forward earlier (although they usually omit group 4, and often group 3 as well), so this would work nicely. However, given the following point this discussion is much less necessary:

3) ZLib no longer delays during check_version(), so functionally speaking there is no difference between being alerted vs. not (and therefore settings to configure the alert are just 'luxury' settings).

StDoodle said:
my two concerns
Click to expand...

Haha!
 
zarqon said:
1) Yes, of course. ZLib is non-proprietary. :)
Click to expand...

Yay! Just fyi, everything I post on here is as well.

zarqon said:
2) I could see a setting allowing users to specify the degree of alerting they want.... I believe script authors are more or less conforming to the 4-group standard which fronobulax put forward earlier...
Click to expand...

Cool; do you happen to remember where that was discussed? I don't recall seeing it and want to make sure I'm going with the same system, but what you wrote is pretty much what I had in mind.

zarqon said:
3) ZLib no longer delays during check_version(), so functionally speaking there is no difference between being alerted vs. not (and therefore settings to configure the alert are just 'luxury' settings).
Click to expand...

Huh, one of these days I need to poke my head in on that code when I'm not horribly tired. ;)

zarqon said:
Haha!
Click to expand...

Sigh, that's how many I had in my head when I started writing... I need to make my posts list-length agnostic. :p
 
Maybe be_good() could be changed to:
PHP: 
boolean be_good(string it)
{
   return my_path() == "Bees Hate You" ? !it.to_lower_case().contains_text("b") :
          my_path() == "Trendy" ? it.is_trendy() :
          true;
}
 
Right now be_good() is a function designed to determine if something is acceptable to the beecore path specifically. I think that it should remain that way. If you want a function to determine if an item etc is acceptable to the current path, regardless of which, then it needs a new name.
 
How about a function named path_okay() (or something like that) including be_good, is_trendy (the mafia function), and anything else as it gets added? That way we have a standard function that can get updated and we can deal with the joy of new challenges as they come.

For that matter, path_okay should probably check if it's a weapon or offhand trying to be equipped without owning/using a disembodied hand during WotSF.
 
Bale said:
Right now be_good() is a function designed to determine if something is acceptable to the beecore path specifically.
Click to expand...
It still does that, as well as checking for other paths. Creating a new function with another name seemed redundant, and changing the name would break scripts, I guess.
 
When would you use be_good() and not want to check other paths as well? I couldn't think of any examples, but maybe you can.

Are there any familiars/items/skills with the same name where one is trendy and one is not? That would be a major obstacle to a single-function implementation.
 
Yes. Some items equate to familiars:

disco ball => Autonomous Disco Ball
grapefruit => Clockwork Grapefruit
goat => Angry Goat
lime => Sabre-Toothed Lime
fuzzy dice => Fuzzy Dice
spooky pirate skeleton => Spooky Pirate Skeleton
barrrnacle => Barrrnacle
box => Bulky Buddy Box
balloon monkey => Howling Balloon Monkey
volleyball => Blood-Faced Volleyball
blood-faced volleyball => Blood-Faced Volleyball
NG => Angry Goat
ND => Baby Sandworm
star => Star Starfish
star starfish => Star Starfish
ghost pickle on a stick => Ghost Pickle on a Stick
leaf => Whirling Maple Leaf
maple leaf => Whirling Maple Leaf
Hanukkimbo dreidl => Hanukkimbo Dreidl
hovering sombrero => Hovering Sombrero
pygmy bugbear shaman => Pygmy Bugbear Shaman
ninja pirate zombie robot => Ninja Pirate Zombie Robot
sweet nutcracker => Sweet Nutcracker
ball => Autonomous Disco Ball
pet rock => Pet Rock
teddy bear => Teddy Bear
wind-up chattering teeth => Wind-up Chattering Teeth
astral badger => Astral Badger
brick => BRICKO chick
misshapen animal skeleton => Misshapen Animal Skeleton
scary death orb => Scary Death Orb
reassembled blackbird => Reassembled Blackbird
towel => Origami Towel Crane
rock => Pet Rock
stick => Ghost Pickle on a Stick
tooth => Sabre-Toothed Lime
fire => Mutant Fire Ant
evil teddy bear => Evil Teddy Bear
toothsome rock => Toothsome Rock
snake => Baby Mutant Rattlesnake
cracker => Sweet Nutcracker
wizard action figure => Wizard Action Figure
Crimbo P. R. E. S. S. I. E. => Crimbo P. R. E. S. S. I. E.
Bulky Buddy Box => Bulky Buddy Box
teddy borg => Teddy Borg
El Vibrato Megadrone => El Vibrato Megadrone
adorable seal larva => Adorable Seal Larva
macaroni duck => Animated Macaroni Duck
hobo monkey => Hobo Monkey
mutant cactus bud => Mutant Cactus Bud
pair of ragged claws => Pair of Ragged Claws
midget clownfish => Midget Clownfish
syncopated turtle => Syncopated Turtle
grinning turtle => Grinning Turtle
rock lobster => Rock Lobster
Jack-in-the-box => Jack-in-the-Box
boulder => He-Boulder
organ grinder => Knob Goblin Organ Grinder
smiling rat => Smiling Rat
holiday log => Holiday Log
reconstituted crow => Reconstituted Crow

And some equate to skills:

spring => Spring Raindrop Attack
orange => Fire orange bottle-rocket
box => Fire a boxing-glove arrow
WA => Claws of the Walrus
NG => Advanced Cocktailcrafting
ND => Ask Richard for a Bandage
star => Start Trash Fire
leaf => Falling Leaf Whirlwind
bow => Rainbow Gravitation
top => The Polka of Plenty
ball => Awesome Balls of Fire
brick => Summon BRICKOs
can cannon => Cannelloni Cannon
rock => Fire black bottle-rocket
stick => Summon Stickers
tooth => Tolerance of the Kitchen
yo => All-You-Can-Beat Wing Buffet
fire => Awesome Balls of Fire
fire poi => Fire a poison arrow
pear => Spaghetti Spear
The Ballad of Richie Thingfinder => The Ballad of Richie Thingfinder
Benetton's Medley of Diversity => Benetton's Medley of Diversity
Elron's Explosive Etude => Elron's Explosive Etude
Chorale of Companionship => Chorale of Companionship
Prelude of Precision => Prelude of Precision
The Spirit of Crimbo => Recite 'The Spirit of Crimbo'
knuckle sandwich => Knuckle Sandwich
boxing glove => Fire a boxing-glove arrow
Bag o' Tricks => Open the Bag o' Tricks
sugar sheet => Summon Sugar Sheets
Inigo's Incantation of Inspiration => Inigo's Incantation of Inspiration
jingle bell => Jingle Bells
stress ball => Squeeze Stress Ball

If you go by the exact same name, a universal single-string-parameter function would have to run considerably slower, but the subset of matches becomes smaller (bolded above). All of the familiar matches are hatchling => familiar as well, which may provide some trick for speeding it up.

Not having seen the typeII list yet, I don't know which of these are trendy vs. not, but it's a factor for implementing a universal path_safe(string) function, rather than one per type as ASH did.
 
Last edited:
zarqon said:
Not having seen the typeII list yet, I don't know which of these are trendy vs. not, but it's a factor for implementing a universal path_safe(string) function, rather than one per type as ASH did.
Click to expand...

You can find the typeII list at URL/typeii.php even if you aren't currently on the trendy path.
 
Anyone see any reasons this sucks? I'm a bit curious whether the per-type trendy checks are redundant, given that there is a string version of is_trendy() which "verifies that the random string is not untrendy in any of the various possible categories". I'm a bit curious if this uses exact or fuzzy matching. If the latter, then I think the apparent redundancy is necessary, but if the former, we could probably reduce it all to a single is_trendy(string) check.

PHP: 
boolean be_good(string it) {
   switch (my_path()) {
      case "Bees Hate You": return it.to_lower_case().index_of("b") == -1;
      case "Trendy": 
        foreach f in $familiars[] if (it.to_string() == f.to_string()) return is_trendy(f);
        foreach s in $skills[] if (it.to_string() == s.to_string()) return is_trendy(s);
        if (it.to_item() != $item[none]) return is_trendy(to_item(it));
        return is_trendy(it);
      case "Way of the Surprising Fist": return !($slots[weapon,offhand] contains it.to_item().to_slot());
   }
   return true;
}
 
In the case of a string, this is what is_trendy() returns:
PHP: 
result = TrendyRequest.isTrendy( "Items", key ) &&
	TrendyRequest.isTrendy( "Campground", key ) &&
	TrendyRequest.isTrendy( "Bookshelf", key ) &&
	TrendyRequest.isTrendy( "Familiars", key ) &&
	TrendyRequest.isTrendy( "Skills", key ) &&
	TrendyRequest.isTrendy( "Clan Item", key );
However, TrendyRequest.isTrendy() doesn't do any kind of fuzzy matching: "key" must be the normalized name, which is shown in typeii.php. I tweaked it so that case doesn't matter, but the name still needs to be normalized.

Just one more point: is_trendy() translates the names of the bookshelf skills to the associated tome/libram/grimoire, so is_trendy( skill ) covers those, but is_trendy( string ) doesn't.
 
Last edited:
I think it should be mentioned that if the string entered doesn't match anything directly you will get "true" back:
Code: 
> ash is_trendy("coffee")

Returned: true

> ash is_trendy("coffee pixie")

Returned: false

> ash to_item("coffee")

Returned: none

> ash to_familiar("coffee")

Returned: Coffee Pixie

> ash to_skill("coffee")

Returned: none
 
Hence the need to normalize:
PHP: 
> ash string f = "coffee"; is_trendy( f.to_familiar() );

Returned: false
 
You must log in or register to reply here.
Back
Top