ZLib -- Zarqon's useful function library

As far as I can tell vprops are just mafia properties with the defaults cooked in to each script. So it will work, although as far as Prefref Plus is concerned it will treat the property as not having a default, since we cant possibly load every script to look for those defaults.
 
Please modify zlib to honor mafia's svn update settings. When SourceForge goes down you have to edit zlib.ash and remove the checks for updates that it runs.
 
Please modify zlib to honor mafia's svn update settings. When SourceForge goes down you have to edit zlib.ash and remove the checks for updates that it runs.

I don't even know how to do that, share please? Also, batbrain etc. I just completely cut out the SVN section to the end of the check for updates section, then had the same error for batbrain. Had no idea how many of my background scripts are dependent upon sourceforge being up and running, so turning on my auto attack seems to have side-stepped the situation for now. Sharing in case anyone else is as clueless as I am about .ash scripts and runs into the same problem.
 
Please modify zlib to honor mafia's svn update settings.

Do you mean svnUpdateOnLogin? I guess ZLib's version checking is completely unnecessary for users who have set that to true, since all versions would have already been checked.

The next revision (which I'll commit whenever SourceForge goes back up) will skip SVN version checking for users who have already automatically updated SVN.
 
Thank you! I would advocate one tweak: Don't update at all if svnUpdateonLogin is not set. The problem when SourceForge goes down is, mostly, fixable by disabling SVN updates on login but then zlib comes along and wants to check everything that calls zlib, in addition to itself. What ended up happening this morning went something like this:

  1. Login
  2. See that SourceForge is down
  3. Flip the SVN preference to NOT auto-update on login
  4. Log out and then back in
  5. Start adventuring
  6. Zlib tries to update itself
  7. Edit Zlib to remove that check
  8. Adventure again
  9. Zlib tries to update BBB
  10. Scream
  11. Edit Zlib to rip out all the checks
  12. Back to adventuring
 
Last edited:
Do you mean svnUpdateOnLogin? I guess ZLib's version checking is completely unnecessary for users who have set that to true, since all versions would have already been checked.

The next revision (which I'll commit whenever SourceForge goes back up) will skip SVN version checking for users who have already automatically updated SVN.

Also please _svnUpdated (which is true even after issuing a successful manual svn update).

Moreover, I would say that automatic updates are actively harmful, unless you can guarantee that new versions of zlib never use any mafia features newer than latest point release.
 
@xKiv: Yep, that's how I did it (note wording above). r36 should hopefully spell the end of frustrating update issues when a host goes down (assuming mafia still sets _svnUpdated to true; and if not, you can).

Harmful to whom? Error reports due to using an out-of-date version of one of my scripts have dwindled to nearly nonexistent. My scripts also take advantage of the "since" command to avoid problems caused by using a non-current build of mafia.

Automatic updates are admittedly heavy-handed and I generally dislike and disable them as a rule on software I use. In this case, they are there for my sanity. I can forgive myself for the heavy-handedness given that 1) they're not baked into a piece of compiled software but are in an easily-editable script, and ii) anyone savvy enough to disable them is also savvy enough to try updating the script before reporting an error. It also fits philosophically with my desire to promote discourse in the language of ASH rather than single-author products discussed without reference to code, but that's an entirely different can of worms altogether.
 
I understand the desire to reduce insanity caused by out-of-date versions. Would you be willing to entertain the addition of a, non-default, variable that instructs your auto-update to stop running? Perhaps with a warning printed to the gCLI?
 
I understand the desire to reduce insanity caused by out-of-date versions. Would you be willing to entertain the addition of a, non-default, variable that instructs your auto-update to stop running? Perhaps with a warning printed to the gCLI?

As a control freak with a misguided belief in efficiency, insanity is having at least three different ways of checking for updates, two of which are not controlled by user settings. Zarqon and I have agreed to disagree on this point.

I confess to enjoying the smug sense of self-righteous indignation when I can respond to a bug report with "are you running the latest version?" so I am quite content to let the user decide how and when to upgrade, but since none of my scripts are widely used, this doesn't happen often enough to become annoying.

But any solution that stops trying to update (until rollover) after the first failed attempt to update will be fine with me.
 
Harmful to whom? Error reports due to using an out-of-date version of one of my scripts have dwindled to nearly nonexistent. My scripts also take advantage of the "since" command to avoid problems caused by using a non-current build of mafia.

Do you think "since" will prevent mafia from installing a too-new version of a script? I don't see any protection against that. It will just print a more intelligent error message with any action that uses the script.
 
@xKiv: Unfortunately no, but at least there will be no user confusion over the error.

@Magus: Such a variable (or rather, property) now exists, if you think about it. :)

@frono: Perhaps, for your amusement, I will post error messages in your threads caused by outdated versions of your scripts, just for old times' sake! Then when you smugly ask me about which version I am using, I will reply with the appropriate level of mildly embarrassed chagrin and let you know that the problem is solved!

at least three different ways of checking for updates

All but one of which are now controlled by user settings. But this makes me wonder if anyone is using ZLib's old "forum thread" method of version checking. I strongly doubt that I am.
 
Script execution aborted (java.lang.NullPointerException): (zlib.ash, line 314)


I have 0 idea what this means or how to fix it. Just started a few minutes ago, can't do anything that uses zlib.
 
That line is:

PHP:
file_to_map("vars_"+replace_string(my_name()," ","_")+".txt",vars);

So perhaps there's a problem with your settings file? Did you edit it manually at any point? Does KoLmafia somehow not have permission to read the file? Does the error stop if you rename the file? (Careful with that last one as all your settings will be temporarily deleted until you rename it back.)
 
I don't recall editing that particular line, unless it was in that section regarding SVN updates. That's the only time I've edited zlib manually (as far as I recall), for anything else I normally just use the gcli commands. Did not try renaming the file, can't until tomorrow. Auto-attack bypassed zlib again so I was able to finish the day. I did a manual update, just in case something was being stupid on my end somewhere. Will check back in tomorrow, and thanks for the swift response! <3
 
Sorry, I wasn't asking about your editing ZLib, but rather your ZLib settings file, vars_<yourname>.txt. Editing that in a non-text editor was all I could think of that might possibly be a cause for your error.
 
@Veracity: the list is huge and I don't know how to make those little scroll windows so my reply won't take up half the internet.

@zarqon: My vars I do through the gCli, when I edited zlib directly it was in notepad so, yeah. Was zlib updated yesterday? It's working fine now (after the manual update + new session) and what comes to mind is maybe there was an update posted in the middle of my session and it freaked out mafia? Also, I know this isn't zlib's fault, but mafia seems to keep forgetting I have access to that 70s volcano and won't fetch my volcoino through a script. Where would I stick that issue? :D
 
Back
Top