bumcheekcend.ash - A zero setup semi-automated ascension script!

Can that [1] even work if the macro uses native kol macro syntax (call ...)?
I would try ading
Code: 
print get_ccs_action(round);
before the return, for greater debug.

[1] either get_ccs_action, or returning from consult script
 
Thanks xKiv,
I should have spotted it is a string :)
I've added
Code: 
	string r = get_ccs_action(round);
		print("CCS: " + r, "blue" );
		return r;
But it will be a couple of days to get to the Barrrr or similar that calls consulCasual rather than my default script setting.
 
Last edited:
So ... this time I am ascending as an Accordion Thief and the problem struck in Barrrney's Barrr. I traced the code to consultBarrr() which I amended to:
Code: 
string consultBarrr(int round, string opp, string text) {
	if (!isExpectedMonster(opp)) return ((my_primestat() == $stat[Mysticality] && in_hardcore()) ? consultMyst(round, opp, text) : get_ccs_action(round));
	print("In consultBarrr()", "red" );
	if (round == 0 || round == 1 && have_effect($effect[Embarrassed])==0 ) {
		if (my_path() == "Bees Hate You") return "item Massive Manual of Marauder Mockery";
		return "item the big book of pirate insults";
	}
	// return ((my_primestat() == $stat[Mysticality] && in_hardcore()) ? consultMyst(round, opp, text) : get_ccs_action(round)); 
	string r = get_ccs_action(round);
	print("CCS: " + r, "blue" );
	return r;

}
Note the addition of a check for Embarrassed because consultBarrr() was using the book twice (which wasn't the problem).
When my CCS was:
Code: 
[ barrrney's barrr ]
call athard

[ global prefix ]
sub checkfamiliar
    if hasskill release the boots
        skill release the boots
    endif
    if happymediumglow red
        skill siphon spirits
    endif
endsub
sub atnormal
	attack with weapon
endsub
sub athard
	if hasskill Accordion Bash && !mpbelow 5
		skill Accordion Bash
	endif
	attack with weapon
endsub
The result was:
Round 2: You gain 27 Mojo Points
In consultBarrr()
CCS: call athard
You don't have enough null
You're on your own, partner.
Click to expand...
When the CCS was:
Code: 
[ barrrney's barrr ]
if hasskill Accordion Bash && !mpbelow 5
	skill Accordion Bash
	endif
	attack with weapon
The result was:
In consultBarrr()
CCS: endif
You don't have enough null
You're on your own, partner.
Click to expand...
When the CCS was:
Code: 
[ barrrney's barrr ]
if hasskill Accordion Bash && !mpbelow 5; skill Accordion Bash; endif
attack with weapon
Everything worked as expected.
Because "+effective" didn't think I had a powerful enough accordion there is no Accordion Bash to happen.
This looks like either a bug or a poorly documented feature in get_ccs_action().
You could argue that this obeys a very literal interpretation of:
This will only return a value from the section of the CCS for the monster that is currently being fought.
Click to expand...
But you could also argue that:
Macros may be used in a Custom Combat Script in addition to the basic commands. Any line in quotes and any macro command used in a CCS will be made into part of the macro which KoLmafia is passing to KoL. You can find an primer on all KoL's macros at Combat Macros.
Also there is a section in the CCS called "global prefix" which will be part of every combat macro KoLmafia generates, regardless of the monster encountered.
Click to expand...
indicates that Macros and "global prefix" will be part of any actions. :(
My thought is that the first occurrence probably isn't a bug but the second should be ... thoughts?
 
Last edited:
I think that get_ccs_action is defined to return one *line* of the current ccs. Passing that can work only if the line is a complete thing.
 
Hmm, the second example obviously doesn't match your interpretation, otherwise it would have returned "if hasskill Accordion Bash && !mpbelow 5". Anyway it is not a BumCheekCityAscend issue so I need to move it to bugs.
 
Gnocchi Masala said:
Hmm, the second example obviously doesn't match your interpretation, otherwise it would have returned "if hasskill Accordion Bash && !mpbelow 5". Anyway it is not a BumCheekCityAscend issue so I need to move it to bugs.
Click to expand...

It printed a line of your ccs. It was not the line you expected, but it was a complete line.
 
Fine, then I'm calling BCA bug.

I have a full featured CCS capable of supporting a hands off ascension. There is no way to tell BCA to only use my CCS ( or rather my selected KolMafia combat setting ). As soon as I am out of ronin and at several points prior it abandons all common sense and uses the brain dead get_ccs_action(round) function which trashes most of the advanced CCS features.

I suggest there should be a BCA config variable that causes adventure() and its brethren to always be called with a null string for the combat filter.
I would also be willing to have BCA run all the combats if it did not dump me when I get out of ronin.
 
Last edited:
What on earth is this:

BCC: We have 2 clovers and are using one to level.
Using 1 disassembled clover...
You acquire an item: ten-leaf clover
Finished using 1 disassembled clover.
Unknown Adventure #395 = adventure.php?snarfblat=395&confirm=on
Unknown Adventure #395 = adventure.php?snarfblat=395&confirm=on
Unknown Adventure #395 = adventure.php?snarfblat=395&confirm=on
Conditions list cleared.
Checking for familiar 'Pair of Stomping Boots' where x=1
Checking for familiar 'slimeling' where x=2
Mood swing complete.
That area is not available.

BCC: You aborted, so so am I. This abort may have been caused by a rogue condition not being met. If this is unexpected, please paste the CLI output, as well as the results of typing 'condition check' without the quotes, into the mafia CLI window now.

The script won't proceed no matter what I do :(
 
Theraze said:
Beaten up and 0 health, and so it can't actually clover-level?
Click to expand...

It happens even when I'm at full health with no beaten up status. It's almost like it's trying to clover at a place that does not exist/inaccessible.
I managed to bypass this problem by manually playing the game for a while and levelled up but wondered how I could avoid this problem in future runs?
 
395 is haunted ballroom, and "Unknown Adventure" means that mafia couldn't resolve the url into a known adventure. Which is probably because of that "&confirm=on" tacked on there. What's that, the "recommended stats" warning?
 
That's weird, and maybe mafia bug/issue?

(quoting returned values from debugged instance of mafia)
Code: 
net.sourceforge.kolmafia.KoLAdventure.findAdventure("adventure.php?snarfblat=395")
 (net.sourceforge.kolmafia.KoLAdventure) Manor2: The Haunted Ballroom

net.sourceforge.kolmafia.KoLAdventure.findAdventure("adventure.php?snarfblat=395&confirm=on")
	 null

Mafia doesn't expect this confirmation to be present in script-supplied urls.
Is there any other way to make mafia clover a location (i.e. script automatical adventuring somewhere *without* dismantling clovers)?
(there's always the possibility of localizing cloverProtectActive, but that's ugly:
Code: 
string _outer_clover_protection = get_property('cloverProtectActive');
try {
  set_property('cloverProtectActive','false');
  // adventure in the place
} finally {
  set_property('cloverProtectActive', _outer_clover_protection);
}
)
 
Last edited:
Well, it works fine in the Bathole. And it usually works fine for me personally in the Ballroom.
I wouldn't expect the internal function findAdventure to match a non-correctly-distinct result. I would expect visit_url to visit the page and be successful. This is what I have experienced.
 
The clover confirmation is confirm1=on.

RelayRequest.java:

Code: 
	private static String CONFIRM_COUNTER = "confirm0";
	private static String CONFIRM_CLOVER = "confirm1";
	private static String CONFIRM_MCD = "confirm2";
	private static String CONFIRM_FAMILIAR = "confirm3";
	private static String CONFIRM_RECOVERY = "confirm4";
	private static String CONFIRM_SORCERESS = "confirm5";
	private static String CONFIRM_WOSSNAME = "confirm6";
	private static String CONFIRM_TOKENS = "confirm7";
	private static String CONFIRM_SEAL = "confirm8";
	private static String CONFIRM_ARCADE = "confirm9";
	private static String CONFIRM_KUNGFU = "confirm10";
	private static String CONFIRM_POOL_SKILL = "confirm11";
	private static String CONFIRM_WINEGLASS = "confirm12";
	private static String CONFIRM_COLOSSEUM = "confirm13";
	private static String CONFIRM_GREMLINS = "confirm14";
	private static String CONFIRM_HARDCOREPVP = "confirm15";
	private static String CONFIRM_DESERT_UNHYDRATED = "confirm16";
	private static String CONFIRM_MOHAWK_WIG = "confirm17";
	private static String CONFIRM_CELLAR = "confirm18";
	private static String CONFIRM_BOILER = "confirm19";
	private static String CONFIRM_DIARY = "confirm20";
	private static String CONFIRM_BORING_DOORS = "confirm21";
	private static String CONFIRM_SPELUNKY = "confirm22";
	private static String CONFIRM_ZEPPELIN = "confirm23";
When we try to match urls with adventures, we use this:

Code: 
	public static String removeConfirmationFields( String adventureURL )
	{
		return CONFIRMATION_PATTERN.matcher( adventureURL ).replaceAll( "" );
	}
And that pattern is:

Code: 
	private static final Pattern CONFIRMATION_PATTERN = Pattern.compile( "&confirm[\\d]+=on" );
Obviously, we could match 0 or more digits to get "confirm=on" too, but since KoLmafia doesn't use it itself, I don't see the point - unless KoL itself uses it.

If the script is really trying to disable clover protection, it should be using confirm1=on.
 
Huh, weird that it seemed to work when BCA last clovered for sonars for me. Is that a new change, or is there any way that should have worked for the months I've seen it go by?

Example from April 5th.
Session log:
Code: 
> BCC: Getting Clovers
> BCC: We're going to end up with one and exactly one ten leaf clover

Use 1 disassembled clover
You acquire an item: ten-leaf clover
Unknown Adventure #31 = adventure.php?snarfblat=31&confirm=on
Unknown Adventure #31 = adventure.php?snarfblat=31&confirm=on
Unknown Adventure #31 = adventure.php?snarfblat=31&confirm=on

[261] Guano Junction
Encounter: How I Wonder What You're At
You lose 5 hit points
You acquire an item: sonar-in-a-biscuit
You acquire an item: sonar-in-a-biscuit

use 1 sonar-in-a-biscuit

use 1 sonar-in-a-biscuit
The BCA code:
Code: 
			while (item_amount($item[sonar-in-a-biscuit]) < 1 && !contains_text(visit_url("place.php?whichplace=bathole"), "bathole_bg4")) {
				//Let's use a clover if we can.
				if (i_a("sonar-in-a-biscuit") == 0 && cloversAvailable(true) > 0) {
					if (my_hp() < 1 && !restore_hp(1)) abort("You can't get enough health to adventure. :(");
					clover_result[0] = visit_url("adventure.php?snarfblat=31&confirm=on");
					if(!contains_text(clover_result[0], "but you see a few biscuits left over from whatever bizarre tea party")) {
						map_to_file(clover_result, "BCCDebug.txt");
						abort("BCC: There was a problem using your clover. Please try it manually.");
					}
				} else {
					bumAdv($location[Guano Junction], "+10stench res", "items", "1 sonar-in-a-biscuit", "Getting a Sonars");
				}
				if (cli_execute("use * sonar-in-a-biscuit")) {}
			}
			if (cli_execute("use * sonar-in-a-biscuit")) {}
It didn't abort, it got the clovers. Mafia obviously thought it was a weird adventure - 3 times - but it went there and got my biscuits.

Sounds like if we change it from confirm - which seems to work, even if it's classified as an unknown adventure - to confirm1, then Mafia will know that we're doing a clover-confirm and not call it unknown anymore.

It won't fix the root problem of failed adventuring, but at least it should remove the unknown adventuring log messages.
 
From what I can tell, "confirm1=on" only does anything for relay browser adventuring.

From KoLAdventure
Code: 
		if ( AdventureDatabase.isPotentialCloverAdventure( adventureName ) && InventoryManager.cloverProtectionActive() )
		{
			KoLmafia.protectClovers();
		}
Clovers aren't disassembled because mafia is failing to recognize where you adventure.

It looks like the only proper way to get a clover adventure is to disable cloverProtectActive before adventuring. Or you can throw any random gibberish on the URL to keep mafia from recognizing it, the way things currently work.
 
So what you're saying is that I COULD change confirm to confirm1, but that wouldn't actually help anything - the only reason why it allows clover adventuring is because Mafia doesn't recognize we're adventuring, and this whole clover-trail has been a red herring to the actual problem that pasta angel brought up because we're already doing what we have to.
 
You must log in or register to reply here.
Back
Top