ZLib -- Zarqon's useful function library

[Bale]

Second, would it be possible to have the "vars.txt" files stored elsewhere so they don't appear on your scripts menu? If you're running multiple characters, that menu gets cluttered up quickly.

2) Mafia automatically creates maps in the scripts directory (which makes no sense, since mafa can't execute maps), so there is no way to change their created location. However, after they are created you can move them to your data directory yourself, and then they will still work just fine, without cluttering your scripts directory.

BWA-HA-HA! As of this revision that is no longer true! Jason just fixed things (at my forthright request) so that maps are now created in the /data directory instead. That's been bugging me for a while so I'm glad that this made me think to request the feature change.

 

[zarqon]

List of heroes: +Bale and +Jason.

This removes quite a lot of user annoyance for scripts that create data files at runtime rather than coming with them. (i.e. most of mine)

 

[cakyrespa]

Minor little suggestion for ZLib. I'm getting ready to head out to GenCon and decided to spent a few hours having fun trying to make a "OMG, apparently I needed sleep more than the sucking electrons off my laptop" script. I.e. a little maintenance script in case I forget to get online after playing WAY too many games this year.

So, one of the things I noticed is that user_confirm and cron jobs do *not* play well together. I encountered this with the version check of zlib since I haven't updated the version. So, I thought I'd make another little function to help with that:

//                             SCRIPT ROUTINES

[b]// returns true if the session is identified as interactive
boolean is_interactive()
{
   if (to_boolean(vars["noninteractive"])) return false;
   return true;
}[/b]

// checks script version once daily
void check_version(string soft, string prop, string thisver, int thread) {
   if (get_property("_version_"+prop) != "") return;
   print("Checking for updates (running "+soft+" ver. "+thisver+")...");
   string ver = excise(visit_url("http://kolmafia.us/showthread.php?t="+thread),"<b>"+soft+" ","</b>");
   if (ver == "") { print("Unable to load current version info."); return; }
   set_property("_version_"+prop,thisver);
   if (ver != thisver) {
       print("New version available: "+ver,"red");
       [b]if (!is_interactive()) {
         print("Visit http://kolmafia.us/showthread.php?t="+thread+" for the latest version.", "red");
         return;
       }[/b]
       if (!user_confirm("A newer version of "+soft+" is available.  Continue anyway?"))
         abort(soft+" stopped.  Visit http://kolmafia.us/showthread.php?t="+thread+" for the latest version.");
   }
}

setvar("defaultoutfit","current");
[b]setvar("noninteractive",false);[/b]
check_version("ZLib","zlib",": 4",2072);

I had to move "SCRIPT ROUTINES" section below the Wossman stuff, mainly so vars was declared. I kept in the message about a new version, mainly because I like to know the version, but I just wanted any calls to "user_confirm()" not to show up. It defaults to interactive (i.e. noninteractive is false), just because most people don't want to bother about this stuff.

EDIT: Forgot to ask a question. Is there a function like get_safemox() that would get the minimum moxie for an area but not adjusted for mcd and monster_level_adjustment()? I was trying to figure it out since I wanted to keep using the vars["threshold"] settings but I couldn't get my numbers to work out.

 

[mredge73]

Why don't you include a parse_mail() function in Zlib similar to your one in registry.ash?

 

[zarqon]

There have already been complaints about the user_confirm() being an annoyance. But I am not going to budge on this one. I've had too many bugs reported by users running older versions. Users who are comfortable modifying scripts can easily edit their local copy of ZLib, and users who are not comfortable making those modifications should be annoyed until they update, rather than annoying me. Unless there is something broken, I try to wait until several new things are added before updating scripts.

Also, you could easily compensate for the ML adjustment of get_safemox() by adding it back in.

@mredge: I tend to think that the majority of scripts do not parse mail. Broad range of applications is an important consideration for inclusion in ZLib. If you want to use it, feel free to copy that section into your script.

Coming Soon to ZLib

The next ZLib has a little thing I've always wanted: a print() command that prints in red and returns false! Now I don't need brackets for print(error,"red"); return false; anymore!

Also, I improved auto_mcd() by adding a setting called "unknown_ml" which defines the strength you want to assume for unknown zones. Now, rather than automatically setting your MCD to 0, it treats unknown zones as having a safemox of unknown_ml. This allows you to play it safe at low levels (particularly helpful for low-level wormwooding), yet boost ML once you have more power and a deeper HP reservoir.

 

[Bale]

I'd rather not modify my local zlib because then I have to re-modify it every time a new version comes out which makes me very reluctant to update. (I'm having enough trouble with my personal variant of BBB) With that said, I have no incentive to turn off user confirmation since it is necessary to make me notice the update. I'm grateful for it, but I emphasize strongly with those who want to remove it as an annoyance.

Would it be so awful to use setvar("zlib_update_confirm", true)? You could leave the feature undocumented...

 

[cakyrespa]

Well, there is another approach to the problem you suggested to: requiring version.

import <zlib.ash>
require_zlib_version("4");

I would see require_zlib_version() to check for exact match. If it doesn't (like the upgrade), it throws a user_confirm() and aborts. No if, ands, or buts. For those who use non-interactive setups or command-line, they probably will have their scripts and the appropriate versions set up. One would also assume they are "mostly" happy with it or will deal with it at a different times. If you allow the new version check to be noninteractive, it still shows up user_confirm() for most people and just a message for noninteractive use.

That way, the message comes up when you don't have the version you need, but optionally when there is something new (which during rapid development, everyone might not care about as much).

The other advantage is that if require_zlib_version() always aborts if it doesn't match, then you'll get less support requests because they'll have a message specifically telling them their version is out of date.

"And did you pay attention to the message that says you needed version 5?"

I'd like to find a way that doesn't require customizations to fit an environment. zlib is a great little library of functions. I'm sure there is a way that could reduce your problems with support while still getting those little additional features.

 

[Rinn]

I'd rather not modify my local zlib because then I have to re-modify it every time a new version comes out which makes me very reluctant to update. (I'm having enough trouble with my personal variant of BBB) With that said, I have no incentive to turn off user confirmation since it is necessary to make me notice the update. I'm grateful for it, but I emphasize strongly with those who want to remove it as an annoyance.

Would it be so awful to use setvar("zlib_update_confirm", true)? You could leave the feature undocumented...

I was actually coming in here to ask about this, like bale I'm not a big fan of having multiple local changes to files that are updated frequently, but unlike Bale I have a scheduled task that runs everyday and a user_confirm will completely screw me.

Even the list of olfaction monsters at the top of FTF is kind of annoying to make sure my changes propagate to the new version when it's released (speaking of which could those options could be moved to a user var like ftf_olf_monsters and ftf_grin_monsters?), local changes deep in code are a lot harder to maintain.

 

[zarqon]

There are two user_confirm()'s in all of my posted scripts. One of them is in the update checking function, and one of them in in the MacGuffin script because there is no way to know whether or not a wooden wheel has been used without possibly wasting turns or straight up asking the user. I don't think that is too many changes to make to your local code.

Especially given that my scripts are not updated frequently. In particular, I try to avoid updating ZLib unless it is necessary. It has been over a month since ZLib was last updated. Even though I posted about upcoming changes, I won't actually update the script until something breaks, something in another script needs edited-ZLib support, or someone clamors for the announced feature. I don't like having to stop what I'm doing and go download an update to an already functional script any more than the next guy.

As for the olfacted monsters, those have stayed in the script because I've felt for a while now that I am on the cusp of being able to write much smarter auto-olfaction into FTF, but the necessary information is still inaccessible from within ASH. I may just move it into a variable because it's been a while and my hope for this capability is fading.

I kept the grin monsters in there just because I didn't think about it. Those will be moved out into a script setting in the next FTF update.

 

[Bale]

Have you considered adding olfaction based on mafia's one-time olfaction settings?

 

[zarqon]

How would I do that? I can access the mafia setting, and I can access whether or not the monster is the last remaining monster to drop goals, and I can even access the drop rate of those goals, but I can't access how many goals are remaining. So presently, scripted auto-olfaction would have to olfact such monsters even if they are dropping the last remaining item at a 100% drop rate -- something I don't feel comfortable implementing.

 

[cakyrespa]

There are two user_confirm()'s in all of my posted scripts. One of them is in the update checking function, and one of them in in the MacGuffin script because there is no way to know whether or not a wooden wheel has been used without possibly wasting turns or straight up asking the user. I don't think that is too many changes to make to your local code.

I know you don't want to add this, but I wish you would reconsider. Just as you think it is trivial for me, or someone else, to edit the files, I think it would be trivial to add a few lines to make it optional but default to use user_confirm(). The difference is, your trivial change shows up in everyone's code, every time they download it while changing it locally means everyone who wants it needs to make that change every time it was downloaded.

The other part is that zlib is a very useful library, and it is used by 6+ scripts already and no doubt going to be used by even more. And all of those scripts use check_version(). While zlib doesn't update frequently, I probably can't say the same for BBB, macguffin, Wossname, dailydungeon, or my own libraries. One of those is probably going to update every few weeks.

The third is I don't like local changes. It is bad enough I have local changes to KoLmafia (my crafting patch) which I can't take advantage of any useful script, it gets more cumbersome to work with minor changes to scripts. And, it is makes it even harder to remember to make a change when you update only every few months, and it won't become an issue until it nails you.

Yeah, I could make the change locally, but I really wish you would consider putting it in. I don't mind if you make it default to always use it, or require me to solve a quadratic equation to figure out what to put in there, but I'd like it to be part of the pristine zlib instead of local edits.

EDIT: I'd also like to see the macguffin question defautable with a setvar(). At this point, I only use macguffin for that question, so I already know the answer.

 

[Rinn]

There are two user_confirm()'s in all of my posted scripts. One of them is in the update checking function, and one of them in in the MacGuffin script because there is no way to know whether or not a wooden wheel has been used without possibly wasting turns or straight up asking the user. I don't think that is too many changes to make to your local code.

You don't need a user confirm for the wooden wheel, the middle chamber image changes when you use it. Before you use it the image in pyramid.php is "pyramid3a.gif" and after you use the wheel the image is "pyramid3b.gif".

 

[Bale]

How would I do that? I can access the mafia setting, and I can access whether or not the monster is the last remaining monster to drop goals, and I can even access the drop rate of those goals, but I can't access how many goals are remaining. So presently, scripted auto-olfaction would have to olfact such monsters even if they are dropping the last remaining item at a 100% drop rate -- something I don't feel comfortable implementing.

Oh, I didn't mean anything nearly so complicated. I just meant that it would be nice if you checked get_property("autoOlfact") and if it said "monster blooper", then you could olfact a Blooper. Or if it was "item ketchup hound", then you cold olfact the next monster that drops a ketchup hound. And let this take priority over your usual olfaction settings since it is user determined.

Mostly this would save me from making my first line "special action" which I don't want to do since it ruins the chance of SmartStasis using noodles or pickpocket.

I know that olfacting goals is much trickier and poorly supported by mafia, but I'd still rather if it only triggered if get_property("autoOlfact") was "goals". I once had it trigger on me for goals when I didn't want to use an olfaction.

EDIT: Why the heck was this brought up in the zlib thread instead of SmartStasis thread?

 

[zarqon]

@Rinn: Awesome, I didn't know that. Thanks! Less user annoyance, coming soon.

While zlib doesn't update frequently, I probably can't say the same for BBB, macguffin, Wossname, dailydungeon, or my own libraries. One of those is probably going to update every few weeks.

That's why they all use ZLib... if you had made the one local change to ZLib a month ago when the last ZLib was released, you would have been popup-free for a month and counting, no matter how many times all those other scripts updated.

If I were using an undocumented script setting to disable the confirm, people have to change a variable once/script lifetime, which is easy and which most users of my scripts are familiar with. Suddenly, I'm back to dealing with bugs that are already fixed. I'd rather disabling the confirm box be something only for people who are comfortable with scripting.

I just meant that it would be nice if you checked get_property("autoOlfact") and if it said "monster blooper", then you could olfact a Blooper. Or if it was "item ketchup hound", then you cold olfact the next monster that drops a ketchup hound.

That's a great idea! I like the idea of CCS transparency with mafia settings (cf. FTF's handling of poison removal). I'm not familiar with the possible values of that property, though. Can it contain more than one goal/monster? I want to know how much the script needs to parse.

I once had it trigger on me for goals when I didn't want to use an olfaction.

That's actually impossible. FTF only detects whether or not the monster is the last monster dropping goals, then prints a message. It only actually olfacts for bounties and your specified always-olfact monsters.

Why the heck was this brought up in the zlib thread instead of SmartStasis thread?

I'm not answering that question because it's off-topic.

 

[Bale]

That's a great idea! I like the idea of CCS transparency with mafia settings (cf. FTF's handling of poison removal). I'm not familiar with the possible values of that property, though. Can it contain more than one goal/monster? I want to know how much the script needs to parse.

Well it is set by the UI's custom combat settings, so you can just change it to various values and seeing how it works... As far as I know you can only choose 1 item or 1 monster or "goals" as the value. If you could chose more than 1 item or monster it would be interesting. Maybe I'll try that out later and see if it works, or if it gives me an error.

Also, the value can have " abort" at the end to have it stop adventuring after using olfaction.

 

[zarqon]

Bale -- continued this discussion in the FTF thread.

 

[mredge73]

I am looking to make clean up some of my scripts and incorporate zlib into them because of Zlibs popularity. I have a few questions about vars.

What is the purpose of using vars when you can just as easily use mafia's properties to do the same thing?

Is there a downside to using mafia's properties, I use them on almost all of my scripts as in I have variables in the properties that I created and use?

At first glance vars don't look like they can be changed internal to a script like the properties. It looks like they are initially set and can only be changed manually by changing them in the file. Am I correct? Or is it just a standardized map and can be reset by changing the map and rewriting the map to the vars file at the end of the script?

 

[kain]

one immediate benefit would be that you don't lose all your script settings should you have to blow out your prefs for some reason.

 

[Bale]

Another benefit is tidiness. It is a lot easier for the user to peruse a vars file than to try to find program preferences amidst a list of several hundred lines. Also I like to know that if I stop using a script, its preferences won't have to be with me forever just because they're lost in the midst of my preferences.

And they are just a map file.