Bug - Waiting for Info Not recognizing having 2 gaudy keys and keeps adventuring

Here is what happens. BCC sets the goal to '2 gaudy key'. Mafia adventures till it gets 1 gaudy key, then the automation occurs to use it. Then BCC sets the goal to '2 gaudy key'. Mafia keeps adventuring till it gets 2 more gaudy keys. Unlike in places like the small pyramid where it recognizes how many crumbling wheels it has and only goes for how many you need. I am including a section of a session log to show how this is happening.
View attachment gauidy.txt
 

Veracity

Developer
Staff member
BCC sets the goal to 2 gaudy keys
We acquire 1 and "the automation occurs to use it".

What automation are you talking about? I see no code in KoLmafia to automatically use a gaudy key.

BCC sets the goal to 2 gaudy keys

Why did it do that? Since it already got one, why would it say it wants two more? And, having told KoLmafia that it wants to get 2 more gaudy keys, in what way is it a KoLmafia bug that it does what BCC told it to do and adventures until it gets 2 more?

I don't know what you are talking about when you say "it recognizes how many crumbling wheels it has and only goes for how many you need". What is "it"? Since you seem to be talking about something that uses crumbling wheels in the control room as it gets them - which is definitely not KoLmafia itself - I assume you are, again, talking about how BCC behaves.

In any case, the title of this is says KoLmafia "doesn't recognize 2 gaudy keys" - but you specifically said that "automation" "used" the first gaudy key, converting it into a snakehead charrrm, which means that when you got the second key, you no longer had "2 gaudy keys" to "recognize".

From what you are describing, I'm not seeing a KoLmafia bug.
 
Set this to waiting on more info please and I will run the gaudy key steps manually next ascension and see what happens. As for the crumbling wheel. Say you set the goal to 9 crumbling wheel and then go adventuring in the pyramid each time mafia finds one it will decrement the number by one if you check the goal each time. It does not appear for gaudy keys it is doing this.
 

Veracity

Developer
Staff member
Say you set the goal to 9 crumbling wheel and then go adventuring in the pyramid each time mafia finds one it will decrement the number by one if you check the goal each time.
That's how all goals work.

It does not appear for gaudy keys it is doing this.
Perhaps you missed the part where I said "I see no code in KoLmafia to automatically use a gaudy key." I'll go farther: "I see no code in KoLmafia to do anything whatsoever when you get a gaudy key; the ONLY code that looks at ItemPool.GAUDY_KEY 1) makes sure you are wearing pirate fledges or the swashbuckling getup before trying to use one from the GUI or a script or 2) only removes the key from inventory if KoL says it actually consumed it."

Looking at adventure automation, after running an adventure - and getting the gaudy key - the only thing that KoLmafia.executeAdventureOnce does before checking goals is to execute your afterAdventureScript. If that happens to use a gaudy key as soon as it gets one, obviously the goal will not be satisfied.

What is your afterAdventureScript?
 

Theraze

Active member
As Veracity said, neither BCA nor KoLmafia will automatically use a single gaudy key. If your between battle or after adventure script automatically uses a single gaudy key for no useful reason, then that's on you.

Here's the entire BCA gaudy key code.
Code:
		bumAdv($location[Belowdecks], maxstring, "", "2 gaudy key", "Getting the Talisman");
		if (cli_execute("make talisman o namsilat")) {}
Aka, set a condition for 2 gaudy keys, adventure belowdecks until we have a total of 2, regardless of whether we started with 0, 1, or 2. Then try to make the talisman, but we don't really care about the results because the user may have already had mafia autocreate it due to having 2 gaudy keys.
 
As Veracity said, neither BCA nor KoLmafia will automatically use a single gaudy key. If your between battle or after adventure script automatically uses a single gaudy key for no useful reason, then that's on you.

Here's the entire BCA gaudy key code.
Code:
        bumAdv($location[Belowdecks], maxstring, "", "2 gaudy key", "Getting the Talisman");
        if (cli_execute("make talisman o namsilat")) {}
Aka, set a condition for 2 gaudy keys, adventure belowdecks until we have a total of 2, regardless of whether we started with 0, 1, or 2. Then try to make the talisman, but we don't really care about the results because the user may have already had mafia autocreate it due to having 2 gaudy keys.

Its not the use that is the issue. It is the goal setting. I stated the issue incorrectly I will need to regroup and rewrite after I get to test it. So let this lie.
 
What is your afterAdventureScript?

Don't have one I use BCA, CounterChecker and Universal Recovery. Here is what I am trying to report

When you normally set a goal. Such as "9 crumbling wheels". and then tell Mafia to adventure in the Pyramid for X turns everytimes it finds a crumbling wheel and you go back to the goal it has decremented it by one even if you stop and restart the adventuring and haven't complete the goal. SO in this case If have gotten 3 wheels and kill adventuring, and restart it doesn't go for 9 wheels it goes for 6.


When you set or something sets a goal of '2 gaudy keys' and then tell Mafia to adventure in the Belowdecks for X turns it never decrements the goal if the kill the adventuring after it gets one gaudy, and then restart the adventuring it still thinks it needs 2 gaudy keys instead of 1.
 

fronobulax

Developer
Staff member
So you are saying that if you set a goal of X something, auto adventure, stop auto adventuring after Y < X have been found and then start again, mafia will use a goal of X-Y something? That sounds like the expected and desired behavior to me.

If that is not the behavior you want then a Feature request might be in order.

If there is a particular something where that is not true then there is an issue but the claim that it is the gaudy key lacks credibility according to code inspections.
 
So you are saying that if you set a goal of X something, auto adventure, stop auto adventuring after Y < X have been found and then start again, mafia will use a goal of X-Y something? That sounds like the expected and desired behavior to me.

If that is not the behavior you want then a Feature request might be in order.

If there is a particular something where that is not true then there is an issue but the claim that it is the gaudy key lacks credibility according to code inspections.

If you read what I wrote it works differently between two different goals for two different items. I would expect it work the same across all goals.
 

Veracity

Developer
Staff member
I looked into how & when we update goals. For items:

If you gain a positive number of an item, we decrement the goal by that amount.
If you gain a negative number of an item - "use" it, for example - we do not touch goals.

So, I expect the following:

- You set your goal to be "2 gaudy key"

- You adventure until you find the first gaudy key.
ResultProcessor.processResults (eventually) calls
ResultProcessor.processResult( <gaudy key (1)> ) calls
-- ResultProcessor.gainItem( <gaudy key (1)> ) calls
-- GoalManager.updateProgress( <gaudy key (1)> )
--> your goal becomes "1 gaudy key".

- You stop automation and "use" the gaudy key.
UseItemRequest.parseConsumption( <gaudy key (1)> ) calls
ResultProcessor.processResult( <gaudy key (-1)>) calls
-- ResultProcessor.gainItem( <gaudy key (-1)> ) DOES NOT CALL
-- GoalManager.updateProgress( <gaudy key (-1)> )
--> your goal stays "1 gaudy key".

You say this did not happen. Now, all my characters are overdrunk, so I can't adventure, but I tried this:

goal set 5 hair spray
goals
--> hair spray (5)
buy 3 hair spray
goals
--> hair spray (2)
use 3 hair spray
goals
--> hair spray (2)

which is exactly what I expected; "gaining" an item updates goals, but "losing" an item does not.
 
It is odd It works like you stated for everything but gaudy keys. I will try it next time manually when I get to that step in my next ascension.
 

fronobulax

Developer
Staff member
If you read what I wrote it works differently between two different goals for two different items. I would expect it work the same across all goals.

I was reading what you wrote in hopes that I might understand it well enough to look at the code and fix it or explain why it was not a problem. Clearly there is a gap between my reading comprehension and your writing. I can certainly just sit back and let someone else deal with this and just learn from their solution. I've probably overapplied principles of active listening in which the listener deliberately paraphrases and restates what they thought they heard in order to get clarification or agreement. My problem, not yours.
 

Veracity

Developer
Staff member
I was reading what you wrote in hopes that I might understand it well enough to look at the code and fix it or explain why it was not a problem.
A fine goal. Look at his DEBUG log when he posts it and see what you can figure out. :)
 
Top