ZLib -- Zarqon's useful function library

Rinn said:

GMT (or kol time), and if it was down to the second it wouldn't matter if a newer build was posted a half hour later. The script author could just use whatever compile time of mafia they're currently on because clearly if they're writing a script in some version it has all the functionality needed. At worst it would force people to get a newer daily build when they don't actually need it, which they should be doing anyway if they're running daily builds in the first place. None of this is different then using the version value, except that it solves the problem of multiple different numbers because now you don't have to maintain two version checks, just a single date-time check. Either way, version or time, if you want to prevent fifty people from asking how to solve the exact same issue you need to have some kind of error checking in the first place to solve the problem for them.

Click to expand...

I myself have the Unofficial Builds forum RSS feed in my Google Reader. I know usually within 5 to 15 minutes of a new build. From that post i can directly download the new build and save it over my current mafia build. Easy-peasy. I wouldn't want this functionality built into any script, especially if multiple scripts i use daily had to do a server check to see if it needed to update (pretty much all my scripts that i run already do a server hit at first to check if its the current version of the script itself). A script should only take care of its immediate functions. If functionality like this should be built into anything, it should be an optional setting within mafia itself, and i'd have it switched off. I prefer to read what has been changed/added/removed from the build before running it and the RSS feed works amazing for that.

I don't think any of these proposals adequately solve the issue -- the proposed solutions are easily breakable by script authors themselves forgetting to designate the proper date/build/version. Further, scripts that don't use recent features may not need the more recent specification, making the forgetting more likely since the change is not required every time, and making users annoyed in the case that authors take the easy option and alway require the latest daily. Additionally, authors would be required to not only update version numbers for new releases (on the forum and in the script), but also research and update the required mafia version in the script -- a hassle. I dislike doing updates enough as it is.

One easier idea might be a special function specification for recent functions, i.e. "ashreq item_drops_array();" During parsing, if no item_drops_array() exists in ASH, mafia would abort with a message that a newer incarnation of mafia is required to run the script. It would age nicely, and not require authors to make further updates. It would only generate errors where actually applicable, as opposed to version specification which is easily abused by authors. It could be removed after the author was fairly certain that no one was using an older version, but would harm nothing by remaining there.

But for now, a FAQ post that we could link to would be nice. After making the post, perhaps fewyn could even add a button for quick reply that adds

[thread=XXXX]RTFM[/thread]

into the post.

Ooh, yeah, ashreq sounds like it'd work excellently. But how to initially implement it? (ashreq ashreq? =D)

But the RTFM quick-reply would be good, too. I'd imagine that not everyone would use it, so perhaps a Greasemonkey script or something like that...?

ashreq has the same problem as versioning in my opinion. Either you gotta add some kind of version checking in your script, or someone is gonna ask why a function isn't defined. I'm all for letting users fend for themselves.

How about this for a stopgap? Starting in r8409, the function not found error message includes the text "This script may require a more recent version of KoLmafia and/or its supporting scripts.". That may be a bit confusing when it happens with a script you're writing, and won't handle more fundamental changes (like the 'script' directive or the 'sort' statement), but should cut down on the idiocy a bit.

Anything that has a chance of reducing idiocy gets a thumbs-up from me.

Jason, thanks for the stopgap. It will help.

Ideally, something like ashreq would be introduced at the same time as a fix to a major case of KoL breaking mafia. Users running pre-ashreq versions would find it intolerable. Failing that (or in addition), script authors could avoid using it until both the latest build and the latest version include it. I would be fine with that.

Another alternative is mafia opening a FAQ in a window when you get your very first script-generated parsing error. After that, it would be silent.

zarqon said:

Ideally, something like ashreq would be introduced at the same time as a fix to a major case of KoL breaking mafia. Users running pre-ashreq versions would find it intolerable. Failing that (or in addition), script authors could avoid using it until both the latest build and the latest version include it. I would be fine with that.

Click to expand...

In other words, it would be best if ashreq wasn't added until Veracity was ready to roll a major release, if there was interest in adding it at all.

I like my second option better. Since everyone who gets a parsing error would have seen that FAQ, it makes our frustration at those questions justified.

Expected ;, found + (zlib.ash, line 222)

New version of Mafia. Get it.
(Compound assignment operator, I presume)

Gotcha, thanks. I've been holding off since some of dj_d's scripts I use need tweaking to work with newer builds, looks like this is just the push I needed.

Scroll up. A little further... did you reach post 367? Good.

OK, downloaded latest build, zlib & daily dungeon.
But the vprint never prints. Added some debug and it seems the verbosity is not set to anything so on zlib line 45 : if (to_int(vars["verbosity"]) >= abs(level)) print(message,color);
the to_int returns null, and so it is false and never prints.

And yet I see line 474: setvar("verbosity",3);

EDIT
OK... // effect. You can view ("zlib vars") or edit ("zlib <settingname> = <value>") values in the CLI.
Putting zlib verbosity = 3 fixed it... no idea how it got set to 0.

ZLib variables are stored in a datafile called vars_[charname].txt (in \data). They're created via setvar(), accessed via vars[], and modified in several ways (entering "zlib [variable] = [value]" into the CLI, using this relay override script, or directly modifying the datafile with a non-formatting text editor like Notepad).

I'm not sure that I answered your question completely, so I'll add some more: user-defined functions like vprint() have to be defined before they can be called. What you see is where the function is being defined. It then can be called from any script that imports ZLib (including ZLib, obviously).

As such, verbosity is set before vprint() is ever called, so there should be no conflict.

If it's still returning null for some odd reason, can you see if verbosity has even been set in the first place? (That relay override script provides a quick and easy way to do so.)

Feature request:

In other environments, I've found it useful to be able to modify / add to the error handling routine. Mostly for situations similar to calling abort() from ash; perhaps you have a map of user preferences as they existed pre-script that you'd like to reset. Or perhaps you want to re-equip what a character was wearing. Etc. Being able to do this on an abort() would be wonderful; perhaps such a feature could be added to zLib?

Edit to add (grr... can I ever remember to add everything before hitting "Reply"?):

Of course I don't expect this for abort() per se; having it function for vprint() w/ verbosity of 0 would be what I had in mind.

That feature already exists. You'll want to edit vprint(). Basically, none of my scripts contain abort(). They all contain vprint(message,0). I've tried to encourage other script authors to do this as well, for precisely the reasons you mentioned.

I follow you, I'm just saying it would be nice to have a standard way of handling it such that any script I made relying on such modifications didn't need to include its own special version of vprint() and hence its own version of zlib.ash. But I'm operating under the impression that one cannot overload an ash function such that the new version has the same parameters as the old; if this is wrong, my apologies.

Something like a vprint(message,0,"cli-executable string")? I don't know of a way to include arbitrary ASH in a function.

You could pass the name of a function and "call" it by name.