Bug - Fixed Extraneous encounter logged in gCLI on login

Veracity

Veracity

Developer
Staff member
Code: 
Refreshing session data...
Synchronizing moon data...
Loading character status...
Retrieving character data...

[119291] The Castle in the Clouds in the Sky (Top Floor)
Updating inventory...
Examining Meat in closet..
Updating closet...
Retrieving quest data...
Retrieving familiar data...
Familiar data retrieved.
Retrieving campground data...
Session data refreshed.
I am quite sure that it didn't actually visit that location while logging in, but it visited some page that KoLmafia decided to log that way.

Doing "Refresh Session" from the Tools menu does this:

Code: 
Refreshing session data...
Synchronizing moon data...
Loading character status...
Retrieving character data...
Updating inventory...
Examining Meat in closet...
Updating closet...
Retrieving quest data...
Retrieving familiar data...
Familiar data retrieved.
Retrieving campground data...
Session data refreshed.
 
Bale

Bale

Minion
Confirmed. The following was in my CLI at first login after rollover:

Code: 
Installing default certificate validation...
Validating login server (www.kingdomofloathing.com)...
Using data override: data/mallprices.txt
87 players online.
Sending login request...
Initializing session for bale...
Refreshing session data...
Synchronizing moon data...
Loading character status...
Retrieving character data...

[816] The Hole in the Sky
Updating inventory...
Examining Meat in closet...
Updating closet...
Retrieving quest data...
Retrieving familiar data...
Familiar data retrieved.
Retrieving campground data...

My last adventure before rollover was in The Hole in the Sky. My next adventure is the actual number [816].
 
Last edited:
lostcalpolydude

lostcalpolydude

Developer
Staff member
From a debug log, it comes after the HTML from charsheet.php is logged, but before "Processing results..." is printed. I have no idea why that is logged, but initializing KoLAdventure.locationLogged as true seems to fix the issue. I expect that the initial logging sets it to true anyway.
 
Veracity

Veracity

Developer
Staff member
The last encounter from api (or charpane) now sets KoLAdventure.lastLocationName. Since, as lost says, KoLAdventure.locationLogged was false, that inspires AdventureRequest.registerEncounter to "finish" logging the location before trying to register the encounter.

It shouldn't need to "finish" logging it if it wasn't an adventure to begin with. So, for now, I made KoLAdventure.recordToSession set KoLAdventure.locationLogged to true if it wasn't even an adventure.

This whole adventure/encounter logging stuff is "tricky" and fragile. It doesn't want to log the adventure when you submit the URL, since it can fail for many reasons, so it logs it after it gets the result back - which can be after a redirect to fight.php or choice.php, at least - and also looks into the result text to pull out the encounter. I like the way the logging ends up looking, but, wow, it would be nice if it could do it in a more straightforward way.

If I had more time, I'd give it some hard thought and see if it could be simplified.

Revision 14058 attempts to solve this particular issue, at least. I hope there are not unexpected side effects, given the "trickiness" of the code...
 
lostcalpolydude

lostcalpolydude

Developer
Staff member
Locations aren't being added to KoLConstants.adventureList now (visible in the Visited Locations frame or with the "locations" command).
 
Veracity

Veracity

Developer
Staff member
Revision 14060 comments out that commit.
I'll look at another solution another time.
 
M

Magus_Prime

Well-known member
That seems to have fixed the problem for me: based on a single login as a data point. :) Given that it happened every time I logged in I think it's a good data point.
 
Bale

Bale

Minion
I also am getting a good experience as a result of the update. Nobody has yet noticed any horrific side effects from the fix this time so I'll mark this bug fixed!
 
You must log in or register to reply here.
Top