ZLib -- Zarqon's useful function library

I've been having a problem over the last couple months where my zlib saved variables are getting reset to default. Luckily I'm using dropbox and I can manually revert to an older version, but so far I have been unable to figure out why this is happening since it occurs through automation. It does look like the var file is getting saved out several times in a row with wildly different file sizes within the same minute based on the dropbox timestamps, so maybe that has something to do with it but I'm not sure.
 
Last edited:
ZLib is on SourceForge!

After almost an entire year and nearly 3500 downloads, ZLib r37 is done with its long run. ZLib is now a SourceForge project, and can be installed automatically by typing
Code: 
svn checkout https://svn.code.sf.net/p/zlib/code
in your CLI.

I'm calling this r38 so that users of r37 will see the update notification, but actually since moving to SourceForge the revision numbers started over, so we're now at revision 4. Sometime in the future I will be removing the version number from the first post so as to avoid confusion.

What's new in r38/r4

I fixed the issue Bale reported about unascended characters not having access to exactly-three-sided boxes, but of course the big news is a check_version() that works for SVN projects, and which ZLib now uses itself, so it will stay current without needing to navigate here to download it.

The check_version() we've known thus far had four parameters: one printable-format script name, one property-format scriptname, the current version, and the script thread.

This update adds another version of check_version() with nearly all the same parameters: printable-format script name, project name, and the script thread. The project name is the name of the SVN repo mafia should access to update your script, which in the case of ZLib is "zlib". Just as with the forum post version, your script's current version and the last date checked is stored in zversions.txt, along with scripts which are checked via the four-parameter version, and maps which are checked via load_current_map().

Important things to know about the SVN check_version:

  • As with the forum post version, it only checks once a day.
  • It still returns a string -- an empty string if no update occurred, or an informative message if either 1) it automatically updated the script, or 2) the script was previously updated but has not yet notified the user of the update. This message is both printed to the CLI and also returned inside a <div class="versioninfo">.
  • It will automatically update scripts which are not at head using "cli update <proj>". It does not, however, stop operation at this point. If you want to abort so that the user needs to restart (this time with the updated script), you'd need to do that in the calling script based on check_version's return value.
  • If you've already updated the script since it last ran (for example automatically at login or by manually updating), it detects this and prints an informational message letting users know the script has updated, with two or three links: one to the forum thread (first post), one to the forum thread last post, and if the repository is hosted on SourceForge, a link to the SourceForge changelog. Users who want more information about the update can then easily view the updates and participate in discussion about them.
  • When the forum post version of check_version is called, it checks to see if you have switched to SVN -- it checks svn_exists(provided property name). If this exists, it calls the three-parameter version of check_version() instead. This ought to allow script authors to migrate incredibly gracefully, in the event that their previous property parameter shares the name of their SVN project.
  • Authors releasing scripts via SVN which use ZLib can now include ZLib as a dependency, and it will be automatically installed when your users install your script.

If you want to see the exact function syntax, I have edited the ZLib Wiki page with information about the new function.

Enjoy migrating to an update experience that is vastly more convenient, without leaving users in the dark!
 
Last edited:
Just wanted to say that this line:
Code: 
float has_goal(item whatsit) {                   // chance of getting a goal from an item
   if (whatsit == to_item(to_int(get_property("currentBountyItem")))) return 1.0;
   if (!goal_exists("item")) return 0;
still causes problems for automated item retrieval, since it means that zlib will suggest an area that doesn't actually ever meet your goals, which means you'll adventure there until you're either out of turns or manually abort.

Any chance we could get this overloaded, like so? (entire function included even though only the top two lines and the lower lines are changed):
Code: 
float has_goal(item whatsit, boolean bounty) {                   // chance of getting a goal from an item
   if (bounty && whatsit == to_item(to_int(get_property("currentBountyItem")))) return 1.0;
   if (!goal_exists("item")) return 0;
   float has_goal(item whatsit,int level) {
     if (whatsit == $item[none]) return 0;
     if (is_goal(whatsit) || whatsit == to_item(to_int(get_property("currentBountyItem")))) return 1.0;
     if (count(useforitems) == 0 && !load_current_map("use_for_items", useforitems)) {
        vprint("Unable to load file \"use_for_items.txt\".",-3); return 0;
     }
     if (level > 5) return 0;  // avoid infinite recursion
     float res;
     if (useforitems contains whatsit) foreach key,perc in useforitems[whatsit]
        if (has_goal(key,level+1) > 0) res = max(res,perc);
     return res;
   }
   float tot;
   foreach i,s in get_goals() {
      matcher numthings = create_matcher("\\d+ (.*)",s);
      if (!numthings.find()) continue;
      item testor = numthings.group(1).to_item();
      if (testor == whatsit || !is_goal(testor)) continue;
      tot += isxpartof(whatsit,testor);
   }
   return tot + has_goal(whatsit,0);
}
float has_goal(item whatsit) { return has_goal(whatsit,true); }
This allows for continuing to allow for legacy behaviour, but also allows for automation to only go for the correct zone. And the alternate values below appears to be the zlib standard, which is why I included it that way. :)
 
Did I do bad?

> zlib vars

Bad item value: "bitchin meatcar" (zlib.ash, line 586)
Click to expand...

This started happening as soon as I did the svn update.


EDIT: And then I updated from r2220 to r2222, and it disappeared. False alarm!
 
Lxndr said:
Did I do bad?



This started happening as soon as I did the svn update.


EDIT: And then I updated from r2220 to r2222, and it disappeared. False alarm!
Click to expand...

This means that fuzzy matching stopped working in mafia for you. That happens very rarely. Restarting mafia fixes it.

It also means zlib isn't using an exact item name when it could be.
 
I had formed a habit of omitting single apostrophes in mafia's typed constants because it screwed with my syntax highlighting. I have since tearfully abandoned my old favorite editor and testing just now revealed that the habit is no longer necessary. I'll start unlearning that habit, and re-inserting them as I find them.
 
zarqon said:
I had formed a habit of omitting single apostrophes in mafia's typed constants because it screwed with my syntax highlighting. I have since tearfully abandoned my old favorite editor and testing just now revealed that the habit is no longer necessary. I'll start unlearning that habit, and re-inserting them as I find them.
Click to expand...

What editor do you use now?
 
ZLib automatically updates itself even though I unchecked "Update installed SVN projects on login" in Preferences -> SVN. Is there a way to disable this?
 
chaosbeaver said:
Is there a way to disable this?
Click to expand...

The short answer is no.

chaosbeaver said:
Is there a way to disable this?
Click to expand...

The long answer is yes! Go to your KoLmafia directory and head for the /svn/zlib/scripts directory. Edit the version of zlib.ash in this directory to ensure that your changes will remain even if you later update zlib! Go down to the bottom of the file and on line 760 you will see:

Code: 
[check_version("ZLib","zlib",2072);

Either comment out or delete this line. Then in the CLI use the command: svn sync

Finally, go to Preferences -> SVN -> check "Sync after svn update"

That will keep zlib from automatically updating itself. You can still tell kolmafia to update zlib with either a svn update or svn update zlib command. Even if it is updated, the updated version will retain your alteration.
 
Last edited:
I'm so happy I wasn't typing all that in vain! All praise the new era of SVN where we can make changes to own scripts and know the changes will stay there if the author updates it.
 
You don't even need to tic the "sync after update" preference really. The one manual svn sync is sufficient to get the modified file pushed locally; any updates will be pushed regardless of that setting being on.

The only reason to have sync-after-update on is if you often make numerous modifications to your working copies and want to make sure you don't forget to sync. I use it basically for peace of mind that i didn't forget anything. It's a pretty marginal feature, I might move it back to being hidden.
 
Theraze said:
zlib will suggest an area that doesn't actually ever meet your goals, which means you'll adventure there until you're either out of turns or manually abort.
Click to expand...

Wouldn't that technically mean you would adventure there until you satisfied the bounty, at which point the script would recommend the correct location? Shouldn't waste much more than 40 turns. :cool:

Silly nitpicking aside, what would break if we just removed current bounty items as always being goals? Anything? I forget my original reason for including that, and wonder if it's still valid in this ever-changing world of KoL scripting in which we live.
 
zarqon said:
Wouldn't that technically mean you would adventure there until you satisfied the bounty, at which point the script would recommend the correct location? Shouldn't waste much more than 40 turns. :cool:
Click to expand...
Nope. When goal = 3 beer lens, and you adventure at the spooky forest for your bounty of triffid bark with 3 beer lens still set as your goal, you'll never get beer lens from the spooky forest. Many many more than 40 turns spent. Unless you only had 40 adventures or less remaining.

Silly nitpicking aside, what would break if we just removed current bounty items as always being goals? Anything? I forget my original reason for including that, and wonder if it's still valid in this ever-changing world of KoL scripting in which we live.
Click to expand...
Only lazy scripting, I believe. Since we can easily actually check what the bounty is and set it as a goal if we'd like to evaluate against it.
 
You must log in or register to reply here.
Back
Top