Winterbay
Active member
Have you tried doing an "update clear" in the CLI? It seems many problems have been caused by manual overrides not working as intended.
ZLib -- Zarqon's useful function library
- Thread starter zarqon
- Start date
Have you tried doing an "update clear" in the CLI? It seems many problems have been caused by manual overrides not working as intended.
Theraze
Active member
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.
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.
Theraze
Active member
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.
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).
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).
StDoodle
Minion
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.
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.
zarqon
Well-known member
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?
I can't guarantee that I will remember to edit that page when I change something in ZLib, however.
@Fluxx: KoB? Kingdom of Buffing?
Bale
Minion
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:
Theraze
Active member
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:
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?
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?
StDoodle
Minion
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:
I'm 99% sure of the last line, but it isn't documented... harumph.
Code:
vars["BaleCC_nextSemirareLocation"]=$location[none];
updatevars();
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:
EDIT: I should reload the thread before answering questions ^^
PHP:
vars["BaleCC_nextSemirareLocation"] = "";
updatevars();EDIT: I should reload the thread before answering questions ^^
Last edited:
Theraze
Active member
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.
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:
There's no practical difference here.
EDIT:
PHP:
vars["BaleCC_nextSemirareLocation"].to_location();There's no practical difference here.
EDIT:
Again, you can do that directly:
PHP:
remove vars[ "BaleCC_nextSemirareLocation" ];
updatevars();
Last edited:
In case anyone goes hunting for this, it was posted on a different forum.
zarqon
Well-known member
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.
Theraze
Active member
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.
It's not supposed to be persistent, it's just there to be read by the other script before it gets cut.
zarqon
Well-known member
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.