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

Basically, this means that if you have a price that's been checked in the past hour, use it. Otherwise, do the server hit to check the mall.

This saves time and server hits, and so is a GoodThing(tm).
 
Afaik, mall_price() is only cached during one mafia session, while historical_price()s are kept over and over, and can be even gotten from other players (if they have the sharing option enabled).

ETA: oh, and mall_price() won't check again if it already checked this session, so "if you have a price that's been checked in the past hour, .... Otherwise, do the server hit ..." is wrong. If you last checked the price two hours ago, and you are in the same session, mall_price() will still use that same cached price. Iirc, you would have to try to buy some of that item and have mafia realize that there are no longer any at that price to get another direct check.
 
Last edited:
True, unless you end up buying it, but... if you've checked in this session, it'll attempt to use historical data. Whether that historical data comes from historical_price or mall_price is irrelevant, except that historical_price runs faster for me when I'm running a delayed execution of EatDrink, but... If you've got recent data in the last hour, always skip the server hit. If our data is older, either hit the server or use our cached data, but either way we're going to check and add gCLI information about our check.
 
The script would do a dozen price checks, but since the historical price is usually less than a day old, I often won't have to do more than one or two server hits to check prices. Considering that every user's mafia updates prices to every other user's mafia I want to make use of that networking to use those updated prices.

mall_price() will only search the mall once per item per session, but I'm happy doing fewer mall searches than that.

But to get back to the original question:
stannius said:
It seems that the return value from mall_price isn't used for anything? Or is that what loads up historical_price? Why not just use mall_price directly? Since it pulls the value from cached data anyways? Aren't questions great?
Click to expand...

When I invoke mall_price() without saving the result, mafia will save the result and use it to update historical_price() with the most recent value.
 
Last edited:
I don't ever want to automate semirares in HC/Ronin, but is it possible to use this script to abort when one is due, to allow me to get in manually? (When doing a lazy/semiautomated run, or using bumcheekascend, say?)
 
Except that he does NOT want to automate SR in HC, but he DOES want it to stop. :) That means editing the script to still detect that counters are triggering, but to abort instead of giving a message and burning your SR or actually automating your SR.
 
If you don't want to get semi-rares in HC it will stop. Just leave BaleCC_SrInHC set to false.

That's standard behavior. Nothing special needs to be configured. It will stop when you are automating adventures just as you desire.

The only problem is when you are using BumcheekAscend. That is a BUG in BumcheekAscend so report it to him! I'm getting tired of being asked to fix his bug.
 
Last edited:
Any script that uses a while loop with !adventure will continue to adventure past semirares. If it uses adventure (without the if adventure{}) or doesn't loop, it should abort properly.

My ballroom levelling script uses a while loop with !adventure so it continues if I lose, since back when I needed the script a lot, it was the NC adventures I was needing and losing combat didn't mean I wanted it to stop. :) There are other scripts out there, but BCA is the most visible currently.
 
slyz said:
Oh, BCC captures the error and just keeps going?
Click to expand...

Correct. It's tucked into a happy little while() loop that doesn't give a flying fuck about the reason adventure() ceased adventuring.

I posted in bumcheekcend's thread and hopefully he'll finally fix this annoying bug. I call it "annoying" because it is annoying me and I don't even use his script. Even Veracity would agree that is a valid reason to call a bug annoying.
 
Last edited:
Sorry Bale, that was both ignorant and rude of me to make that assumption/fail to do my research. That's what I get for posting in a hurry.
Please accept my apologies, and I'll take it to BCC.

EDIT: That said, I was playing around with CounterChecker myself, and this appeared to do what I want (in main):
Code: 
	case "Fortune Cookie":
		if(!can_interact() && vars["BaleCC_SrInHC"] != "true") {
			print("Semi-rares choices are not automated in hardcore or ronin.", "red");
			print_html("<font color=\"FF9900\">Your last semi-rare adventure was at <u>"+get_property("semirareLocation")+"</u>, so plan accordingly.</font>");
			[color=red]abort("APG - stopping to get semirare manually");[/color]
			return false;

Gave:
Request 1 of 163 (Plains: Palindome) in progress...
Checking for updates (running CounterChecker ver. 1.49995)...
Running CounterChecker version: 1.49995 (current)
Checking counters now.
Semi-rares choices are not automated in hardcore or ronin.
Your last semi-rare adventure was at Dark Elbow of the Woods, so plan accordingly.
APG - stopping to get semirare manually
Click to expand...
 
Last edited:
illarion said:
Sorry Bale, that was both ignorant and rude of me to make that assumption/fail to do my research. That's what I get for posting in a hurry.
Please accept my apologies, and I'll take it to BCC.
Click to expand...

I hold no grudges. I don't really expect people to research everything. I was just being a little cranky. Please do take it to BCC though, people need to get up his stovepipe about that.
 
something like:
PHP: 
boolean continue = true;
while ( condition && continue )
{
    continue = adventure( 1, loc );
}

EDIT: or
PHP: 
while ( condition )
{
    if ( !adventure( 1, loc ) ) abort();
}
 
Last edited:
I'd still use a while, but include checks which break the loop if something interrupts adventure(). You can meaningfully use the result of adventure() rather than just capturing it. You can check lastEncounter or lastAdventure properties. There are ways.
 
Eh, the problem with that is getting beaten up aborts it, and that's the main reason for the while loop... continue until it works, long as you can.

What you want is something more like:
Code: 
boolean aborting = false; 
while ( condition ) 
{
    int adventurecount = my_adventures();
    (!adventure( 1, loc )); 
    if (adventurecount == my_adventures()) abort("Your adventure didn't take up a turn, so something went wrong. Maybe you had a counter trigger or something... aborting!");
}
 
You must log in or register to reply here.
Back
Top