Bug - Won't Fix Black Cat batting used items away not detected

Theraze

Theraze

Active member
When the black cat familiar bats away an item that you try to use, the item isn't destroyed... unless that item happens to be the scroll you're putting into a Rampaging adding machine, in which case, the item isn't immediately destroyed, but the auto-insert code fails to realize that the last insertion was actually aborted. This means that when it tries to insert the next scroll, it usually won't insert one that properly makes another scroll, and will destroy both of them.

I just had the joy of triple-collecting scrolls for BC BM, and manually finishing up the quest in the relay browser, which worked fine because I, unlike the autoautoadventure, actually detect when the BC bats an item away, but thought I should report this so that other people don't need to pay that much attention. :)
 
Last edited:
Didn't have it set to log familiar actions to the session log... will try and see if having it logging the batting away makes the client more aware of the consequences. Will be at least a day or two before I can know for sure, and even then it should be aware of it, whether it displays or not...
 
I can't find the thread(s), but this has come up several times before, and if I remember correctly the devs' answer was that it's too much work to implement something that will be used only during a handful of turns by people doing their one and only kittycore run.
 
Hmm... since the batting away follows a standard message, and it'll likely come up heavily during the Level 12 flyering as well, it shouldn't be that hard to put in a check that if an item is batted away, the use just didn't happen, and don't change either the inventory (since it'll be wrong if you remove that item) or combat plan (since if you were going to use a rusty bonesaw, for example, you still have that bonesaw and presumably want to use it). Possible this is already implemented normally... I noted that it took 6-7 uses of the bonesaw to actually succeed instead of 2, but...

And some of us poor lost souls screwed up our kittycore rounds by accidentally using the black kitten before the terrarium, which makes Kolmafia think that the BC is available, until you switch into the relay browser and see that you're not actually using any familiar, and then you look at your inventory and still see both the kitten and terrarium and depression starts to sink in and you tell yourself: I won't forget to do that again... more than twice.
 
The most straightforward fix for the adding machine might be to not automate the fight at all (regardless of settings) if you have the black cat out. I'm only guessing though.
 
True... if black cat is your familiar, and you're fighting an adding machine, it could just force a request sync... That shouldn't take too much extra coding, and at least avoids the "why have i spent 300 turns on the chasm" question.
 
Okay, just whipped this up... added a break for the hulking construct as well, since that also has similar item issues (and auto-handle code). Using an abort, but not a forced request synch because some people may prefer the relay browser as opposed to the mini-browser. If I understand what I've done properly, it shouldn't affect anything besides adding and construct fights while using a black cat...

Just to clarify, I left it in a way that would only abort combat if it would have otherwise automatically used the internal code... If in bird form or waiting for a special action to happen, it will either continue to fight or wait for the special action, and only when it would have otherwise gone on to the internal item code, abort.
 
Last edited:
Have you tried your own patch? I will say now that I haven't, but the following line looks dodgy to me:

Code: 
if ( KoLCharacter.getFamiliar().getId() == FamiliarPool.BLACK_CAT
	&& !KoLConstants.activeEffects.contains( FightRequest.BIRDFORM )
	&& !FightRequest.waitingForSpecial )
	&& ( FightRequest.encounterLookup.equals( "rampaging adding machine" )
	|| ( FightRequest.encounterLookup.equals( "hulking construct" ) ) )
	{
		KoLmafia.updateDisplay( KoLConstants.ABORT_STATE, "Aborting combat automation due to Black Cat." );
		return;
	}

&& !FightRequest.waitingForSpecial ) looks as though it closes the if statement.
 
Yeah... my copy of ant was screwing up, so I couldn't make sure my parenthesis were closing properly. :) A manual declarion of JAVA_HOME later, it now actually compiles and the extra ) after waitingForSpecial and the extra ( before the hulking construct are gone.
 
Last edited:
One final question, because I don't know a great deal about these, but is it possible for consult scripts or KoL combat macros (which can be submitted via ccs) to work on a round-by-round basis, detecting whether these items were batted away? If so, I imagine a change like this could become tiring.
 
Actually, the way the code is written, adding machines and hulking constructs apparently short-circuit past your CCS... doesn't matter what you want it to do, the system knows best. At least, based on the comment here:
Code: 
 		// Adding machine should override custom combat scripts as well,
 		// since it's conditions-driven.
 
Yeah... I don't really see anyone using Black Cat and trying to finish up the Hulking Construct, but... it may happen someday. Heh. The other thing I could do would be to make an internal variable set if the Black Cat bats an item away, to tell the adding machine and hulking construct that their last action failed and to try again, but I'd need to be given a variable name to use. I'd gladly do it, total time for that change would be about 5-10 minutes and then the automation can continue, but... depends on what the developers want. :)
 
I see your point. I'm not sure it's a big enough issue to matter to most people, though. The abort is probably useful, but may also confuse folks. I doubt many people will realise it is to protect them (since they will then not encounter mafia's difficulty at handling the batting away). Coping with the rejected items will probably avoid the odd bug report here and there.

Just out of interest, is there a reason you use:

Code: 
KoLmafia.updateDisplay( ... );
return;

Instead of:

Code: 
KoLmafia.updateDisplay( ... );
FightRequest.action1 = "abort";
return;
 
Nope, I just started with Request Synch code, and that isn't found in fightrequest, but adventurerequest... when I decided not to force the request synch, I was still in adventure, not fight, hence the lack (before now) of the abort action. That looked like a good addition, since most (but not all... wha?) of the aborts in FightRequest seem to include it.

Edit: As I was looking through the code, I noted that the OAF familiar can also change from items to attack... added them into the abort code as well, because there's probably at least a few people out there crazy enough to try a 100% OAF run. Also changed the abort message to hopefully make a bit more sense, as well as not be specific towards the Black Cat, since it's not the only one.
 
Last edited:
Well, that version does indeed switch to mini-browser when you try to adventure with a black cat and hit a rampaging adding machine... I'll try tomorrow and see if skipping the FightRequest makes it not pop a mini-browser window... If I can work through how I want the automatic continuation to work, I may code that instead...
 
Good point... hadn't noticed that before. Apparently works on BC as well, though not really since you can't get the TCW when HC BM, but those are relatively insignificant details... Some crazy person out there may try using BC outside HC someday and wonder why it quits out. This current version has the fight action commented out, which I hope will remove the auto mini-browser window (making it easier to use the Relay browser instead)... if it does work as I expect, I'll delete the commented line. It also has an equipment check for tiny costume wardrobe now. Let me know if I screwed anything up in the equipment check... I haven't found the "this is which functions do what, how" manual yet for Kolmafia's code. :)

Edit: Okay, tried it out today, the removed "fightrequest" doesn't seem to have removed anything at all. Still aborts combat, still launches the mini-browser. Updated the patch to no longer have that.
 

Attachments

Last edited:
Been rethinking this and if possible, would potentially be nice to have it realize if an item is batted away or otherwise disrupted. Not sure if there's any other things that need to be detected besides scrolls with the RAM, where the order of multiple items matters? On normal item-fails, we'd want it to reconsider which item to use...

Also suppose it would be good to detect BC/OAF on bounty hunts and other such guaranteed items failing to drop... It's not that they failed to drop, it's that the familiar either lost the item or sold it... But it doesn't mean that the game is necessarily broken, just that your familiar sucks. :)
 
Last edited:
Veracity has said in the past that she believes a Black Cat ascension is meant to be painful and she doesn't want mafia to ameliorate that pain. KoLmafia is meant for dealing with extremely repetitive tasks. You only do Black Cat once (ideally) so you should actually do it.

Personally I agree with her.
 
You must log in or register to reply here.
Back
Top