ZLib -- Zarqon's useful function library

Aww... but then it's spammy, and with directly setting using vars[string] = setting; updatevars; and remove vars[string]; updatevars; it even cleans up after itself... :(
 
Yes, it works. I just dislike it from a design standpoint. It's not a script setting, so why is it a script setting?

And, I don't consider being able to see when a script changes my mafia preferences spammy; I rather like it, actually.
 
I like preference changing displayed normally. The issue is, I don't actually want to set a preference though... I just want BBB to stop trying to hijack my semirare adventure and eat another fortune cookie. Or however many I have fullness for, If I'm set to cut counters down to 1. :D The best way I've found to do that (currently) is to set a value SOMEwhere and if it matches, tell BBB to stop hijacking.

I suppose if I was going to do it with preferences, the 'proper' way to do things would be to completely disable BBB scripts for that adventure... read BBS value to a string and set it to "", adventure, and set it back to prior value. But that's even worse in terms of what happens if the adventure is aborted part-way through. As well, that disables the other parts of BBB, not just the fortune cookie part.
 
Couldn't you just do a
Code:
cli_execute("zlib <setting name> = /"/"")
if you wanted to clear the variable? (not sure about the escape character needed for quotes)
 
Could. But then again, I can just wipe it in ash, using the tip from slyz. I was just wondering if there was anything built in for this. Apparently the answer is no, because it's not designed for this. ;) Doesn't mean it's not a good usage necessarily, does mean it's unlikely to get more official support.
 
Hello ppl,

I get an error on the zlib script, it says "desert bus pass" zlib.ash, line 394... Can any one help? I'm not a very high level (7), does that matter?

Thx,
Michael
 
ok, winterbay... I will do that. Thx

EDIT: I'm a real n00b at this... Ok, I did the Latest EXE Build and placed it in its own folder but it still isn't working, I did the "update clear" too. I looked over this thread and it seems that other people has had this trouble to. Thx

EDIT 2: Ok, I got it... Thx :-)

EDIT 3: the zlib says "Please input a value for string setval", what does this mean?
 
Last edited:
Well, if you try to run zlib itself it will do that. Zlib is made to be included in other scripts and to be called from within them so that is the normal behaviour if you try to call it outside of a script and don't give it soemthign to work with.
You could try entering "vars" into the field and it should give you all your zlib variables that are stored in yoru mafia installation.
 
I got the desert pass problem, deleted the + desert pass and the + angelcake ?? part and left only the meatcar....got past that problem

Now I am in a loop trying to kill the filthworm hatchling but queen is dead.....

IS there an easy way to get this script to finish this war, without getting stuck. A previous version of this script blew up and record of turns is gone. So, starting again from scratch. I suck at this game, been trying to ascend for 2 crimbos....If it wasn't for the chance to program it, I'd be toast... Anyone have any pointers....
 
Could try to run fastest.txt instead of optimal.txt? Are you wanting it to just finish, or finish with a Wossname?

Also, wrong thread for Wossname questions... this is the zlib thread, for the support functions. :)
 
rnum() seems to insert commas only for numbers with more than four digits before the decimal point, so you get:
Code:
> ash import <zlib.ash>; rnum(5000)

Returned: 5000

> ash import <zlib.ash>; rnum(55000)

Returned: 55,000

> ash import <zlib.ash>; rnum(5000.01)

Returned: 5000.01

> ash import <zlib.ash>; rnum(55000.01)

Returned: 55,000.01
That 4 is right there in the conditional on line 80. Is this intentional? I changed it to 3 and nothing seems to have broken so far, but I haven’t done any extensive testing.

At any rate, thanks for an exceedingly useful library!
 
Won't be able to test this until tonight, but this should enable has_goal to detect on unspaded drops, now that they're back to a 0% drop rate:
PHP:
         case "n": res += temp*minmax(rec.rate*(item_drop_modifier()+100)/100.0,0,100)/100.0; continue;
         case "0": res += .001; continue;

These two replace the current case "n" line. Basically, we're continuing the search for drops (not continuing on to "0" directly), then saying that if it's unspaded, make it a tenth of a percent, less than even a 1% spaded drop. It means we'll go for any spaded drop first, but unspaded should still work.

Well, did get to test it.
> conditions add antique packet; 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);

Condition added: antique packet of ketchup
antique packet of ketchup
Haunted Kitchen
 
Last edited:
if it's unspaded, make it a tenth of a percent, less than even a 1% spaded drop. It means we'll go for any spaded drop first, but unspaded should still work.

That doesn't make sense to me. Very few items are at such a low rate. Odds are that any unspaded drops are at least 5%, so shouldn't we make use of a sane low number like 10?

Do you have some reason to wish not to get items just because their drop rate is still unspaded? Frequently those are the most interesting items at the moment.
 
Basically, if there's an actual drop rate, use it. It only affects cases where there's multiple locations with the same item (not multiple enemies), and it's trying to decide which of them is best.

Edit: To clarify - Setting the unspaded value that low doesn't make has_goal skip the location as a possible place. It just depreciates it if there is another spaded area with better known drops. Setting the value to 5% doesn't make sense when it's possible that it's an ultrarare 1% drop or something similar. If we know that another area is 5%, use that area first.

Unspaded means that you might get the item, but it might be pickpocket only, or it might be conditional, or... we have no clue if it's even possible for you, specifically, to get. Maybe you need to finish part of another quest... maybe you need to be a different class... who knows?!

If we have a different location where we know you'll have success... go there! You'll get it eventually. The unspaded bits? Meh. That's why they're unspaded...
 
Last edited:
@Aankhen: Yes, it's 4 by design. Somehow I felt commas for 4-digit numbers to be unnecessary. I tried to back up this instinct with some Google searches but only found evidence to the contrary. Oh well. :)

@Theraze: I like this better than the previous method. Changed locally, will be in the next update.
 
Updates! Whee!

Edit: Might I suggest changing this has_goal section slightly:
Code:
         case "n": res += temp*minmax(rec.rate*(item_drop_modifier()+100)/100.0,0,100)/100.0;
to this:
Code:
         case "n": res += temp*minmax(rec.rate*(item_drop_modifier()+100)/100.0,0,100)/100.0; continue;
         case "0": res += .001; continue;

Basically, unspaded drops get a .1% drop rate for has_goal. :)
 
Last edited:
Back
Top