ZLib -- Zarqon's useful function library

Yeah... if you use an old version and upgrade after using a zone that has changed, you'll likely need to do an update clear, as your copy will have override data files...

Or, for that matter, if you use the current version and run 8 adventures in the bathole. :) The screambat will cause you to have override data files... though those ones are ones you need until after 8780 is out, at least.
 
So yeah... made myself an update that has unspaded drops considered as a 1% drop rate, mostly so that they decide that increasing drop% is actually useful, and so that has_goal actually works.
> condition set

antique packet of ketchup

> ashq import <zlib.ash> float bestrate; location bestloc; foreach l in $locations[] if (has_goal(l) > bestrate) { bestrate = has_goal(l); bestloc = l; } if (bestrate > 0) print(bestloc);

Haunted Kitchen

> ash item_drops_array($monster[possessed silverware drawer])

Returned: aggregate {item drop; int rate; string type;} [3]
0 => record {item drop; int rate; string type;}
drop => antique packet of ketchup
rate => 1
type => s
1 => record {item drop; int rate; string type;}
drop => corn holder
rate => 15
type =>
2 => record {item drop; int rate; string type;}
drop => eggbeater
rate => 4
type =>
Click to expand...

The s, in this case, means that it needs spading... but at least it detects as a real live drop, and is available (and easily located in the data file in case of wanting to actually spade properly). :)
 
Hey, I promised / threatened it would happen, and now it has (or at least is in progress). ZLib is on the wiki!

Honestly, I've had to look up the functions in ZLib on several occassions, and think it would be of benefit to many to have them in the same place & in the same format as other ash functions. Sorry z, but this thing is too useful NOT to put there. :P
 
It's fine by me. I'm glad you managed to put everything in one place from its current multiple locations -- although the guide for script settings will change rather drastically with the advent of the WOSSMAN.

I can't guarantee that I will remember to edit that page when I change something in ZLib, however.

@Fluxx: KoB? Kingdom of Buffing?
 
zarqon said:
@Fluxx: KoB? Kingdom of Buffing?
Click to expand...

Yup. Kinks gave Kingdom of Buffing it's very own page on the KoL wiki 'cause he wasn't satisfied with the brief writeup on the buffbots page. The wiki administrators deleted that page because they couldn't understand why KoB was more special than the other buffbots. Then Kinks threw a shit-fit at not being able to document KoB's chat commands on the wiki and so he shut down KoB in protest. I was never clear about why he couldn't document these chat commands on the same site as KoB, linked nicely from his buffing webpage. The KoL wiki's talk page was lots of fun during the "drama". KoB remains shut down to this day so that all may regret how mean the wiki administrators were to poor Kinks.

Hence Fluxx's amusing comment. I chuckled slightly at the bitter memory.
 
Last edited:
And Bale wins the cookie! ... Wait, where'd it go?... Is that a rabbit over there?

And as for editing the page when you change something, zarqon, I think you have enough of a following to change it for you.
 
Having a weird problem that confuses me... trying to wipe out a value after it's set, and it doesn't want to go away. I'm setting BaleCC_nextSemirareLocation using a specific location, and then I want it to get removed after the adventure. The chain is something like this:
PHP: 
 setvar("BaleCC_nextSemirareLocation", locale);
 (!adventure(1, locale));
 setvar("BaleCC_nextSemirareLocation", $location[none]);

Problem is, that doesn't change the value... it stays on the value set before the adventure. So... what am I doing wrong? How do I fix this to update (or remove) the value after it finishes and it becomes irrelevant?
 
Theraze, the second parameter in setvar() is for the default value, which is used only the very first time that particular setting is referenced. To change it, try:
Code: 
vars["BaleCC_nextSemirareLocation"]=$location[none];
updatevars();
I'm 99% sure of the last line, but it isn't documented... harumph.
 
Last edited:
setvar() only creates the zlib var if it doesn't exist, the second parameter is the default value. If you want to change the value, you need to do:
PHP: 
vars["BaleCC_nextSemirareLocation"] = "";
updatevars();

EDIT: I should reload the thread before answering questions ^^
 
Last edited:
Sounds good... reason to use "" or $location[none]? I know if you screw up and do $location[non], it provides for a rather bizarre match. :)

Edit: Request for a new function in ZLib... removevar or delvar or something like that, for removing temporary values. This should make it easier to use setvar to put in temporary values that only need to be around for a set number of adventures, and remove them when done.

Similar to the code posted a while ago for unset for mafia preferences.
 
Last edited:
vars is a string [ string ] map, so $location[none] will be turned into "none", and both "none" and "" will be turned back into $location[none] wen you do:
PHP: 
vars["BaleCC_nextSemirareLocation"].to_location();

There's no practical difference here.

EDIT:
Theraze said:
Edit: Request for a new function in ZLib... removevar or delvar or something like that, for removing temporary values.
Click to expand...
Again, you can do that directly:
PHP: 
remove vars[ "BaleCC_nextSemirareLocation" ];
updatevars();
 
Last edited:
Your issue is actually that this should be a mafia property, not a ZLib setting. Users never need to configure this. ZLib settings exist to be set by users and read by scripts. They're intentionally difficult to edit in ASH. For persistent information that scripts need to pass to themselves, use mafia properties.
 
Funny... I started with it as a mafia property, and moved it to being a zlib property to try to make it more silent. Figured that on a script value that only needs to be set for one adventure, it didn't need to be getting two lines of log every time.

It's not supposed to be persistent, it's just there to be read by the other script before it gets cut.
 
Haha -- but think about it. ZLib settings are meant to be tweaked by users. For this reason, they are easily exposed and edited via the CLI or numerous relay editors. Also unlike mafia properties, they are loaded into memory for each instance of ZLib! These two together mean that if it is something that the user is not meant to adjust, don't make it a ZLib setting; make it a mafia property.
 
You must log in or register to reply here.
Back
Top