ZLib -- Zarqon's useful function library

Update!

Hahaha! I also don't get why the middle one failed, but I fixed the third one.

I also commented out the "bounty items are automatically goals" lines from has_goal(). I'm not anticipating this will break anything. If it is, in fact, a safe change, I believe we'll simply remove the lines for good. I do know that code predates bounty information in proxy records so it may have been something to help FTF out.
 
> ash import <zlib.ash>; print(best_fam("meat"));

Finding best familiar of type "meat"...
No familiar found matching type "meat"
Cocoabo
Returned: void
Click to expand...

best_fam("meat") is not returning the Angry Jung Man even though it is a fairychaun type and does indeed boost meat gains.
 
Yes, I've not updated the bestfamiliars.txt data file (in your data directory) in quite a while. It's missing more than a few familiars.

To fix it, one simply has to add the Angry Jung Man to the data file. Then, to share this fix with all users, upload the edited data file on the Map Manager. Voilà!

I've just done this for you, so the next time ZLib checks bestfamiliars.txt (which it does no more than once a day unless you delete its entry from zversions.txt) it will download the changes into your data folder. In the future, now that you know the data file is publicly editable, I hope you will be able to make the change yourself. :)
 
What do the numbers in that file signify? I would have expected the entries to be similar to the Leprechaun and Baby Gravy Fairy since the gains follow the same rules. I also would like to take a stab at adding the Unconscious Collective once I understand the file's format better. I'm going to guess it should be "Unconscious Collective meat 25, stat 75" based on other entries but what does the 25 and 75 mean?
 
Those numbers are somewhat arbitrary. They represent the strength or rank of the familiar in the specified category; however, they also try to take into consideration secondary abilities.

This is because, although best_fam() will use your heaviest familiar in a given category, in the event of a tie it will use the familiar with a higher strength rating. This allows us to rank familiars in a given category -- which is sometimes a rather arbitrary business.

Let's consider the "meat" category as an example. A Leprechaun is listed at "meat 10". The Casagnova Gnome, which gives the exact same meat yield as a Leprechaun, is rated "meat 30". That's because the Gnome also gives +items and should thus be considered a "better" meat familiar in the event of a weight tie between those two (which happens when you haven't used any of the familiars in that category yet). The Uniclops is "meat 25" -- it also gives +stats so it's clearly better than a Leprechaun, but is it better than a Casagnova Gnome? Impossible to say, but whoever added this data preferred the Gnome over the Uniclops.

The numbers aren't terribly important because they only affect ties, but they are somewhat important because recently ascended players, people who just completed a familiar-less challenge path, and people who just completed a 100% run all have quite a lot of ties on their hands.

A long while back this data file was overhauled by some other people to include new categories, and they fleshed it out with more familiars as well. When I originally made the data file it did not contain the categories dodge, restore hp, restore mp, elemental damage, or water, yet now it does.

Thanks for contributing by the way! Hope this information helps you in your efforts to do so.
 
zarqon said:
Those numbers are somewhat arbitrary.
Click to expand...

Well that makes me feel better about not being able to figure out how they were derived. I went ahead and added the Unconscious Collective and copied the values from the other volleychaun type familiars.
 
Since there is some angst being exhibited about the fact that all scripts using zLib have to read all of the variables in the associated data file and thus unused or unneeded variables can cause performance issues, how about a special version of setvar? User runs a special command - zClean which sets a zLib zClean var, renames vars_char.txt to vars_char.txt.UNCLEAN and replaces setvar with a special version. zUnclean would optionally delete vars_char.txt.UNCLEAN, delete the zClaen variable and restore zLib to the version with the unspecial setvar.

Special setvar would work as setvar does now unless the variable being set does not exist. In that case setvar would use a value from vars_char.txt.UNCLEAN rather than the value passed in as a parameter.

If the spec is correct then the zLib vars file will be recreated with only the variables used by a script that the user runs and the values the user last set would be preserved.

Or there could be an instrumented version that keep track of variable name and date it was last used. A user could manually edit the vars file to delete variables with no date.

or...
 
Unless you're instancing variables to scripts, and making vars_fronobulax_Harvest, vars_fronobulax_eatdrink, vars_fronobulax_ (for the general ones) and so on... I don't think that most clean-up methods will get used by people. Especially if it involves wiping settings that they may have modified a year and a half ago with great difficulty and much confusion.
 
It's not really an issue of performance so much as script design. Script authors, for the most part, are probably not thinking when deciding to use ZLib vars that the decision has an effect -- albeit infinitesimal -- on all ZLib-powered scripts. The recent "angst" I exhibited was mild Best Practices indignation, not performance concern. Even a hundred pointless script settings would have a negligible impact on performance, so it's not worth revamping the way they're handled; though I do appreciate your efforts in brainstorming an implementation. :)
 
I have been known to lie awake at night concerned with the fact that there were zLib variables and mafia preferences that were still in files but placed there by scripts I have no intention of ever running again. Some nights I actually get up and start writing shell scripts to do something about it but then my ADD overcomes my OCD and I start wondering about all the scripts that are in my scripts directory that I will probably never use again and then I give up and play whatever game intrigues me at the moment until the insomnia passes.
 
zarqon, I had a thought so I thought I'd run it past you to see if you wanted to add my thought to zlib. I was thinking about check_version() and it occurred to me that some people might appreciate the ability for the script to update only on a stable release. It just requires a couple of small changes.

Code: 
[COLOR="#FF0000"][B]setvar("stableUpdateOnly",true);[/B][/COLOR]   // Actually this goes at the bottom of the script

// checks script version once daily, returns empty string, OR div with update message inside
string check_version(string soft, string prop, string thisver, int thread) { int w = 8; string page; matcher find_ver;
   if (svn_exists(prop)[COLOR="#FF0000"][B] && vars["stableUpdateOnly"] == "false"[/B][/COLOR]) { return check_version(soft, prop, thread); }
   if (count(zv) == 0) file_to_map("zversions.txt",zv);
   boolean sameornewer(string local, string server) {
      if (equals(local,server)) return true;
      string[int] loc = split_string(local,"\\.");
      string[int] ser = split_string(server,"\\.");
      for i from 0 to max(count(loc)-1,count(ser)-1) {
         if (i+1 > count(loc)) return false; if (i+1 > count(ser)) return true;
         if (loc[i].to_int() < ser[i].to_int()) return false;
         if (loc[i].to_int() > ser[i].to_int()) return true;
      }
      return local == server;
   }
   if (zv[prop].vdate != today_to_string()) {
      vprint("Checking for updates (running "+soft+" ver. "+thisver+")...",1);
      page = visit_url("http://kolmafia.us/showthread.php?t="+thread);
      find_ver = create_matcher("<b>"+soft+" (.+?)</b>",page);
      zv[prop].vdate = today_to_string();
      if (!find_ver.find()) { 
         vprint("Unable to load current version info.",-1);
         map_to_file(zv,"zversions.txt");
         return "";
      } w=1;
      zv[prop].ver = find_ver.group(1);
      map_to_file(zv,"zversions.txt");
   }
   if (sameornewer(thisver,zv[prop].ver)) { vprint("Running "+soft+" version: "+thisver+" (current)","gray",w); return ""; }
   [COLOR="#FF0000"][B]if (svn_exists(prop)) { return check_version(soft, prop, thread); }[/B][/COLOR]
   string msg = "<big><font color=red><b>New Version of "+soft+" Available: "+zv[prop].ver+"</b></font></big>"+
      "<br><a href='http://kolmafia.us/showthread.php?t="+thread+"' target='_blank'><u>Upgrade from "+thisver+" to "+zv[prop].ver+" here!</u></a><br>";
   find_ver = create_matcher("\\[requires revision (.+?)\\]",page);
   if (find_ver.find() && find_ver.group(1).to_int() > get_revision())
      msg += " (Note: you will also need to <a href='http://builds.kolmafia.us/' target='_blank'>update mafia to r"+find_ver.group(1)+" or higher</a> to use this update.)";
   vprint_html(msg,1);
   return "<div class='versioninfo'>"+msg+"</div>";
}

That way if someone has automatic svn updates turned off.... and it is off by default, they won't get troubled by the script updating unless it is a stable update according to the script's thread. I added a var to control the behavior in case someone really wants to disable it.
 
Last edited:
Trying to be a good samaritan:

"Changing "boss bat's lair" to "The Boss Bat's Lair" would get rid of this message (zlib.ash, line 603)"

(I assume this is the only thing that is affected - just the message. But still...)
 
r9 Update

Mostly implemented Bale's suggestion, minus ZLib var. For the four-parameter version of check_version(), if the script version according to the thread isn't current and svn_exists(prop), call the three-parameter SVN version. This will allow authors more control over when they want their scripts to automatically update (i.e. on a "stable" release, if such a thing is even possible in the world of KoLmafia scripting). Authors who would want the script to always automatically update regardless ought to be using the three-parameter version anyway.

The Boss Bat's Lair has a definite article. Yep, that's definitely an article.
 
When that idea occurred to me I thought you might like it. :D Ironically I might not use it myself. I just thought it was a neat idea.


zarqon said:
The Boss Bat's Lair has a definite article. Yep, that's definitely an article.
Click to expand...

That's why I go there to enjoy some reading, despite the poor lighting.
 
I do like the idea of both versions of check_version() serving a purpose for SVN-using authors.

What is the Boss Bat's relation to the Bat King? Seems to me he must be some kind of crime lord who refuses to acknowledge my sovereignty. Guess that's why I make sure to smack him down every run.
 
I have looked through this thread, but I can't find where the boss bat bug discussion begins. I have tried updating, and tried changing it to "The Boss Bat's Lair" but I still get the error read out:

Bad location value: "the boss bat's lair" (zlib.ash, line 603)

Bad location value: "The Boss Bat's Lair" (zlib.ash, line 603)

what to do?
 
Whenever ZLib tries to update, I keep getting an error:

Checking for updates (running ZLib rev. 9)...
Validating repo...
Repo validated.
Updating zlib...
svn: E200030: READONLY
Done.

I have already updated to the newest .jar file so I don't think my version of kolmafia is the problem. I am stumped.
It then aborts all scripts that were running... This is completely stopping me from doing anything considering pretty much every script ever depends on this library.
 
You may be running as a limited user and unable to overwrite your current copy of zlib. If you're on Windows, try moving the mafia folder to the desktop and running it there to see if it works better. If you're on *nix, you can chmod or sudo java -jar to make sure you have permission for one execution.
 
You must log in or register to reply here.
Back
Top