ZLib -- Zarqon's useful function library

Bale said:

While I'm happy that you're producing this editor, I'm still rooting for zarqon to finish his version. I'd like to be able to change these variables without ever needing a user to download a separate piece of software. I'm very much looking forward to the WOSSMAN.

Go for it zarqon! WOSSMAN, Banzai!

Click to expand...

LOL I understand. Zarqon and I had a brief pm conversation about that when he announced the pending functionality, and I decided to keep working on the project mainly as an exercise in programming. I understand that most people are probably not going to use my program, and that's cool. I am mostly just looking for a good way to contribute to the community since I don't know ASH. The moral of the story is that I am excited about Zarqon's version as well.

I'm very glad you don't find my interest in the WOSSMAN to be insulting. So far all I know about it is what I can glean from commented-out lines in zlib. I'm a bit concerned about needing to edit a password into zlib before it can be used. I'd rather that the user didn't need to do that, but I'm not going to try to second guess it before I see the finished version.

Should obtain abort if it returns false? Or should I be using it like this:

if(!obtain(1,"item",$location[here])) abort();

Update

I have added settings editing to ZLib. Nothing fancy, but now you can call ZLib directly to change the value of a setting. Use it like so:

in the CLI: "call zlib settingname = value"
directly from the scripts menu: in the popup box, enter "settingname = value"

Basically just like the CLI's "set" command for mafia settings, but with one key difference: you cannot edit nonexisting settings.

You can also adjust your threshold using "up" and "down" rather than a specific value.

@FN Ninja: Yes, your script should use the result of obtain, since it will not abort.

@brenny: I'm looking forward to your editor! Everyone likes doing things differently, so there may well be some peeps who prefer your tool to the WOSSMAN.

@Bale: due to various implementation problems, the password cannot be a script setting. Thus, the password must either be a variable or a mafia setting. I've worked out something that's both, so that once the user sets it once in either place, they don't need to set it again even after downloading an update. (See the commented code right above main()).

The other option is leaving the data unprotected. This would allow unscrupulous scripters to screw with other players' script settings (although I've not heard of anything like this happening among mafia users).

As always, I'm open to feedback.

To anyone who was using the spaces_to_underscores function and don't feel like rewriting anything (I know I was too lazy to go redo it all), here's some code you can add to your script to replace the functionality:

Zarqon, a request.

As a scripter, one of the "penalties" I pay for sharing the things I enjoy is maintaining them. Every time something breaks in one of my scripts, I have to go back and fix it, and re-upload it, and change version numbers, etc.

Now I know one of my scripts uses spaces_to_underscores. I don't remember which one. I'm going to have to retest them all (or remind myself of how to use whatever the DOS equivalent of grep is) to fix it, update it here, etc.

In the future, could you make a "once its in zlib, it's always in zlib" rule? Even if you just alias a zlib function to an ash function. That would save a lot of headaches.

Thanks!

dj_d said:

Now I know one of my scripts uses spaces_to_underscores. I don't remember which one. I'm going to have to retest them all (or remind myself of how to use whatever the DOS equivalent of grep is) to fix it, update it here, etc.

Click to expand...

Do you use Notepad++? If not, you should check it out. It's free and a life-saver for ASH scripting.

If you open Notepad++ and hit ctrl+shift+f, you can point it to any directory and it will find any text you wish, i.e. "spaces_to_underscores", in every file in that directory.

But I do agree with your larger point that a "library" should be very cautious about removing function calls. I would say a better approach is to mark a function "DEPRECATED" in big bold notes everywhere in the code and make a note in the docs that it should not longer be used. That buys people some time to excise it from their code before you ultimately remove it.

Apologies -- I had no idea anyone was using that function. It was only in ZLib for two months, and replace_string() can do what it did, but better. Weeks ago, I simply edited it to what flypapermonk posted above, but I figured only one or two people might need to edit their scripts, which would be easy since I was sure the function was not widely used. So in the interest of optimal scripting and streamlining ZLib, I removed it.

Needlessly Detailed Reponse
(skip to the summary if short on time)

I promise that I will only remove functions if something far better is added to ASH. It is my philosophy not to have just functional scripts, but optimal ones. On the other hand, it is also my philosophy (as evidenced by just about everything I've posted/shared/made) to provide useful, easy-to-use scripts and scripting resources for the mafia/scripting community, with a minimum of inconvenience. So, while I strive to make ZLib of maximum usability to all, I view one such use as promoting script optimization.

In this case, replace_string() is superior in every way to the old ZLib function. Though you may not like having to replace it, it's for your script's own good. I feel this is akin to when the change was made disallowing = (requiring ==) in conditions. Most everyone had to track down these places and fix them, but it was better.

Here I simply removed it due to its short lifespan and very specific application. However, if an ASH equivalent to obtain() were to come along, I would simply make the existing ZLib function a wrapper for the new ASH one.

Summary
Don't worry. I am very considering and cautious about changes to ZLib, since I know that now (surprisingly enough!) quite a few authors are using it.

Good to know - thanks Z.

Z this script is indispensable! Every time I start writing a script the first thing I do is import zlib!

The only problem I've encountered so far is when using the "choiceadv" option in obtain. If I run out of adventures while trying to obtain a choice adventure it doesn't print the out of adventure error message and it returns true.

If choiceadv is passed to the function as the cond the following line doesn't catch that I've ran out of adventures:

I'm not sure why this is happening.

Thanks for all your hard work.

I've added a few things to ZLib:

1) to resist() -- if buffs/gear switching fails, attempts to gain resistance from your Exotic Parrot if you have one. Note that this does not consider the is_100_run setting (Daily Dungeon/basementing/Trapper quest all don't affect a 100% run as far as I know -- it's only Guano Junction that may cause problems).

2) auto_mcd() -- skips altering the MCD for boss zones that grant different rewards depending on your MCD.

I've updated the first post, but not the version number. Once something more important is added in, I'll consider these updates part of the next version. But I wanted you to have them available. Enjoy.

zarqon said:

I've added a few things to ZLib:

1) to resist() -- if buffs/gear switching fails, attempts to gain resistance from your Exotic Parrot if you have one. Note that this does not consider the is_100_run setting (Daily Dungeon/basementing/Trapper quest all don't affect a 100% run as far as I know -- it's only Guano Junction that may cause problems).

Click to expand...

The stress should be put on non-combat adventures won't affect 100% runs. I'd be the person who screws up. I panicked all the way thru kittycore lol. And today I wore my sugar shorts thru several adventures more than intended (till they turned into shards) because I spaced it.

Hey Zarqon, have you ever experienced the problem with obtaining choiceadv that I mentioned a few posts back? Further testing is revealing more of the same.

@Spiny: I know, I'm doing kittycore right now and I kept my cat on the whole time just out of fear.

@FN Ninj: I haven't ever had that problem -- but that's because I rarely use the result of obtain(). It's on my list of scripting things to look at. If you have any further information from your tests (not just about obtain, but about adventure() when the only condition remaining is a choiceadv), that might save me some time.

Okay, I think I got it working. When using conditions adventure() will return false if conditions are not met within the turns specified so I changed this portion of obtain:


to:

So far it has been working as intended with these modifications.

I doubt that would work unless there has been a change to the mechanic of adventure(). My previous testing showed that adventure() returned false if it stopped due to satisfied conditions, which means your code will return false when obtain is successful.

You're absolutely right. When using conditions adventure() returns false whether the conditions are satisfied or not! So scratch that code. That implies though, that this line is part of the problem:

When you run out of adventures trying to satisfy a condition adventure returns false and the return error("Out of adventures."); doesn't ever get triggered.

obtain() returned false when I run out of adventures trying to get an item, but the "Out of adventures." error message was not displayed indicating that the unsatisfied condition is what caused obtain to return false and not the error function.

With choiceadv obtain will always return true because even if you don't get the choice adventure this line is triggered :


That's what I've found so far.

So I guess we need


??

Still would break if you got a choiceadv on your last adventure, but might be an improvement to always breaking for choiceadvs.

Yes, that would be a drastic improvement. As far as breaking if you got a choiceadv on your last adventure I don't think that would be as big a problem. It probably wouldn't happen too often and when it did, a script using obtains return value wouldn't have any adventures left to mess with. Thanks for looking into this.

On another topic what is the type produce for your best_fam function? Is that for familiars that give you hp/mp in combat? And can I request in addition to meat, items, & produce that there be a stat option as well? That would be nice.

Ok, that small change to obtain() will be in the next update. Thanks for helping debug that.

The "produce" type is for familiars that produce meat during combat (as opposed to just +meat). It is used by OCW to help you get more meat from the nuns if you have that option set.

And yes, the familiar types data file was meant to be expandable. I just haven't taken the time to expand it. You can feel free to modify the data file yourself -- the format is very simple.

<familiar name> (tab) <comma-delimited types>

For example:


Then, upload it here for the benefit of all.