ZLib -- Zarqon's useful function library

Whenever I attempt to run ZLib, I get: "Undefined reference to function 'modifier_eval' (zlib.ash, line 67)". Has anyone else experienced this error?
 
The council is pretty easy. I usually just include

PHP:
if (my_level() != get_property("lastCouncilVisit").to_int()) visit_url("council.php");

for quest-sensitive scripts. That works for almost all of them.

The guild, on the other hand, is definitely something that needs reworking in CanAdv (the present function is mostly a placeholder). Calling the CLI "guild" is just a stopgap and is sometimes undesirable. It needs to be smarter about knowing when to check in with the people in your guild (and when to check in with them more than once).

I was recently getting hobo glyphs for a level 25 character who hadn't done any of the Epic weapon quest (although he had one from previously); he had to visit his guild's appropriate person three times to unlock the Fun House.

@Bale: hehehe. Or, as they say in Korea, kekeke.

I had missed the lastCouncilVisit property, I'll go add that to pageCache right now, thanks!

BTW the spanish version is jejeje (or jajaja)
 
I was thinking about this earlier today and I realized it's basically possible to automatically update a script in mafia:

Code:
void update_file(string url, string filename)
{
    buffer ash = visit_url(url + filename);
    cli_execute("mirror " + filename);
    print(ash);
    cli_execute("mirror close");
}
That will basically download a file and save it to the root directory of mafia. Additionally, for people that are a bit more handy mirror supports a filepath as well as a filename, so you could basically update all your scripts on login if you specified the exact path to write the file to.

On normal use I would expect you would want to save download files into a folder such as ./updated_scripts/

There are three issues I can see with this currently, first if you're not forcing an overwrite of the version in the script directory there's no way to know whether or not an updated version has already been saved to ./updated_scripts/, second it's possible some other output could get printed while the mirror is open, and thirdly the script filesize could be larger then the buffer. I think all of these issues could be overcome with small changes on mafia's side.
 
Does this mean that you could overwrite other files (not created by your script to begin with) and screw with people that try to use a script? I suppose a script could do much worse, like kmailing all your meat to the script writer, but it's good to know exactly what the potential risks are in a script.
 
I'm not sure if mirror appends or overwrites (another possible issue) but yeah I suppose you could.
 
I consider that comment a clap on the shoulder for a job done successfully.

@Rinn: Interesting. Have you done any experimenting or is this still mostly theoretical? What are possible locations for mirror to save to? Can it save a file as any extension? That seems a little dangerous.
 
ZLib 12 Updates!

Tiny update: added abs(), for both ints and floats.

Much bigger update: There have been several requests for (and I've seen quite a few other scripters implementing) wrappers for print() that depend on a "verbosity" setting. In addition, I don't like the all-too-common situation of
PHP:
if (condition) { 
   print("message"); 
   return true / false;
}
just to be able to return a boolean with user feedback. I added the error() command to ZLib a while ago as a way around this, but only for false.

ZLib's new vprint() is a way to kill all the birds with one stone:

boolean vprint(string message, string color, int level)
boolean vprint(string message, int level)


The parameters message and color behave exactly the same as in print(), so let's talk about level.

First, level controls the return value -- if level is positive, vprint will return true; if negative, it will return false. If level is 0, vprint() will abort with the specified message. You can see now that vprint already replaces both abort() and error(). I recommend using it in place of abort() in case a savvy user wishes to avoid or otherwise handle aborts somehow.

So this takes care of my annoyance with needing brackets and two commands just to return a boolean along with user feedback. How about the verbosity issue?

Ladies and gentlement, there is now a new ZLib setting "verbosity" (integer). If the absolute value of level is more than verbosity, the message will not be printed. This allows users to control the chattiness of scripts, and allows authors to include debug print statements which can be shown by setting verbosity high.

Recommendations for Verbosity Levels in vprint()

0: abort error
+/- 1: absolutely essential (and non-cluttering) information -- use very sparingly, since a verbosity of 1 is basically "silent mode"
+/- 2: important and useful info -- this should generally be your base level for your most important messages
+/- 4: interesting but non-essential information
+/- 6: info which an overly curious person might like to see on their CLI
+/- 10: details which are only helpful for debugging, such as "begin/end functionname()" or "current value of variable: value"

This will allow users who want extra levels of detail printed to see that detail without cluttering the CLI for users who don't prefer to see all the details. In addition, it allows users to specify a verbosity of 0 to see ONLY mafia output (no script output at all), which could prove handy.

There is also a version of vprint() without the color parameter. The default color is black for positive values of level, and red for negative values. So, basically you don't need to use the version with color unless you want to specify a different color or override the default colors.

Conversion

NOTE: This function deprecates error(), since vprint(message,-X) is identical. I'll give everyone a month or so to make the changes, and then will be removing error() from ZLib.

I will be converting all of my scripts to use this system, and recommend that others who import ZLib do the same, for consistency of user experience. To convert your script, replace every instance of print(), abort(), and error() with the new vprint() for a new level of universal user control over script feedback! I also recommend replacing every "return true" and "return false" with a more meaningful vprint() command.
 
the 25 second wait is infinitely better than the pop-up dialog box that halted all script activity!

They're both pretty shit.

I'd much rather just have a note in obvious (mildly oversized, coloured or both) telling me that there's a new version. Given that whatever scripts I have will always work with the previous version of ZLib (because I was already using them), I don't need to be slapped in the face with the fact that there's a new version available.

tl;dr - I'll upgrade when I feel like it, the library doesn't need to throw a shitfit till that happens.
 
Well then make editing the library to remove the wait part of your update routine. I know you're a capable scripter and it shouldn't be a problem for you. Regardless, it's not my problem.
 
This is a trifle annoying...

New Version of ZLib Available: : 11
Upgrade ZLib from : 12 to : 11 here: http://kolmafia.us/showthread.php?t=2072
Countdown: 3 seconds...
Countdown: 2 seconds...
Countdown: 1 second...
Waiting completed.
 
Did you read the bold note right above where you download the file?

Too bad to_int() errors out on non-numeric characters now, or there would be a workaround for versioning that includes numbers.
 
No, I didn't read that note, but I did figure it out for myself. Would you like a regexp that returns only the numeric characters in a string? So that you could make your own to_int()...
 
Ack! Nnnnooooooo i thought you were my friend

EDIT: Wow, I typed that in all-caps but the forum converted it! NNNOOOOOOO
 
Would it be possible at some point to get a vprint version of print_html(), too? I like to use print_html() for bolds, etc. (And so do you, I see, in these update messages people are so persnickety about!)

Edit: Also, a question re: use of verbosity. I have several functions specifically designed to produce output, mostly for use in aliases. Presumably, no-one would call them without wanting the output. This suggests a level 1 for output from those functions, because as it is their only function the output is essential to their function. On the other hand, they are hardly producing life-changing information, and level 1 ought to be special.

Is this just a case where vprint() is the wrong answer and I should stick with print(), or do you have any suggestions?
 
Last edited:
Back
Top