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

I was getting the follow error:
Code: 
Request 4 of 4 (Manor2: Haunted Ballroom) in progress...
(Dance Card     counter expired)
Bad item value: "fernswarthy letter"     (CounterChecker.ash, line 143)

I change fernswarthy letter to Fernswarthy's letter on line 143 and that fixed it.
 
That's interesting. I've got a question for you:

When you logged on, were you in the middle of a fight that you had to resolve so that mafia could continue?

That happened to me once and I then had problems with mafia's fuzzy matching. I'm wondering if you had a similar experience.
 
I don't recall that being the case. However, I just started using this script because I just started running the bumcheek ascension script. Not sure if that helps. The bad part is, I'm at level 12 doing a 0-side quest frat run, so I probably won't need anymore ballroom leveling this run.
 
So Bale, here's an idea for implementing custom semi-rares.. what if Mr. Adventurer set another counter that would expire at the same time as a Fortune Cookie counter with item name of the SR they want. ;-)

Code: 
Unexpired counters:
Fortune Cookie (15)

counters add 15 Inhaler

Unexpired counters:
Fortune Cookie (15)
Inhaler (15)

You can parse individual counters like that, right?
 
That's... tricky. There's several problems that come up when there are two counters expiring on the same turn and I'd need to account for all the cases. (Remember that it is possible for either one to invoke the counter script and it is possible to have a counter other than those two.) Plus I can only find counters I check for. I think I'd rather have a zlib variable containing your choice for the semi-rare.

Besides, few people actually know or can remember how to add counters. It is not a trivial action considering that the command has at least 3 parameters.
 
Drat! Well, it was idea.

I'm becoming more accustomed to zlib, and the relay script helps tremendously, but it's (zlib) not trivial either. ;)

Thanks for the reply.
 
I tweaked getChoiceAdv for debug as such-
Code: 
559 boolean getChoiceAdv(int count, location l, string goal) {
560     string last_adventure = "";
561     int n=0;
562     while(n < count && my_adventures() >0) {
563         n = n + 1;
564         last_adventure = visit_url(to_url(l));
565         if(contains_text(last_adventure, "choice.php")){
566             run_choice(last_adventure, goal);
567             cli_execute("mood execute");
568             print("GetChoiceAdv returning true due to contains text...");
569             return true;
570         } else {
571             print("Running combat, n is  " + n + " count is " + count);
572             run_combat();
573             print("Combat complete for n " + n );
574         } 
575         # here, either combat is over, or you hit a noncombat 
576         # now, lets restore HP and MP, as well as maintaining our mood
577         cli_execute("mood execute");
578         restore_hp(0);
579         restore_mp(0);
580         print("End of loop, n is " + n + " count is " + count);
581     }
582     print("Returning false from getChoiceAdv, n is " + n + " count is " + count + " and my_adventures is " + my_adventures());
583     return false;
584 }

When I run, I see the following occur (bolding for emphasis)-
Code: 
Checking counters now for Wormwood with 0
Goal: not-a-pipe.
To change this goal, use set wormwood = xxx, where xxx is a stat or item. (Optionally add 951, 51 or 1 for stats.)
Worm Wood first step...

[2668] Stately Pleasure Dome
Encounter: angry poet
Round 0: oh shazbot wins initiative!
Running combat, n is 1 count is 3
Round 1: oh shazbot uses the facsimile dictionary!
Round 2: oh shazbot uses the facsimile dictionary!
Round 3: oh shazbot uses the facsimile dictionary!
Round 4: oh shazbot uses the facsimile dictionary!
Round 5: oh shazbot uses the facsimile dictionary!
Round 6: oh shazbot uses the facsimile dictionary!
Round 7: oh shazbot uses the facsimile dictionary!
You lose 6 hit points
Round 8: oh shazbot uses the facsimile dictionary!
Round 9: oh shazbot uses the facsimile dictionary!
Round 10: oh shazbot uses the facsimile dictionary!
You gain 36 hit points
You gain 36 Muscularity Points
Round 11: oh shazbot uses the facsimile dictionary!
Round 12: oh shazbot uses the facsimile dictionary!
Round 13: oh shazbot executes a macro!
Round 13: oh shazbot attacks!
Round 14: oh shazbot wins the fight!
You gain 15 Fortitude
You gain 7 Magicalness
You gain 9 Cheek
Combat complete for n 1
Mood swing complete.
End of loop, n is 1 count is 3
(Wormwood counter expired)
Countdown: 1 second...
Waiting completed.
Checking counters now for Wormwood with -1
Time has expired for you to adventure at Wormwood for not-a-pipe.
[B]Running combat, n is 2 count is 3
Combat complete for n 2
Mood swing complete.
End of loop, n is 2 count is 3[/B]

[2669] Stately Pleasure Dome
Encounter: Kubla Khan
Round 0: oh shazbot wins initiative!
Running combat, n is 3 count is 3
Round 1: oh shazbot uses the facsimile dictionary!
Round 2: oh shazbot uses the facsimile dictionary!
Round 3: oh shazbot uses the facsimile dictionary!
Round 4: oh shazbot uses the facsimile dictionary!
You gain 35 hit points
You gain 35 Muscularity Points
You lose 8 hit points
Round 5: oh shazbot uses the facsimile dictionary!
Round 6: oh shazbot uses the facsimile dictionary!
Round 7: oh shazbot uses the facsimile dictionary!
Round 8: oh shazbot uses the facsimile dictionary!
Round 9: oh shazbot uses the facsimile dictionary!
Round 10: oh shazbot uses the facsimile dictionary!
Round 11: oh shazbot uses the facsimile dictionary!
Round 12: oh shazbot uses the facsimile dictionary!
Round 13: oh shazbot uses the facsimile dictionary!
Round 14: oh shazbot executes a macro!
Round 14: oh shazbot attacks!
Round 15: oh shazbot wins the fight!
You acquire an item: Polka Pop
You gain 9 Muscleboundness
You gain 10 Mysteriousness
You gain 12 Sarcasm
Combat complete for n 3
Mood swing complete.
End of loop, n is 3 count is 3
Returning false from getChoiceAdv, n is 3 count is 3 and my_adventures is 129
Wormwood counter expired.

It looks like for n 2 it's attempting to adventure and then immediately returning without doing anything.
 
Last edited:
That's very interesting and very puzzling. I really want to know what happened on line 564 when it did last_adventure = visit_url(to_url(l)); It appears that the adventure failed completely being something other than a fight or a choice, but that makes no sense to me. Are you doing anything that could produce non-combats (without any choices) like using dance cards?

I can't think of any way to find out other than the extremely unpleasant print(last_adventure), but you may need to do that.
 
Bale said:
That's very interesting and very puzzling. I really want to know what happened on line 564 when it did last_adventure = visit_url(to_url(l)); It appears that the adventure failed completely being something other than a fight or a choice, but that makes no sense to me. Are you doing anything that could produce non-combats (without any choices) like using dance cards?

I can't think of any way to find out other than the extremely unpleasant print(last_adventure), but you may need to do that.
Click to expand...

I should have nothing producing non-combats. And my adventure count is not being decremented in that MIA combat call. I'll ramp up the debug tomorrow.
 
You can simplify the output by putting the print() inside the else statement, just before the run_combat()
 
So this is weird. It only failed once today (yesterday it was quite constant, not sure why), and when it did fail, the HTML dump before the bad run_combat was for my clan basement. I've updated my debug to include what location l is set to, as well as what to_url returns (just to validate).

Update: Happening more consistently today, all locations and URLs are for the correct wormwood locations. I have no idea where the clan basement is coming from.
 
Last edited:
I've scanned this thread and apologize if I overlooked the issue being covered earlier.

Briefly, CC will automatically look for SR based on best mall price, which is great. However, it doesn't know/check what the last SR obtained was. Thus, for example, it will repeatedly go back to get a lunchbox but only managed uberpants (since a particular SR will not trigger in the same zone two times in a row). Unfortunately, I don't see an elegant automated way to fix this.

1) Keep last SR in external file/database with turn number. Problems: Can be out-of-date and inaccurate due to any adventuring outside Mafia framework. Also, yet-another-file to check, update, delete.

2) Add an SR-specific counter (e.g., lunchbox[300]) that can be checked. If next SR comes up and "best" choice is "lunchbox" BUT lunchbox counter is still active, choose next-best SR. Problem, yet another counter with related issues (as mentioned by Bale here and/or elsewhere). Also, it's not a generalized counter with a variable; actually, I can imagine a SR-type-counter[300], but have no idea how to implement it.

3) Available only within a Mafia session, set a global state variable with similar function to 2. Ugh. No, don't do this. Well, could be another zlib-style variable that is auto-stored in vars_<user>.txt, so maybe.

Anyway, for now, my workaround is to disable the auto-SR which is probably what I should be doing anyway. Sometimes (e.g., doing an auto-slime or auto-basement grind), though, I like to just set, go, and forget.
 
No clue what the problem is in your case, but CC does already have last semirare detection... note the following:
Code: 
 string last_rare = get_property("semirareLocation");
 
Hmmm, Theraze, I'm now confused as well. For now, ignore my post and I'll investigate/characterize more fully. Indeed that property is already present and apparently saved in <username>_pref.txt. Perhaps this may end in the land of "unreasonable great justice" for me (see completely unrelated posting thread) or it could just be massive pilot-error.
 
Last edited:
Yeah... it COULD be a conflict between a BetweenBattle script and a Counter script... BB scripts run before the counter adventure actually triggers, but after you've told it where to go. I was having issues with BBB trying to eat fortune cookies when it's trying to run the adventure that CC gave it, so there isn't actually a fortune cookie counter (and with my "always 1" setting, BBB sees that as a problem), so I had to add a new value to both BBB and CC that would avoid the issue. :)

But that would just affect you if have both a BB script trying to set your next semirare as well as the CC script. Or, it could also have to do with hacking the CC script to try to promote lunchboxes... but those are the two primary causes I'm coming up with.
 
tragus said:
Thus, for example, it will repeatedly go back to get a lunchbox but only managed uberpants (since a particular SR will not trigger in the same zone two times in a row).
Click to expand...
If you always get Uberpants instead of a lunchbox, you never got a semirare in the Spooky Forest, and you can still get one.

Also, maybe CC should disassemble your clovers for you before adventuring, and reassemble them once it is done.
 
If you get Uberpants, then you have ten-leaf clovers in your inventory. If you're going to turn off clover protection then... Well, that's just PBKAC. Turn on clover protection.
 
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.

If you want to make it efficient, I'll try to track down a list of semi-rare locations that have clover advs.

EDIT:
PHP: 
// This only contains locations that also have a semi-rare adventure.
boolean has_clover_adv( location loc )
{
	switch( loc )
	{
	case $location[Outskirts of The Knob]:
	case $location[Limerick Dungeon]:
	case $location[Sleazy Back Alley]:
	case $location[Haunted Pantry]:
	case $location[Harem]:
	case $location[Haunted Kitchen]:
	case $location[Haunted Library]:
	case $location[Guano Junction]:
	case $location[Laboratory]:
	case $location[Pre-Cyrpt Cemetary]:
	case $location[Post-Cyrpt Cemetary]:
	case $location[South of The Border]:
	case $location[Spooky Forest]:
	case $location[Hippy Camp]:
	case $location[Frat House]:
		return true;
	default: 
		return false;
	}
}
 
Last edited:
You must log in or register to reply here.
Back
Top