Bug - Fixed Checking what's trendy twice on login

Login routine is checking trendy things twice.
Code:
Validating login server (www.kingdomofloathing.com)...
750 players online.
Sending login request...
Using data override: data/mallprices.txt
Using data override: data/mallprices.txt
Initializing session for extirpator...
Refreshing session data...
Loading character status...
Seeing what's still trendy today...
Done. Are YOU a fashion plate?
Synchronizing moon data...
Seeing what's still trendy today...
Done. Are YOU a fashion plate?
Retrieving character data...
Refreshing closet...
 

matt.chugg

Moderator
Does running an apirequest trigger a trendy reset?

I can't find anywhere in there, but from the debug log it looks like the second check is actually the intended one..

in: KoLmafia.java
Code:
private void refreshSessionData()

{

...

		// Reset what is trendy
		TrendyRequest.reset();
		if ( KoLCharacter.isTrendy() )
		{
			TrendyRequest.initialize();
		}
...
}

However by the time it gets here, trendy has already initialised (from what looks like trendy being in the api request json) but is reset and reinitialised

Hope this helps, i'll try and figure it out properly later and make a patch!
 

Theraze

Active member
Is the double-trendy check to blame for infinite loops on trendy-run logins during combat/choiceadvs?
 

matt.chugg

Moderator
I don't think this is the cause of the issue, but I think theres a minor issue here

ApiRequest.java : public static final void parseStatus( final JSONObject JSON )
Code:
		try
		{
			// Pull out the current ascension count. Do this first.
			// Some later processing depends on this.
			int ascensions = JSON.getInt( "ascensions" );
			KoLCharacter.setAscensions( ascensions );

			// Pull out the current password hash
			String pwd = JSON.getString( "pwd" );
			GenericRequest.passwordHash = pwd;

			// Many config options are available
			AccountRequest.parseStatus( JSON );

			// Many things from the Char Sheet are available
			CharSheetRequest.parseStatus( JSON );

			// Parse currently worn equipment
			EquipmentManager.parseStatus( JSON );

			// Many things from the Char Pane are available
			CharSheetRequest.parseStatus( JSON );
		}
		catch ( JSONException e )
		{
			ApiRequest.reportParseError( "status", JSON.toString(), e );
		}

I don't think the CharSheetRequest parsing of the JSON should be happening twice. Althought i'm not up to speed yet, so there may be a good reason!

Code:
			// Many things from the Char Sheet are available
			CharSheetRequest.parseStatus( JSON );
...
			// Many things from the Char Pane are available
			CharSheetRequest.parseStatus( JSON );
 

slyz

Developer
Sounds like the second one should be
PHP:
// Many things from the Char Pane are available
CharPaneRequest.parseStatus( JSON )

I remember examining CharPaneRequest.parseStatus() and wondering why it was never called in the code.
 

slyz

Developer
It looks like the first TrendyRequest call happens in KoLCharacter.addAvailableSkill() when EquipmentManager.setEquipment() is called by EquipmentManager.parseStatus(), during the ApiRequest.

Mafia only becomes aware of a character's path after AccountRequest.parseStatus() is called, but we could move the TrendyRequest.reset() at the beginning of KoLMafia.refreshSessionData(), before the ApiRequest.

This way, when we log on or refresh the session data, we won't initialize TrendyRequest during the ApiRequest, then reset and initialize it again.

EDIT:

I guess we could simply remove those lines from KoLMafia.refreshSessionData()
PHP:
if ( KoLCharacter.isTrendy() )
{
	TrendyRequest.initialize();
}
since TrendyRequest will be initialized anyway whenever we first need it.
 
Last edited:

matt.chugg

Moderator
It looks like the first TrendyRequest call happens in KoLCharacter.addAvailableSkill() when EquipmentManager.setEquipment() is called by EquipmentManager.parseStatus(), during the ApiRequest.

Mafia only becomes aware of a character's path after AccountRequest.parseStatus() is called, but we could move the TrendyRequest.reset() at the beginning of KoLMafia.refreshSessionData(), before the ApiRequest.

This way, when we log on or refresh the session data, we won't initialize TrendyRequest during the ApiRequest, then reset and initialize it again.

EDIT:

I guess we could simply remove those lines from KoLMafia.refreshSessionData()
PHP:
if ( KoLCharacter.isTrendy() )
{
	TrendyRequest.initialize();
}
since TrendyRequest will be initialized anyway whenever we first need it.

I was thinking of just removing the second one too, but wanted to find out what was firing the first one to make sure it always worked before suggesting it!

I guess one could just remove the reset line and leave the call to initialise, since that checks if it's already initialised anyway and if for some reason it isn't it'll go ahead and do it.

Good learning for me anyway!
 
Last edited:

Theraze

Active member
Isn't the reset needed for if you have both Trendy and non-Trendy characters used during the same execution of mafia?
 

matt.chugg

Moderator
how about removing the specific initialise, and moving the trendy check higher up before anything has chance to initialise it, and let it initialise iteself when needed.

Code:
### Eclipse Workspace Patch 1.0
#P kolmafia
Index: src/net/sourceforge/kolmafia/KoLmafia.java
===================================================================
--- src/net/sourceforge/kolmafia/KoLmafia.java	(revision 10207)
+++ src/net/sourceforge/kolmafia/KoLmafia.java	(working copy)
@@ -817,6 +817,10 @@
 		KoLCharacter.setCurrentRun( 0 );
 		TurnCounter.loadCounters();
 
+		// Reset what is trendy, this will initialise when its first needed
+		
+		TrendyRequest.reset();
+		
 		// Get current moon phases
 
 		RequestThread.postRequest( new MoonPhaseRequest() );
@@ -841,13 +845,6 @@
 
 		KoLCharacter.resetPerAscensionData();
 
-		// Reset what is trendy
-		TrendyRequest.reset();
-		if ( KoLCharacter.isTrendy() )
-		{
-			TrendyRequest.initialize();
-		}
-
 		// Retrieve the character sheet. It's necessary to do this
 		// before concoctions have a chance to get refreshed.
 

Veracity

Developer
Staff member
Revision 10211 should fix this. It defers initializing the trendy database until the first time isTrendy() is called. It also changes a bunch of stuff such that we don't call isTrendy while parsing api.php, charsheet.php, and other pages.
 
Top