ZLib -- Zarqon's useful function library

Mysterious. vars[] isn't even a static variable -- it's loaded from your file every time you import ZLib -- so I have no idea where Barf Mountain could have come from if you had no such file. Check your mafia folder for any instances of zlib.ash and vars_CrankyOne.txt that may not be in the usual locations. That can sometimes cause confusion like this.

Are all the instances of the problem only experienced by people using Harvest.ash? I've never used it but possibly Harvest is attempting to do something with ZLib settings that I hadn't accounted for. In that thread someone had a settings file with the space in the name not replaced by underscores -- how in the blue blazes would that happen?? ZLib has always replaced spaces with underscores. That makes me suspicious that it's something to do with that script. I should probably go have a look at it.

@Veracity: Haha! NIH syndrome sounds about right! If we can do it exactly the way we want, why accept someone else's version? Or something like that. Most of my scripting energy is going to relay scripts these days and I will spend hours writing simple jQuery code that does what I want rather than add in some (already-fully-developed) plugin that already does what I want -- and 20 other things that I don't need.

Also, I treasure every instance of "Zargon" on these forums.

What I do not treasure is that someone gave ZLib a 1-star rating on SourceForge. This person says: "This is not zlib, this is a js library that couldn't find a proper name." A chronological snob! Now, anyone who Googles "kolmafia zlib" will see that it is rated 1 star in the search results. :(
 
After some poking around, I see a problem in Harvest, and a problem in ZLib.

Harvest: The relay script explicitly loads the settings map into vars[] in its main(). Again. This has always been redundant as that already happens in ZLib, but now that your vars data file doesn't contain defaults it's actually destructive, given that it has the effect of obliterating all the default values from vars[] that ZLib added back in when it was imported. This wouldn't be a problem if Harvest only used getvar() to reference script settings, but pre-transition it's kicking itself in the foot.

There are some other things I'd change about Harvest (Why assign all the vars to more variables? Why have announce() when you've already imported vprint()?) but that's the only thing I found in my first pass that is definitely a problem to do with script settings.

ZLib: was only adding the default values back in that were being initialized with setvar(). But in a larger script suite such as Harvest (or the BatMan RE world), scripts are referencing settings that haven't been initialized in that script. r34 adds all defaults back in, always. This was probably the crux of the issue.

So, I've fixed my side of the issue. Once Harvest removes the problematic line we should be all clear.
 
Hmm. I'm looking at the Harvest source, and I'm not sure what exactly you're referring to re: "explicitly loads the settings map into vars[] in its main()". I don't see anywhere in Harvest.ash that it assigns *anything* to vars[], for that matter -- it uses setvar() in its set_default_settings() call early on, but a quick grep for lines that contain both 'vars[' and '=' shows nothing other than the "assign vars to variables" bit you noted above. What are you referring to specifically?
 
The relay script -- which I believe exists to configure your settings -- not Harvest.ash.

Oh! Gotcha. Okay, I've removed the offending line from the relay script and pushed the resulting code back up to GitHub and Sourceforge. Thanks again for all your help with this.
 
Last edited:
What I do not treasure is that someone gave ZLib a 1-star rating on SourceForge. This person says: "This is not zlib, this is a js library that couldn't find a proper name." A chronological snob! Now, anyone who Googles "kolmafia zlib" will see that it is rated 1 star in the search results. :(

I gave it a 5-star review to help balance out that nonsensical review.
 
@Bale: :D

To be fair, the other zlib was first but I certainly didn't know about it when I named this -- nor did I think they would ever inhabit the same space (it was way pre-mafia-having-SVN).
 
It already says quite prominently "Zarqon's ASH function library for KoLmafia". I actually intended to add a note like that yesterday, but then Sourceforge encourages you to include keywords in your description, to help with people searching for things. I may just attract further disappointment by including the keywords "compression library". No one who uses ZLib would even find it via Sourceforge. :/
 
Thanks for the defense, friends!

Also, I've made a few be_good() additions for L2A: all familiars and non-martini booze will now not be_good.
 
I have some problems with zlib lately for the yaaz and volcano mining script. The volcano mining used to work fine 1 month ago.
I get : Stack overflow during ASH script: (zlib.ash, line 367) for yaaz

Stack overflow during ASH script: (zlib.ash, line 54) for volcano and yaaz

Is there something that changed in the script ? could it be my new computer ?
 
Try setting your verbosity a bit higher and tell me what you get before encountering the errors.

FWIW I got the same error on one of my scripts (no zlib usage at all, using r1095). Likely a Mafia issue. I did not get the same error with r18096 (yet).
 
The difference between r18095 and r18096 was the changing of CELCIUS to CELSIUS in two internal mafia constants.

Hopefully not the cause of a script error !
 
Ok so i got the same stack overflow errors for everything even ''zlib vars''. then I just typed zlib in the CLI and it updated the script to the last version and everything works now :) Thanks!
 
good-news-everyone.jpg

ZLib now has a new official script settings editor to replace the now defunct WOSSMAN: Prefref Plus!

It does everything you may possibly want to do with ZLib settings (filter, sort, edit, revert to default, delete, understand!) and KoLmafia properties too! Check it out!
 
Back
Top