ZLib -- Zarqon's useful function library

Xireph, you appear to be using a horribly outdated version of KoLmafia itself.

I don't know how out-dated it is, but I'll certainly upgrade from 14.0.

Xireph said:

I don't know how out-dated it is, but I'll certainly upgrade from 14.0.

Click to expand...

14.0 is about five and a half months out of date. Updating to THIS is good.

This new one is giving me troubles. Im getting an error about undefined refrence to function 'min' (zilb.ash line 79)

Phoenix Ninetales said:

This new one is giving me troubles. Im getting an error about undefined refrence to function 'min' (zilb.ash line 79)

Click to expand...

Upgrade KoLmafia. It is recommended to upgrade from THIS page.

FYI for helpful people such as Bale -- I've added some of that post I made earlier to the FAQ on the Wiki. Depending on how helpful you want to be, feel free to link to the Wiki's FAQ with a simple "RTFM." (Read The FAQ, Man!)

I have a different interpretation for "RTFM". One you can use after answering three posts in a row with the same link =)

It was always Read the Fine Manual with fine sometimes replaced with a different f-word depending upon how aggravating the situation was getting. In a similar vein, FNG was not always Friendly New Guy (or Gal). But either way zLib is pretty awesome and we can't thank Zargon enough for his work.

That's the beauty of acronyms; you can make them work for you.

(cf. the BatMan naming contest)

zarqon said:

That's the beauty of acronyms; you can make them work for you.

(cf. the BatMan naming contest)

Click to expand...

Wouldn't that then, strictly speaking, be a backronym rather than an acronym?

had an error with zlib...

i was getting an error saying something about zlib. i came here, saw that the bulk of the responses to having an error involved updating mafia version.

i upgraded, and everything is working just fine.

thank you to all of you who post replies to people like me... i've only been using mafia a few weeks, and every time i've had a question about what to do, people have been awesome about answering them, quickly and informatively.

thanks again!

I have been pondering the verbosity levels and wondering why I don't make better use of them. I think the problem is that I always have to go back to the documentation to figure out whether I want 3 or 4 or how -3 differs from 3. I am used to something like log4j where there are constants defined and the name of the constant makes it easier to figure out what to use and when to use it. Perhaps you might consider defining such 'constants' in the next version of zLib and/or creating an alternative wrapper for vprint?

Options might include (as stolen from log4j)

• The OFF has the highest possible rank and is intended to turn off logging.
• The FATAL level designates very severe error events that will presumably lead the application to abort.
• The ERROR level designates error events that might still allow the application to continue running.
• The WARN level designates potentially harmful situations.
• The INFO level designates informational messages that highlight the progress of the application at coarse-grained level.
• The DEBUG Level designates fine-grained informational events that are most useful to debug an application.
• The TRACE Level designates finer-grained informational events than the DEBUG.
• The ALL has the lowest possible rank and is intended to turn on all logging.

As laid out above "normal" verbosity would be INFO and all the higher priority messages would normally be printed.

I know in my case I would generate more user friendly output if I could easily use such a hierarchy to organize it.

Thank you.

You could just include your own wrapper / overloaded functions in your script that call vprint with the appropriate number for one of those keywords. Though it may be nice to have an "official" version.

Also, I have some ideas for improvements to check_version();
1) An overloaded, also takes a boolean version for relay scripts that prints special <div id=upgrade> content instead of delaying and cli printing.
2) An overloaded version that can check against the thread for a required KoLmafia version, similar to how the current script version checking is done.

@frono: While I appreciate that this idea may make the function more accessible to scripters, I don't much like the string-parsing bloat it would cause. And since StDoodle has suggested a quite valid workaround that does not add bloat to ZLib, for now I will leave vprint() as it is. What I will do, however, is edit your copy-paste to use integers and copy it into the ZLib documentation! Thanks, you and log4.

@Doodle: I like suggestion 1, check_version() could definitely play better with relay scripts. If it outputs a div of some kind, I think it should still print to the CLI as well, so it's just a matter of either setting a flag for your script to use, or adding relay detection/div output within check_version(). Makes me think I would like a way to access the top-level script name from within a script -- then relay scripts could be detected at runtime.

Suggestion 2 is unlikely to be useful. If they don't have the required version, quite often the script will be unable to even get to the point of running check_version(). Even if I'm missing something here, it feels like treating a symptom -- like the solution is being applied in the wrong place. If your script requires a certain mafia version, add that check to the top of your main().

zarqon said:

@Doodle: I like suggestion 1, check_version() could definitely play better with relay scripts. If it outputs a div of some kind, I think it should still print to the CLI as well, so it's just a matter of either setting a flag for your script to use, or adding relay detection/div output within check_version(). Makes me think I would like a way to access the top-level script name from within a script -- then relay scripts could be detected at runtime.

Click to expand...

Still having CLI output is certainly not a huge issue in my mind; mostly the wait() is, as a user isn't necesarrily looking at the CLI while the delay happens, so it can be quite confusing.

zarqon said:

Suggestion 2 is unlikely to be useful. If they don't have the required version, quite often the script will be unable to even get to the point of running check_version(). Even if I'm missing something here, it feels like treating a symptom -- like the solution is being applied in the wrong place. If your script requires a certain mafia version, add that check to the top of your main().

Click to expand...

Not necessarily. I, for one, get rather annoyed when I download a script after being prompted for a new version, only to find that I also need to upgrade mafia. Some daily builds I haven't felt like using right away. Mostly when new, big features are added that may have some bugs to shake out & I'm still in the middle of a run I care about (which is admittadly rare).

Even more often, it's an issue when I want to use a script, but don't want to log out of mafia & back in; I often have very little time right before rollover to play and / or don't want to abandon a conversation in /clan.

I'd rather be told ahead of time that there's a new version of the script, but I'd need to upgrade mafia to use it.

For reference, it's entirely possible you're misinterpreting what I suggested (as I did kinda type it spur-of-the-no-sleep-in-a-while-moment). What I meant to suggest (and what relay_Custom_Daily_Deeds does) is that first, the script checks to see if a new version is available. Then it checks to see if a req'd min. version is listed in the post (similar to how the version itself is checked for, but using a size tag instead of bold), and compares to the current mafia version using get_version(). If a new script is avaialable, but listed-in-post revision number requirement is > get_version(), a different message is displayed (update mafia to enjoy a new version of x blah blah).

zarqon, I'd like to put in a request for the next version of zlib. Could you add a line that checks vars["verbosity"] to see if it is an integer, and set it back to the default of 3 if it is not an integer? (Or at least treat is as a 3 if non-integer.) In a script of mine an error was not being seen because their verbosity was blank.

I don't know why so many people have messed up verbosities, but non-numeric values are a definite problem that could at least be cleared up. The fact that a bad verbosity makes itself know by not displaying any feedback is rather unfortunate.

The point of allowing a verbosity of 0 is for users to be able to separate mafia output from script output. Verbosities were set under the assumption that anyone with a verbosity of 0 would have deliberately set it to 0, and would know how to change it back.

However, somehow many newbie users have had verbosities of 0 without ever specifying that, which means that scripts give users no clue what's going on. This is awful.

I think what I will do is print a warning message once if your verbosity is 0. Something like:

WARNING: Your verbosity is set to 0. This means that many scripts will not display anything when they run, possibly confusing or frustrating you. To change this back to the default, type "zlib verbosity = 3" in your CLI.

I wasn't complaining about a verbosity of "0". I was complaining about a verbosity of "". Nobody should ever set their verbosity to something that isn't an integer and that should be assumed to be a mistake.

This may not be all the problem verbosities, but it is a subset that can be easily fixed.

Oooh, I have a better idea.

In setvar(), the data type is known, so canonizing ZLib settings is possible whenever a setting is declared. I'm thinking now of resaving the map in set_var() with canonized values if to_string(to_type(vars[setting])) != vars[setting].

This means if you typed "zlib is_100_run = badger", the next time that setvar() was called for is_100_run, that setting would be resaved as "Astral Badger", since to_familiar("badger") == $familiar[Astral Badger].

EDIT: Map keys are initialized blank if they are referenced before being assigned, for example in an if check! This means that something (such as vprint()) is accessing vars[verbosity] before setvar() is called. Still trying to track down the source of this stupid verbosity 0 problem.

zarqon said:

WARNING: Your verbosity is set to 0. This means that many scripts will not display anything when they run, possibly confusing or frustrating you. To change this back to the default, type "zlib verbosity = 3" in your CLI.

Click to expand...

No.
Please. Do. Not. Do.

As for hosing verbosity, I am using relay_zlib.ash which may or may not be a factor and the first time I noticed it had been hosed there was a lot of switching characters and multiple instances of mafia. But I don't have enough detail to reproduce the problem.