ZLib -- Zarqon's useful function library

The auto_mcd still needs to be modified due to this...

Current code:
Code: 
boolean auto_mcd(int safemox) {
   if (!to_boolean(vars["automcd"]) || (my_ascensions() < 1) || in_bad_moon()) return true;
   if ((in_muscle_sign() && !retrieve_item(1,$item[detuned radio])) ||
     (in_moxie_sign() && item_amount($item[bitchin meatcar]) + item_amount($item[desert bus pass]) +
      item_amount($item[pumpkin carriage]) == 0))
      return vprint("MCD: unavailable","olive",5);
should be more like this:
Code: 
boolean auto_mcd(int safemox) {
   if (!to_boolean(vars["automcd"]) || (my_ascensions() < 1) || in_bad_moon()) return true;
   if ((knoll_available() && !retrieve_item(1,$item[detuned radio])) ||
     (gnomads_available() && item_amount($item[bitchin meatcar]) + item_amount($item[desert bus pass]) +
      item_amount($item[pumpkin carriage]) == 0))
      return vprint("MCD: unavailable","olive",5);
 
Ok. Any other things that should be fixed? I'll give this a day -- I don't want to post a bunch of back-to-back updates.
 
Small comment & compliment:

New Version of newLife Available: 1.64
Upgrade from 1.7 to 1.64 here!
Think you are getting this message in error? Force a re-check by typing "set _version_Bale_newLife =" in the CLI.
Click to expand...

First of all, thank you for adding "set _version_Bale_newLife =" to the error message. I have had to look up that property SO many times that it is really sweet to see it right there. Of course I should need that a lot less now that you check version numbers.

Also, it's really great to get a sweet clickable link.

Finally, it is a little weird to see that 1.7 is not better than 1.64. :D I'll just change the new version number to 1.70 and all is good. It'd be a little annoying to fix that in zlib. (Check number of digits and pad with zeros I suppose.) It's mostly just quirky.
 
Well, 7 is inferior to 64...

EDIT:
Zarqon, I noticed you didn't add the fix posted in post 697. Are people still getting the "The string "r25" is not an integer; returning 25 ()" output?
 
Last edited:
zarqon said:
Warning messages for non-ints are fine in my book since they could very well annoy people into taking advantage of the new functionality, which would overall decrease user annoyance.

ZLib: Annoying Users Into Compliance Since 2009.
Click to expand...

@Bale, what you should have done is change the old nonstandard version number to 1.6.4.

Also, to clarify: that was a joke. :)
 
Last edited:
zarqon said:
Warning messages for non-ints are fine in my book since they could very well annoy people into taking advantage of the new functionality, which would overall decrease user annoyance.

ZLib: Annoying Users Into Compliance Since 2009.
Click to expand...

The really amusing thing is that the author of this very script has not yet been annoyed into compliance! Perhaps zarqon does not want to decrease user annoyance.
 
I know right? Hopefully soon the author of ZLib will get tired of seeing that warning message and fix his version number.
 
Eh, least now it only shows if the version isn't the same... While it complained every time on every character, I was going to 'note' it again, but then when it was made to first check if the versions matched? It only whines if the versions are different, and in that case I'm going to be replacing them anyways, so it's not really an issue anymore. :)
 
So, doing some prodding around, it appears to me that in the data for kmails from API.php the variable "azunixtime" does indeed return unix time, but I'm not sure what the "az" is there for. At first I assumed (as is natural) that it had to do with AZ, but the time given there is indeed seconds since Jan 1, 1970 GMT, not Jan 1, 1970 MST.

Just thought I'd point that out, since it's in your comments as a unix timestamp of Arizona Time.
Unless, as I've considered, the time would be converted to GMT first, but then it wouldn't make any sense to call it "azunixtime" over any other unix time, as they'd all be the same. So either KoL is wrong, or the "az" is just superfluous. It is my mission to find out which.
 
Asymmetric is in AZ, and some of AZ doesn't use Daylight Savings Time, while some of it does. Maybe they're just proud of their unique time zone, those rogues. Maybe they are in that special zone of AZ which doesn't use DST, yet is in the middle of the part of AZ which does use DST. Seriously, in AZ you could drive down a straight highway and go forward and back in time like 6 times.

Korea doesn't use DST either, they use Real Time. I must say I prefer it.
 
I do believe that the game is in a part of AZ that doesn't observe DST (whenever I change the time over here rollover moves around). I would rather we just skipped the whole bloody thing as well, but unfortunately it was one of the few things that the EU politicians coudl agree on in the beginning and so we are stuck with a solution that makes no sense in the northern parts due to being adapted to the lighting situation in Spain...
 
But .. unix timestamp is GMT (and also never DST) by definition?

Maybe it just means "unix timestamp of our AZ server(s)"?
 
best_fam quick question

Hi, could someone please tell me whether best_fam("") can be used to return the heaviest familiar in my terrarium.
 
It was made to only return your heaviest familiar with a given ability. I'm actually not clear what will happen if you pass a blank string. Try it. If it doesn't work, just use this:

PHP: 
int temp;
familiar bestfam;
foreach f in $familiars[] if (have_familiar(f) && familiar_weight(f) > temp) {
   temp = familiar_weight(f);
   bestfam = f;
}
// bestfam now contains your heaviest familiar
 
aah, thanks guys, in that case Zargon's scriptlet seems the way forward. For the curious, this is part of my login script which gets me ready to PVP.
 
You must log in or register to reply here.
Back
Top