CounterChecker: Wormwood, Semi-rares, Dance Cards and more

I did set counterscript, so it's functional. I don't want my Semi-rares automated, I just want somewhere to check the counter so I can decide where to do my Semi-Rares myself. Not sure how to do that.

ETA: I've just downloaded KOlmafia today, so there might be something really obvious that I'm missing.
 
Last edited:
If you're using the Relay Browser, it'll show up in the charpane. If you want to check it in the CLI for whatever reason, just enter "counters" (no quotes, of course).
 
Thanks. I've no idea what the charpane is, or where it is (character panel, or something maybe?).. ehm, so, yes, that's how bad I am with this stuff. But the counters command works!
 
Yepa said:
Thanks. I've no idea what the charpane is, or where it is (character panel, or something maybe?).. ehm, so, yes, that's how bad I am with this stuff. But the counters command works!
Click to expand...

Charpane = the thing with your stats and so on to the left of your KoL screen.
 
Last edited:
Hmm.. It's not showing up there for me... Feel like a right idiot, but there you go. Maybe it'll show up tomorrow (since I just installed it today). Thanks though!
 
Mafia already tracks your semirares, you don't need to install this script if you don't want to automate them. Of course, Mafia doesn't automagically knows your semi-rare number: it only saves the numbers you get when you eat a fortune cookie.

It also remembers when your last semi-rare was, if you got it when using Mafia, so it knows the window of your next semi-rare and can automatically discard numbers that are out of range.

The counters appear with your buffs in the Relay Browser's charpane, or when you type counters in the gCLI.

If you were already tracking a semi-rare, you can add a custom counter by typing counters add <number of turns left> in the gCLI.

If you are new to Mafia, I suggest you read SingingSally's guide.
 
Char pane is in the relay browser.

Perhaps you should view the kolMafia wiki? Its the 4th tab on this forum...
Check out SinginSally's guide in the New User section...

Ninja'd brillantly by slyz!

And SinginSally's Basics (Relay Browser) page fills in all the semi-rare counter details if you have any more questions.
 
Last edited:
Bale, writing an update to BBB and wanted to implement the cookie-eating thing we talked about before. So let's talk script synergy.

Here's what I have for starters:

PHP: 
boolean cookiecheck() {
   if (!to_boolean(vars["auto_semirare"]) || my_fullness() == fullness_limit()) return true;
   if (get_counters("Fortune Cookie",0,200) != "" || get_counters("Semirare window begin",1,200) != "")
     return vprint("BBB: No need to eat a cookie given the present counters.","#F87217",8);
   if (my_location() != to_location(get_property("semirareLocation")) && $locations[Purple Light District, Haunted Billiards Room,
       Menagerie 2, Outskirts of The Knob, Limerick Dungeon, Sleazy Back Alley, Haunted Pantry, Harem] contains my_location())
     return vprint("BBB: "+my_location()+" contains an acceptable semirare; not auto-eating cookie.  Eat one manually if you want your counterScript to handle it.","#F87217",5);
   return eatsilent(1,$item[fortune cookie]);
}

I'll probably expand the "acceptable semirare" detection to actually consider values later.

This is quite independent. The only issue now is that CC should refrain from eating cookies if BBB is set to do it. I think it would be nice if these two scripts could play nicely together, using a minimum of ZLib settings. CC doesn't really need to pass any information to BBB, but CC somehow needs to know whether BBB's smarter cookie eating is in effect.

I like the idea of sharing a vars[auto_semirare] setting. If false, neither CC nor BBB would eat cookies. If true, CC would only eat a cookie if !contains_text(get_property("betweenBattleScript"),"BestBetweenBattle").
 
It is a worthwhile idea. The first problem I see is if the user renames BestBetweenBattle or he edits a personal version with a different name (I do this). That'd queer the deal.

Perhaps it should be just as simple as not eating a cookie if you have counters. That way, if my script eats a cookie, yours won't. Am I missing a reason that would not work?
 
That is already the case. The problem is how to get your script to avoid eating cookies if mine will later, since delaying is more optimal (as described by suinoc previously).
 
Ah. Now I understand.

Because I want it to work even if BBB is not the name of the script, we need a different vector. Perhaps if BBB notices get_counters("Fortune Cookie",0,1) != "" || get_counters("Semirare window begin",0,1) != "", it can set var["LetMeEatIt"] = true and then CC won't do the eating.
 
Bale said:
Perhaps it should be just as simple as not eating a cookie if you have counters.
Click to expand...
My question is eating a fortune cookie when there are more than one counter or no counter and not eating another fortune cookie if there is only one counter.
What property do I need to use to detect the number of fortune cookie counters running? I would use this in an if statement - if not only 1 active counter, eat a cookie.
 
Last edited:
get_counters("Fortune Cookie",0,200) will produce a tab delimited list. So, count the number of tabs? Hmmm... I guess something like this:

PHP: 
if(get_counters("Fortune Cookie",0,200) == "" || count(split_string( get_counters("Fortune Cookie",0,200), "\t")) != 1) 
   eatsilent(1, $item[fortune cookie]);

That's actually the first time I've ever thought split_string() was the easiest and best way to do something!

Incidentally, count(split_string( get_counters("Fortune Cookie",0,200), "\t")) is 1 if there are no current counters. That's why I needed the first check.
 
Last edited:
So our scripts will occupy 2 mafia properties and 3 ZLib settings, just to eat cookies? Seems a bit overkill. I'm trying to think of how to minimize the overhead.

Overloading variables is my favorite way to do this. Since ZLib settings are all strings anyway, let's pack the auto_semirare setting.

Possible values:
"true", "always" (means you always want a Fortune Cookie counter; CC would always eat cookies and BBB would if CC isn't installed)
"smart" (means you want to delay the smart way and you have appropriate handling in a betweenBattle script or mood; CC would never eat cookies and leave it to BBB/mood/etc)
"never", "off", "false" (neither script would eat cookies)

For any of the cookie-eating values, appending the word "single" would mean that CC or BBB would eat enough cookies to reduce you to only one active Fortune Cookie counter.

How's this sound?
 
That idea sounds quite good to me!

One gripe: "smart" auto_semirare sounds like we're being smart about getting the semi-rare which obviously we are. That value's meaning is a bit counter-intuitive, so how about: "smarteat" or "delayeating" or "delaycookie" or something like that?

Also, I'd recommend that we avoid assigning values of "true" or "false" by default since the current zlib editors will produce a checkbox instead of a text field, making that harder to change to "smart".
 
I included "true" and "false" (and "off" for that matter) as a sort of catchall -- our scripts should have handling for these values in case a user erroneously assumed the setting was a boolean. User documentation for adjusting the setting, however, would not include those as possible values -- just "always", "smart" (which we could change to "bide", "delay", or even "prevaricate" if it suits everyone better), and "never".

In practice, the scripts should probably treat all strings which are not recognized for eating cookies as "never", so the actual contents of the string don't really matter for that particular option.

Anyway, cool. I'll add this support to the upcoming BBB as soon as we decide what the optimal option should be called. Perhaps "optimal". I'm cool with whatever as long as it's one word. Perhaps "eventual" is better, consistent with the adverbial nature of the other options.
 
"timely"!!! I like that one best.

Also, thought of an improvement. Rather than appending "single" let's append a number to the cookie-eating options. That number will be the desired number of cookie counters. So "1" would keep eating cookies until only one counter exists, "2" would keep eating cookies until two or fewer counters remain (which would more likely mean that it would just not eat a second cookie if one of the three lucky numbers is discarded). Default (nothing specified) would be to eat only one cookie, and not care about how many counters result.
 
You must log in or register to reply here.
Back
Top