ZLib -- Zarqon's useful function library

Can the best_fam() function get a beecore check please. I think the easiest way would be to add a be_good() check. This means be_good() function should probably have a string parameter. I propose the following changes to the be_good() function and to line 514 of the best_fam() function:

Code: 
boolean be_good( string it ) {   
       return my_path() != "Bees Hate You" || it.to_lower_case().index_of("b") == -1;
}

Code: 
if (be_good(i) && (familiar_weight(i) > bestweight || (familiar_weight(i) == bestweight && famstrength(fams[i],ftype) > beststrength))) {

Changing the be_good parameter to a string allows you to pass other datatypes to it and mafia will do the conversion so this won't break any scripts currently using be_good(item).
All of the following work fine with this change:

Code: 
be_good("depantsing bomb");
be_good("Barrrnacle");
be_good($item[depantsing bomb]);
be_good($familiar[Barrrnacle]);

Thanks.
 
I'm down. Will include this with the upcoming update, which will also change has_goal() to be speculative.
 
Is there any way to get best_fam() to consider the hatrack? I'm down with "no," I'm just looking to see if future support would ever be considered.
 
The present algorithm is not formulaic, it's more of a simple "which familiar of a given type have you already been favoring?" However, reworking the algorithm to load batfactors for combat familiars and use speculation for item/meat familiars is possible, but that would be a pretty big thing to add. I wouldn't get my hopes up if I were you.
 
On the topic of best_fam(); would it be possible to get it to account for ML when picking the best stat-familiar? If I'm reading the code correctly it values a blood-faced volleyball and a hovering sombrero as equally good stat familiars and thus a 20 pound volleyball wins over a 19 pound sombrero even though the ML of the current location may very well be high enough that the sombrero might be better already at 10 pounds.
 
Maybe an overloaded version that takes a $location argument as well? Or just an int? Seems clunky since that wouldn't do anything for ftypes that aren't "stats"...
 
Could just consider current location... I know that some scripts set that to they can add the 'outfit' goal.
 
Used Weatherboy's Spaaace Script for the first time yesterday (I know, this is the Zlib thread, I do have a reason for posting this here instead of there though) and for some reason it chose to equip my Stocking Mimic instead of a fairy type that would have increased the odds of a map dropping.

I asked in his thread if he knew why this would happen and he replied thusly . . .

Weatherboy said:
Familiar selection is handled by the zlib best_fam("items") function. I would ask about that over there.
Click to expand...

So here I am asking.
 
The only reason that best_fam() will ever equip a stocking mimic is if you have it set as is_100_run. Since the stocking mimic isn't even in the map there's no other condition that it would equip it. (Unless I'm missing something obscure.) Taking a look at Weatherboy's script he seems to be blameless as well. I'd suggest you check to see if you have set is_100_run for a 100% stocking mimic run. (If you don't know how, just type in the cli: zlib vars)
 
Bale said:
The only reason that best_fam() will ever equip a stocking mimic is if you have it set as is_100_run. Since the stocking mimic isn't even in the map there's no other condition that it would equip it. (Unless I'm missing something obscure.) Taking a look at Weatherboy's script he seems to be blameless as well. I'd suggest you check to see if you have set is_100_run for a 100% stocking mimic run. (If you don't know how, just type in the cli: zlib vars)
Click to expand...

Thanks. I guess I just assumed that setting would reset back to default on ascension. Think I've been running with it set as 100% mimic for a couple months now and the Spaace script was the first script I used that called that function in zlib.
 
Well, personally I love that it doesn't, so I can set my 100% run as the last thing I do pre-ascension. If it were to reset automatically, that would screw me up terribly. Easier to just reset it as part of a pre or post-ascension script.
 
Bale, that would be a handy thing to add to newLife if it's not too much trouble. You're already importing ZLib so you could do it the same way ZLib does it, or you could just add a single cli_execute("zlib is_100_run = none") command, which is less efficient but super easy to code. Unless someone screwed up a Kittycore run, chances are very high they're not going to do two 100% runs with the same familiar in a row.
 
zarqon said:
Bale, that would be a handy thing to add to newLife if it's not too much trouble. You're already importing ZLib so you could do it the same way ZLib does it, or you could just add a single cli_execute("zlib is_100_run = none") command, which is less efficient but super easy to code. Unless someone screwed up a Kittycore run, chances are very high they're not going to do two 100% runs with the same familiar in a row.
Click to expand...

How do I know that they didn't set is_100_run on purpose before ascending?


zarqon said:
Rather than just show an error message, print a substring-matched list of settings when called from the CLI with text that doesn't match a setting name.
Click to expand...

Yay for r30! Nice update! I've kinda wanted that for a while.
 
Yeah... I have a pre-ascension script that sets my current familiar to be the new 100% familiar. I noted it on the mafia FReq. An automatic wiping would just screw this up horrifically, since it's hard enough to remember to adventure automatically to have BBB pull out the familiar without remembering what familiar I'm trying to do. Short-term memory isn't what it used to be. :)
 
Since we all come through the gash without a familiar these days, the most recent version of newLife actually checks is_100_run and sets your familiar accordingly. That's a nice feature for users like you. :)
 
I know... I saw that and am excited to need to have it be a bit less accurate. :) Would have screwed up 3 or 4 less 100% runs if my memory were just a tiny bit better. Ah well. That's why we have scripts in those positions. Thanks for that addition, btw. :)
 
Any chance Bale's 'time' function can get rolled into zlib? I don't think anything's currently using it, but it's definitely shiny.
Bale said:
PHP: 
string time(int t) {
	int h = t / 3600000;
	int m = (t / 60000) % 60;
	float s = ((t / 100) % 600) / 10.0;
	return (h>0? h+" hour"+(h==1? "": "s")+", ": "") + (m>0 || h> 0? m+" minute"+(m==1? "": "s")+", and ": "") + s+" seconds";
}
Click to expand...
It does "1 seconds" instead of "1 second" but that's the only one, and easily fixed by doing the same "s==1?" thing to it that hours and minutes had.
 
You must log in or register to reply here.
Back
Top