Bug - Fixed Grey GUI on autostop during Relay adventuring

[Bale]

Lately I've noticed that when I'm adventuring in the relay browser and I have an autostop adventure my charpane.ash override doesn't alter my charpane. Apparently this happens because my Mafia GUI grays out.

Thanks to Clancy I get some completely predictable autostops so I was able to easily execute the following procedure:

1. I started a debug log immediately before an autostop.
2. Encountered "A Miner Variation"
3. In the GUI I typed "greygui" and hit enter.
4. Then I stopped the debug log.

Is the debug log PLUS greygui command overkill?

I see that my mood script and recovery script go on for quite a while in the debug log before I ever get the autostop, but I'll attach the whole huge thing here.

 

[slyz]

What was the result of the "greygui" command? Not that I really understand the output of that command, but I guess it might help.

 

[Bale]

There was no output in the GUI, I believe it outputs to the debug log.

 

[lostcalpolydude]

I get the same thing without any before or after adventure scripts running, using (mostly) the same charpane override.

My guess is GoalManager.checkAutoStop() setting the PENDING_STATE. I added a printLine() statement in there, but then I didn't have any autostop adventures left for the run.

The only line in Bale's log that stood out for me was

Processing result: Advs Used: -1

Not that I knew what I was looking for.

 

[slyz]

Oh, the first time I looked at the file the end wasn't there for some reason.

 

[lostcalpolydude]

I got to an autostop adventure (started a new run), and the printLine() statement I added to GoalManager.checkAutoStop() ran, so that's where it is.

		if ( GoalManager.goals.isEmpty() )
		{
			RequestLogger.printLine( "GoalManager.checkAutoStop is triggering.");
			KoLmafia.updateDisplay( KoLConstants.PENDING_STATE, message );
		}

I'm not really sure how stuff gets printed to the CLI and session log in general, so I don't know if a check for manual adventuring belongs in KoLmafia.recognizeEncounter() or GoalManager.checkAutoStop().

On an unrelated note, hasOtherGoals in checkAutoStop() is never used.

 

[Veracity]

My guess is GoalManager.checkAutoStop() setting the PENDING_STATE. I added a printLine() statement in there, but then I didn't have any autostop adventures left for the run.

Heh. I browsed the code and came to the same conclusion.

I've wondered why special adventures and semirares and such registered the Encounter in the gCLI and then also printed out the encounter name again. This is why.

Seems to me that this only applies to automated adventuring; if you are in the Relay Browser, you can see what is happening and decide on your own what you want to do. Perhaps changing GoalManager.checkAutoStop like the following would do it:

		if ( !KoLmafia.isAdventuring() )
		{
			return;
		}
		else if ( GoalManager.goals.isEmpty() )
		{
			KoLmafia.updateDisplay( KoLConstants.PENDING_STATE, message );
		}
		else
		{
			RequestLogger.printLine( message );
			RequestLogger.printLine( "There are still unsatisfied conditions." );
		}

 

[Veracity]

Yes. Revision 10835

 

[lostcalpolydude]

Should all cases of PENDING_STATE have a check for isAdventuring() ? CouncilFrame has three of them, which I discovered when completing the friars quest triggered it.

 

[Veracity]

I'd say so.

 

[lostcalpolydude]

Here's a patch to fix the three instances in CouncilFrame, which are the only cases I've encountered while ascending.

 

[slyz]

r10859

 

[holatuwol]

Shouldn't the checks go into the updateDisplay instead of in every case where we use pending state?

 

[slyz]

Do you mean that Mafia shouldn't ever enter a PENDING_STATE when not automating?

 

[holatuwol]

From what I'm hearing, it should do it if it's from a script or from adventure automation, but nothing else.

 

[slyz]

I've never really understood what PENDING_STATE was meant for. Is it like a temporary ABORT_STATE? Meant to warn the user/script about something, but cleared more easily than an ABORT_STATE?

 

[Veracity]

Stop automation - e.g., break out of an adventure(100, xxx) call - without stopping the script entirely.