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

[Chef_Rannos]

Add this line to your CCS:

special action

and tell Mafia to automatically ID the spheres, either in the right-click menu of the "Special:" section (adventure tab), or by typing "set autoSphereID = true" in the gCLI.

You can also tell it to identify bang potions by doing this, if you wanted to use the boxes earlier in the run and have them identified before going to the gates.

 

[Chef_Rannos]

Last 2 ascensions the script has curiously failed to do the nuns quest, it's been only spending 1 turn there then moving on to the battlefield to clear out frat boys. Log below:

I didn't notice until I analyzed my last run, but I did it as a Frat Warrior (HCNP AT) and the .33 script only did one adventure in Themthar Hills for me. Obviously I only have my mafia log for it, no GLCI output, but I'll keep an eye on it this run in case it happens again.

 

[morgad]

Thus has not worked for me in over a month (as a hippy), feel free to add any info to
https://sourceforge.net/tracker/?func=detail&aid=3397580&group_id=503565&atid=2048077
to help track down the cause.

best regards
Dave

 

[bumcheekcity]

It must be a rogue condition causing bumMiniAdv() to fail. I've added a conditions clear to 0.34 which should fix it.

 

[Dreamthief]

Errors

You need 1 more detuned radio to continue.

 

[PartyBasher]

You need 1 more detuned radio to continue.

I get this one too. I'm guessing you're in the fist challange run?

I think (someone already mentioned this a page or two back) it will be worth the effort to add basic fist support. Even disabling/minimized meat spending would allow scripting the most of the ascension- right now it just aborts.

 

[bumcheekcity]

I've used the script for a few fist runs actually.

and dreamthief, youre going to need to give some actual information with your bug report.

 

[fronobulax]

You need 1 more detuned radio to continue.

I've seen this message. I believe it occurred when my moon sign let me go inside DeGrassi Knoll, the script wanted to raise monster level for me and there was not enough meat to buy the radio. Obviously this occurs early in a run, or not at all. I'll try and watch more closely next time it happens.

 

[Theraze]

Believe this happens anytime a 'retrieve_item' call fails without being encapsulated... if you don't want the script to abort if the retrieval fails, you need to do something like

(!retrieve_item(1, $item[detuned radio]));

instead.

 

[morgad]

It must be a rogue condition causing bumMiniAdv() to fail. I've added a conditions clear to 0.34 which should fix it.

not sure where you added the extra line, but I just tried this

				//Put on the outfit and adventure, printing debug information each time. 
cli_execute("conditions clear");

				buMax("nuns");
				while (my_adventures() > 0 && prepSNS() != "whatever" && bumMiniAdv(1, $location[themthar hills]) && get_property("currentNunneryMeat").to_int() < 100000) {

					print("BCC: Nunmeat retrieved: "+get_property("currentNunneryMeat")+" Estimated adventures remaining: "+estimated_advs(), "green");

				}

				

				visit_url("bigisland.php?place=nunnery");

			break;

and the problem persisted ...

best regards
Dave

 

[slyz]

It looks like the problem is bumMiniAdv()

boolean bumMiniAdv(int adventures, location loc, string override) {
	if(!bumMiniAdv2(adventures, loc, override)) {
		abort("BCC: You aborted, so so am I");
	}
}

Since it doesn't specify a return value, the return value defaults to false.

Change it to:

boolean bumMiniAdv(int adventures, location loc, string override) {
	if(!bumMiniAdv2(adventures, loc, override)) {
		abort("BCC: You aborted, so so am I");
	}
	return true;
}

 

[Veracity]

It looks like the problem is bumMiniAdv()
Since it doesn't specify a return value, the return value defaults to false.

ASH is supposed to detect when you have a non-void function which doesn't return a value of the correct type and give you a compile error.

On the other hand, looking at Parser.parseFunction(), I see:

		if ( !result.assertReturn() && !functionType.equals( DataTypes.TYPE_VOID )
		// The following clause can't be correct. I think it
		// depends on the various conditional & loop constructs
		// returning a boolean. Or something. But without it,
		// existing scripts break. Aargh!
		&& !functionType.equals( DataTypes.TYPE_BOOLEAN ) )
		{
			throw this.parseException( "Missing return value" );
		}

...there is obviously something funky going on. I wouldn't mind removing the bogus clause and seeing which scripts break - and fixing ASH so that they no longer break - or fixing actually erroneous scripts.

File a bug report. ASH should fail your script validation, rather than letting your bogus function slide by and do what you don't expect it to do.

 

[bumcheekcity]

Good find, slyz, thanks!

 

[Veracity]

As a followup, the following script shows that ASH's return value checking is busted:

int test( int a, int b )
{
	if ( a < b ) {
		return a;
	} else {
		return b;
	}
}

This fails validation with "missing return value".

 

[Winterbay]

As a followup, the following script shows that ASH's return value checking is busted:

int test( int a, int b )
{
	if ( a < b ) {
		return a;
	} else {
		return b;
	}
}

This fails validation with "missing return value".

Yes, I have a bunch of functions that have a "return x" at the end of them because ASH fails to see that a case such as that exist. Not a big problem but a small annoyance

 

[Veracity]

File a bug report. ASH should fail your script validation, rather than letting your bogus function slide by and do what you don't expect it to do.

Yes, I have a bunch of functions that have a "return x" at the end of them because ASH fails to see that a case such as that exist. Not a big problem but a small annoyance

I guess this wasn't important enough to file a bug report. Apparently, people would prefer for their erroneous ASH scripts to mysteriously fail because it didn't detect the bug, or for their correct ASH scripts to fail to validate, because ASH erroneously thought there was a bug.

I'll open a bug report myself, for the record, and ignore it.

 

[Winterbay]

I would probably have done that had I not had head off to bed very shortly after writing that as I was rather tired and would have done a really poor bug report that would most likely have lead nowhere anyway due to being horrible formulated

Edit: Post has been made, hopefully it's not entirely confusing because I have actually no idea what the problem is on the backend...

 

[Crowther]

I've seen this message. I believe it occurred when my moon sign let me go inside DeGrassi Knoll, the script wanted to raise monster level for me and there was not enough meat to buy the radio. Obviously this occurs early in a run, or not at all. I'll try and watch more closely next time it happens.

I've gotten the detuned radio message when I had "telescope as you go" running and it tried to collect a telescope item and set the MCD before selling my pork gems, so I had zero meat. A bit of a bug, but I hadn't had a chance to look and see which tower test was the problem. I'm guessing it's probably something low level like spider web.

 

[Ferdawoon]

I know that fistcore is not fully supported, but I still feel like mentioning that the "safe limits" should not be that strict. When I did fistcore manually I beat NS as soon as I hit lvl13, but with the script is closing in on lvl14. Adjusting the safety levels a bit could shave off a fair few turns of leveling I'd guess.

 

[bumcheekcity]

Yeah, the fistcore limits are being toned down by about 20 moxie in fistcore.