Bug Player status is not updated after Ascending but before entering the Pearly Gates

[philmasterplus]

(Tested in r20631)

When the player enters the Astral Gash (visit ascend.php?action=ascend&pwd&confirm=on&confirm2=on), but has not clicked The Mini-Pearly Gates yet, KoLmafia does not update the player's status (i.e. class is still the old class, player has non-zero mus/mys/mox, etc.).

> ash visit_url('afterlife.php?action=pearlygates');
Returned: <snipped html source of Pearly Gates>

> status
Name: philmasterplus
Class: Sauceror

Lv: 8
HP: 93 / 93
MP: 50 / 746

Mus: 41 (26), tnp = 18
Mys: 220 (62), tnp = 15
Mox: 45 (25), tnp = 24

Advs: 0
Meat: 62,862

Full: 13 / 15
Drunk: 0 / 14
Spleen: 0 / 15

Restarting KoLmafia or entering the Pearly Gates (visit afterlife.php?action=pearlygates) allows KoLmafia to correctly update the status. In this state, however, there seems to be no way for an ASH/JS script determine whether the player is an Astral Spirit without a server hit/restart. It would be nice if KoLmafia handled this as well.

Note: I've been chaining Grey Goo runs, so I can test this once every two days.

 

[MCroft]

status on/during ascension is a real pain.

What solution would you like to have? Maybe click the mini-pearly gates after ascending?

 

[philmasterplus]

I'm honestly not sure. Auto-entering the Mini-Pearly Gates might work, but I'd prefer another method that doesn't affect the game state.

Reading the code, it seems that visiting charpane.php would cause KoLmafia to correctly update the status. Visiting api.php doesn't help because it checks the value of CharPaneRequest.inValhalla before deciding to check the charpane instead. Since CharPaneRequest.inValhalla is still false at this point, the charpane is not checked at all.

Perhaps ApiRequest could check if we are being redirected to afterlife.php?realworld=1, then decided to use CharPaneRequest instead.

(ofc this could be happening because I am running KoLmafia with --cli option...will have to verify if this happens in the gCLI as well.)

 

[MCroft]

If I were to put in auto Mini-Pearly Gates, I'd make it a preference, so you could script it and I could set it and forget it.

TBH, I don't know of any reason to delay going in if you've ascended. That doesn't mean there isn't a reason to, just that I don't know it.

 

[philmasterplus]

I suppose some people enjoy manually clicking on the gates and reading the welcome message. KoL is about clicking and reading, after all.

(Off-topic: This is one reason I am dissatisfied with Bale's NewLife.ash. It seems to suppress auto-pull messages that you receive after reincarnation, e.g. "You grab your retro superhero cape in case you want to dress like a retro superhero." or "You remember you have a lifetime VIP membership and grab your key!")

In any case, this issue is about KoLmafia getting out of sync due to not recognizing a game state change, rather than a want of automation.

 

[philmasterplus]

I traced the execution flow during an automated jump-into-gash in r20645. To do so, I set up some breakpoints in IntelliJ and ascended by executing the JavaScript statement visitUrl('ascend.php?action=ascend&pwd&confirm=on&confirm2=on').

I discovered that KoLmafia had two places where it could have updated the inValhalla flag (stored in CharPaneRequest.inValhalla), but did not.

First, KoLmafia called AfterLifeRequest.parseResponse() to parse the ascend.php request. See the stack trace from IntelliJ debugger:

parseResponse:71, AfterLifeRequest (net.sourceforge.kolmafia.request)
parseResults:2822, GenericRequest (net.sourceforge.kolmafia.request)
processResponse:2658, GenericRequest (net.sourceforge.kolmafia.request)
retrieveServerReply:2566, GenericRequest (net.sourceforge.kolmafia.request)
retrieveServerReply:2114, GenericRequest (net.sourceforge.kolmafia.request)
externalExecute:1672, GenericRequest (net.sourceforge.kolmafia.request)
execute:1655, GenericRequest (net.sourceforge.kolmafia.request)
run:1365, GenericRequest (net.sourceforge.kolmafia.request)
postRequest:300, RequestThread (net.sourceforge.kolmafia)
postRequest:250, RequestThread (net.sourceforge.kolmafia)
visit_url:2992, RuntimeLibrary (net.sourceforge.kolmafia.textui)
visit_url:2944, RuntimeLibrary (net.sourceforge.kolmafia.textui)

However, the code at line 78 caused it to do nothing:

        // If this is our first visit to the afterlife - we are outside
        // the pearly gates - refresh the charpane
        if ( urlString.equals( "afterlife.php" ) )
        {
            return true;
        }

You can see the HTML response in response-ascend.php.txt, attached at the bottom of this post.

Second, while parsing the ascend.php request, KoLmafia attempted to retrieve api.php to update the player status. I forgot to copy the stack trace from this one, but it's roughly:

updateStatus:110, ApiRequest (net.sourceforge.kolmafia.request)
processResponse:2716, GenericRequest (net.sourceforge.kolmafia.request)
retrieveServerReply:2566, GenericRequest (net.sourceforge.kolmafia.request)
retrieveServerReply:2114, GenericRequest (net.sourceforge.kolmafia.request)
externalExecute:1672, GenericRequest (net.sourceforge.kolmafia.request)
execute:1655, GenericRequest (net.sourceforge.kolmafia.request)
run:1365, GenericRequest (net.sourceforge.kolmafia.request)
postRequest:300, RequestThread (net.sourceforge.kolmafia)
postRequest:250, RequestThread (net.sourceforge.kolmafia)
visit_url:2992, RuntimeLibrary (net.sourceforge.kolmafia.textui)
visit_url:2944, RuntimeLibrary (net.sourceforge.kolmafia.textui)

Here, KoLmafia checks if it should use the charpane instead:

       // api.php doesn't work at all in Valhalla
       if ( CharPaneRequest.inValhalla() )
       {
              ApiRequest.updateStatusFromCharpane();
              return "afterlife.php";
       }

However, since the inValhalla flag has not been set yet, this statement is skipped.

In reality, we have already entered valhalla, and KoL has redirected the api.php to afterlife.php?realworld=1, making our ApiRequest useless.

---

It seems that we have a Catch-22 here.

• KoLmafia can update the inValhalla flag only by updating the player status from charpane.php
• However, since the inValhalla flag has not been updated yet, KoLmafia does not know that it should look at charpane.php instead of api.php

This prevents KoLmafia from updating the character status when auto-ascending. It also prevents forcefully updating the character status via the update status gCLI command.

One possible solution would be to check if KoL redirects an api.php request to afterlife.php?realworld=1, and handle it appropriately:

diff --git a/src/net/sourceforge/kolmafia/request/ApiRequest.java b/src/net/sourceforge/kolmafia/request/ApiRequest.java
--- a/src/net/sourceforge/kolmafia/request/ApiRequest.java    (revision 20645)
+++ b/src/net/sourceforge/kolmafia/request/ApiRequest.java    (date 1613790013689)
@@ -126,6 +126,13 @@
         }
         ApiRequest.INSTANCE.silent = silent;
         ApiRequest.INSTANCE.run();
+        // Fall back to parsing charpane.php if KoL redirects us to afterlife.php.
+        // This may happen if the user entered the gash by calling visit_url(), which does not update the
+        // inValhalla flag.
+        if ( ApiRequest.INSTANCE.redirectLocation.contains( "afterlife.php?realworld=1" ) )
+        {
+            return ApiRequest.updateStatusFromCharpane();
+        }
         return ApiRequest.INSTANCE.redirectLocation;
     }

(patch file attached below)

 

[philmasterplus]

Ascended again. I verified that, after reaching the Pearly Gates, manually calling visitUrl("charpane.php") did not set my class to "Astral Spirit". (Although it did reset my stats to 1/1/1). It seems that the only workaround for now is logging out and back in, or manually entering the Pearly Gates.

Hoping the patch above is accepted.