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

slyz said:
You might not want clover protection if you're in the middle of a powerlevelling session to level 15 for example. I could see a point in adding a check to CC.
Click to expand...

Sigh. I can see your point. Thanks for all the case statements. I'll slip those into the already existing switch.



Released CounterChecker v1.497​


This is the "Save me from Uberpants" release.
 
Duh, clovers! I completely forgot that Uberpants is a clover adventure, so it didn't occur to me to check. Yup, I had protection turned off. AND, I'm in the middle of the Level 30 shuffle, so did a bunch of Gallery levelling. But, I went on to other areas and forgot about the protection.

So, I guess this would be an enhancement request for CC:

BaleCC_SR_cloverprotect: True/False. If True, closet all assembled clovers (if any) for the SR adventure and uncloset afterwards.

I'll leave code logic to others, with a tip-o-da-hat to Slyz for the SR/clover list.

[Hmmm, apparently ninja'd by a whole bunch. Big thanks to Bale for quick-response.]
 
Last edited:
tragus said:
BaleCC_SR_cloverprotect: True/False. If True, closet all assembled clovers (if any) for the SR adventure and uncloset afterwards.
Click to expand...

I cannot think of any advantage to making this configurable, so it will always closet clovers. :) You're gonna have to get your uberpants on purpose now and just accept that when CC triggers you're gonna get a lunchbox instead.
 
Bale said:
I cannot think of any advantage to making this configurable, so it will always closet clovers. :) You're gonna have to get your uberpants on purpose now and just accept that when CC triggers you're gonna get a lunchbox instead.
Click to expand...

At the moment, I agree. Although I could argue both sides, I could imagine a situation of an automated series of clover-related power levelling (e.g., Gallery) during which one might still want to get a semi-rare then return to continue to the clovering adventures. As a matter of style, I generally lean toward configurable parameters though I understand that the added complexity may not be worth the incremental advantage(s).

Bottom line, forced closeting seems a reasonable solution here.

Thanks again, Bale, for all your fine work. Now, I've just got to figure what to do with 11 Uberpants....
 
tragus said:
I could imagine a situation of an automated series of clover-related power levelling (e.g., Gallery) during which one might still want to get a semi-rare then return to continue to the clovering adventures.
Click to expand...

Not an issue. I automatically UN-closet your clovers after getting the semi-rare. :D
 
Bale said:
Didn't you also have to patch BBB to work with that?

I'm not going to make an official change to CC for BBB until zarqon makes an official change to BBB. This was his idea after all. Though I'd be glad to make any change that fits his idea of how it should be fixed.
Click to expand...

Since the official version of the BBB 2.3 script now contains the BaleCC_nextSemirareLocation value, any chance of adding this to the CC script? :)
 
Currently, I'm pasting it in here:
Code: 
 else locale = expensive_semi(last_rare);
 familiar start_fam = my_familiar();
becomes
Code: 
 else locale = expensive_semi(last_rare);
 vars["BaleCC_nextSemirareLocation"] = locale;
 updatevars();
 familiar start_fam = my_familiar();
and
Code: 
  cli_execute("outfit checkpoint");
 }
 eat_cookie();
becomes
Code: 
  cli_execute("outfit checkpoint");
 }
 remove vars["BaleCC_nextSemirareLocation"];
 updatevars();
 eat_cookie();

The top one sets the next semirare location to be whatever locale is, as soon as locale has been set. The bottom one removes it as a locale after the adventure, but before CC eats its cookie, in case it all goes horribly wrong for some reason. BBB checks if my_location() is set to BaleCC_nextSemiRareLocation and if so, doesn't try to eat cookies, even if it's set to always eat if there's no counter (which there isn't the turn CC runs its semirare, because the counter has expired). As the value is only set for the turn that the semirare happens, the only time it would cause problems is if you cancel during the actual semirare adventure, and it would only stop BBB from its cookie eating while you're adventuring in that zone. Otherwise, it shouldn't ever be noticed except in the absense of problems for people running always1 cookie counters. :)
 
I see. That's a pretty weird fix. I never really paid too much attention to your patch since I figured that zarqon would suggest something else when he got around to it. As I understand this, if the character is adventuring in the same location that the semi-rare takes place, then this will fail to eat a cookie. Is that correct?
 
Nope. The issue is that if BBB is set to Timely (default) and CC tells it to go to a place that BBB says is good, BBB won't eat a cookie, because it figures you'll keep adventuring there for another 160 turns and you'll get your semirare there, no problem. If CC tells it to go to a place not in the BBB list of good semirares (anyplace not Purple Light District, Haunted Billiards Room, Menagerie 2, Outskirts of the Knob, Limerick Dungeon, Sleazy Back Alley, Haunted Pantry, or the Harem) then BBB will fire and eat a cookie before the semirare adventure happens. The issue with the timely setting is that if you spend 160+ adventures in those 'good' places and somewhere that the BBB doesn't fire, like the hidden temple or familiar trainer, you can miss out on a semirare.

This only affects BBB's fortune cookie eating. Even if the removal happened after CC's eat_cookie, it wouldn't stop CC from eating. CC only eats after the adventure. That's a great time to eat a cookie.

The nextSemirareLocation isn't a fix to CC... it's a warning to BBB to stop it. A different workaround for BBB would be to detect how many fortune cookie counters are stored, and once it passes 3, stop trying to eat cookies. But at that point, you've completely wasted 2 appetite.

Though that does also make me see a slight bug in the CC cookie eating code. This line:
Code: 
   if(my_fullness() == fullness_limit())
should probably be changed to
Code: 
   if(my_fullness() >= fullness_limit())
because it's possible to overeat... pride and gluttony during badmoon both affect your max, and recalling your skills after badmoon makes both go away. Not sure if eating quantum tacos can go above max as well, but every time I purchased gluttony, I know I was above the max that day because gluttony always gets purchased before pride for the extra fullness point.
 
Bale said:
I wasn't aware of that. Remind me, how was I supposed to enable that fix to BBB's cookie eater?
Click to expand...

I wasn't aware of that either. :) It's been a while since that discussion.

When I realized our scripts could play nicely together for optimal fortune cookie eating, I didn't really realize fully the implications of the fact that my script runs right in the middle of yours. Basically, BBB needs CC to set any kind of externally-readable flag prior to "calling" BBB via adventuring to get the semirare. Then BBB will be able to see that this flag is set and avoid stupidly eating a cookie right on the semirare adventure (which if I'm not mistaken results in entirely random numbers). It may even be handy to set it afterwards to the location you plan to get the next semirare -- which would allow BBB to be smarter still about its cookie eating -- it would only eschew eating cookies in your semirare window in the specified location. And, if you were in the specified location, it could avoid eating even with no counters. Even more optimal!

I regret making this a setting -- it should be a property, given that users will not edit it. Unless you want users to be able to edit it as a way of informing CC where to go next, superseding its own internal logic (which I could see as a handy feature, actually), in which case it should be a setting.

I'd suggest that CC either 1) change this to a property, and set it afterwards to the location it predicts it will go to next, or b) keep it a setting and clear it after getting the semirare, but allow that setting (if set by a user) to inform CC about where to go next. Let me know which you decide to implement and I can make BBB wise up to this as well.
 
zarqon, any blame for how it's done is mine, not yours. I made it a zlib setting though because I could do that silently, while making it a mafia property would have involved two additional session log events... one where it adds it, one where it removes it.

While "timely" would work well with leaving the value in, "always" doesn't, as in that case you don't want BBB to eat a cookie during CC's semirare run, but you do want BBB to eat the round following if you're still adventuring there, meaning that the value would either have to be changed or removed between the two adventures. As it needs to be changed regardless, it might as well clean itself up and be neat.
 
In that case, my option b) is still valid, but option 1) is out. Let's replace option 1) with this: clear the property after adventuring for the semirare.
 
I think Bale had actually talked earlier about setting up some sort of a list of semirares that people wanted to acquire, before it got bogged down in a mass of how best to achieve it. But I think it was going to be done in a more complex manner than just tagging a single setting with "go here next".

I like the silent usage of variables, but don't want it to bog down the system, which is why I had it remove it when done. This is one of the few reasons/excuses I can come up with for silently setting and removing properties... :(
 
zarqon said:
I regret making this a setting -- it should be a property, given that users will not edit it. Unless you want users to be able to edit it as a way of informing CC where to go next, superseding its own internal logic (which I could see as a handy feature, actually), in which case it should be a setting.

I'd suggest that CC either 1) change this to a property, and set it afterwards to the location it predicts it will go to next, or b) keep it a setting and clear it after getting the semirare, but allow that setting (if set by a user) to inform CC about where to go next. Let me know which you decide to implement and I can make BBB wise up to this as well.
Click to expand...

I've recently been thinking about this principle of property vs zlib variable. (There's some small implication for OCD that I intend to change on its next upgrade.) I like your thinking!

zarqon said:
In that case, my option b) is still valid, but option 1) is out. Let's replace option 1) with this: clear the property after adventuring for the semirare.
Click to expand...

I'm going to go with 1. Note that my script will clear this setting if it is on full automatic, but if there is a user determined semi-rare coming up, then it will set the property to the location of the next semi-rare so that BBB knows what CC wants to get. (I'm going to allow the user to make a list of items it wants to get with the semi-rare. A "wish list" which it will then attempt to fulfill.)

PS. I really hate the word "semi-rare" since it so poorly describes the mechanic, but if I made up my own word, nobody would know what I'm talking about.

mredge73 said:
Feature Request:
Can CC check if hobonickles >= 5 before trying to adventure in a hobo zone for a semi-rare?
Click to expand...

Yes it can, quite easily. And it will as of my next update. I'll just roll that into my check for canadv(). Thanks for pointing that out.
 
Bale said:
Yes it can, quite easily. And it will as of my next update. I'll just roll that into my check for canadv(). Thanks for pointing that out.
Click to expand...

Didn't it used to check for hobonickels back before it had its own canadv check? Thought it was in there, but maybe not.
Also, does > 4 make any sort of appreciable difference? I had someone go on about code efficiency at some point and that > 4 was only one operation, while >= 5 was 2 due to needing to check if == 5 and > 5 as well. I don't think we generally care too much about efficiency to that level, but I thought it was worth asking about.

If we're marking areas as unlocked, we'd still want to mark them as open using the unlockedLocations property, just not available for semirare collection. So with the current code, it would just be something like this right after the pandamonium slums check, right? Part of the semirare collection code, not canadv...
Code: 
if (available_amount($item[hobo nickels]) < 5) {
remove semi_rare[$location[the purple light district]]
remove semi_rare[$location[burnbarrel blvd]]
remove semi_rare[$location[exposure esplanade]]
remove semi_rare[$location[the heap]]
remove semi_rare[$location[the ancient hobo burial ground]]
}
 
Bale said:
Note that my script will clear this setting if it is on full automatic, but if there is a user determined semi-rare coming up, then it will set the property to the location of the next semi-rare so that BBB knows what CC wants to get. (I'm going to allow the user to make a list of items it wants to get with the semi-rare. A "wish list" which it will then attempt to fulfill.)
Click to expand...

If CC can access this user-created list, then so can BBB. Unless there will be lots of logic involved in parsing this list somehow, "next SR" doesn't need to be additionally stored elsewhere.

I'm assuming CC's SR queue will be a data file. BBB can simply read that data file and if you're adventuring in the 1st-slot zone, don't eat a cookie, regardless of timely/always/whatever. If the data file doesn't exist or is empty, or if for whatever reason (deleting CC or somesuch) the topmost slot matches lastSemirare, BBB's default behavior will take place.

I like this a good deal. It's easier to script too, since you can read the data file, adventure for the SR, calculate the next SR, and rewrite the data file (all which you would have done anyway). When BBB fires your goal SR will still be at the top of the data file. After that, the next SR will be at the top.
 
zarqon, it seems that you understand my mind. The file would be like this:

PHP: 
record queue_entry {
	location loc;	// Where to find the semi-rare
	int q;			// Quantity desired.
	string extra;	// Some locations need extra info. Billiard room values are "item" and "stats"
};
queue_entry [int] SrQueue;
if(!file_to_map("SrQueue_"+my_name()+".txt", SrQueue)) {}

Urgh. I hope that I don't want to change the name of the file now that I gave you a reason to put it in your script...


Theraze said:
If we're marking areas as unlocked, we'd still want to mark them as open using the unlockedLocations property, just not available for semirare collection.
Click to expand...

unlockedLocations is only set on a url check. That's irrelevant.
 
Last edited:
Excellent. I'm assuming that CC will handle sorting this file, and BBB can simply load it and check srqueue[1].loc.
 
You must log in or register to reply here.
Back
Top