Bug - Fixed API.php visit in valhalla

fredg1

Member
I've been using my script to automate valhalla for my Community Service loops, and I'm getting this:

Code:
e nsContestants3 changed from 0 to -1
Preference relayCounters changed from 712:Semirare window begin loc=*:lparen.gif:752:Semirare window end loc=*:rparen.gif to

> debug on

> call scripts\hccs.ash

Welcome to Valhalla!
Preference bankedKarma changed from 820 to 1031
Unhandled redirect to afterlife.php?realworld=1

Buy astral pet sweater for 10 Karma (initial balance = 1031)
Preference bankedKarma changed from 1031 to 1021
Unhandled redirect to afterlife.php?realworld=1

Buy astral six-pack for 1 Karma (initial balance = 1021)
Preference bankedKarma changed from 1021 to 1020
Unhandled redirect to afterlife.php?realworld=1

Ascend as a Hardcore Male Sauceror under the Vole sign on a Community Service path, banking 1020 Karma.
Loading character status...

I got a debug log out of it, but I managed to understand what happens (if you really want to inflict this on yourself... here it is... View attachment DEBUG_20201007 realword=1 kinda trimmed for sanity.txt )

What I saw was that after every visit_url(), mafia tries to visit API.php. There's no API.php in valhalla, so it fails.

I don't know where that visit is initiated, but the fix for this would simply be to not do it when you're still in valhalla, or at least understand that a redirect to afterlife.php simply means that you're an astral spirit.


Also, it's not super consistent, but there are times where I catch a glimpse of "Unhandled redirect to main.php?noobmessage=true" , too. May or may not be linked to this?


ALSO also, is there/could there be a way to manually do the "on ascension" processes?
Sometimes, they fail (because of me doing things in the relay browser while not noticing that they were still running in the background), and I end up with things such as free pulls not being pulled, the spookyraven letter not being read, and so on...

If I know that I messed up the on-ascension process, any way to re-initiate it?
 

fronobulax

Developer
Staff member
I'm a little confused by the "on ascension" processes. What do you want that cannot be done by manually revisiting the gash or running the pre-ascension script?

The general problem of a script running asynchronously while something else is happening in the relay browser is going to have to be dealt with by someone smarter and more motivated than me. My past experiments ended up with thread deadlocks or a KolMafia that was essentially single threaded with the subsequent in crease in wall clock time.
 

Veracity

Developer
Staff member
I've been using my script to automate valhalla
This is the first I've heard of anybody using a script for Valhalla. We never considered that anyone would do that.
Which probably makes this a Feature request: "Support scripting in Valhalla".

KoLmafia calls api.php for every request which is not a RelayRequest - i.e., is generated by KoLmafia itself via the GUI, CLI, or ASH script - in which KoL says "refresh the charpane".
The Compact Side Pane's "Refresh Status" button also does that. Lots of places call ApiRequest.updateStatus().
This is the first I heard that api.php doesn't work in Valhalla.

Code:
	public synchronized static String updateStatus( final boolean silent )
	{
		// If in limitmode, Noobcore, PokeFam, and Disguises Delimit API status doesn't contain the full information, so use Character Pane instead
		if ( KoLCharacter.getLimitmode() != null || KoLCharacter.inNoobcore() || KoLCharacter.inPokefam() || KoLCharacter.inDisguise() )
		{
			ApiRequest.CHARPANE.run();
			return ApiRequest.CHARPANE.redirectLocation;
		}
		ApiRequest.INSTANCE.silent = silent;
		ApiRequest.INSTANCE.run();
		return ApiRequest.INSTANCE.redirectLocation;
	}
Apparently "being in valhalla" is another reason to do the charpane instead...

Also, it's not super consistent, but there are times where I catch a glimpse of "Unhandled redirect to main.php?noobmessage=true" , too. May or may not be linked to this?
No.

ALSO also, is there/could there be a way to manually do the "on ascension" processes?
Sometimes, they fail (because of me doing things in the relay browser while not noticing that they were still running in the background), and I end up with things such as free pulls not being pulled, the spookyraven letter not being read, and so on...
Don't do that. This is ValhallaManager.postAscension, which resets a lot of state, pulls 3 free pull items (VIP key, cursed microwave, cursed pony keg), runs YOUR postAscensionScript, visits your clan to update available VIP lounge items, resets daily deeds, and on and on.

If I know that I messed up the on-ascension process, any way to re-initiate it?
No. Seriously, don't do that.

Perhaps there could be a way to have the relay browser refresh a page saying that it is "automating", while lengthy processes happen. I have a length kingLiberatedScript, for example, and when I click the prism, KoL seems to freeze for a long time while it runs. Doing postAscension processing - which includes your postAscensionScript - also makes KoLmafia seem to freeze for a while.

Those are completely orthogonal to "api.php in Valhalla", so you've pretty much glommed multiple bug/features into one thread, here.
 

fredg1

Member
1st test: it pooped me out of valhalla without doing any postValhalla process, saying it got an unhandled redirect. Gonna retry today to see if it wasn't just a coincidence.
 

fredg1

Member
there's lots of reports of ascension causing problems; 20464 and 20465 should be reverted. I have 20468, and will use it when ascending to give a debug log of exactly what happens, but until then, we should revert the changes, since they are visibly bringing a problem.
 

Malibu Stacey

Active member
there's lots of reports of ascension causing problems; 20464 and 20465 should be reverted. I have 20468, and will use it when ascending to give a debug log of exactly what happens, but until then, we should revert the changes, since they are visibly bringing a problem.

The issues fred is referring to is this

Code:
Ascend as a Hardcore Male Seal Clubber under the Vole sign on the Standard path, banking 31 Karma.
Preference currentMood changed from default to apathetic
Preference hpAutoRecovery changed from 0.5 to -0.05
Preference mpAutoRecovery changed from 0.1 to -0.05


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
	   Beginning New Ascension	     
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Ascension #0:
Softcore No-Path Astral Spirit
None




=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


Preference relayCounters changed from  to 70:Semirare window begin:lparen.gif
Preference relayCounters changed from 70:Semirare window begin:lparen.gif to 70:Semirare window begin:lparen.gif:80:Semirare window end loc=*:rparen.gif

main.php?refreshtop=true&noobmessage=true

It also tries to use the Spookyraven telegram before it's even arrived. This was in 20468 today but I had the exact same issue yesterday in 20466 (only difference is that it was a Pastamancer, everything else is the same).

I am going to downgrade to 20463 and will re-test tomorrow (assuming autoscend manages a 2 day run again).
 
Last edited:

Veracity

Developer
Staff member
there's lots of reports of ascension causing problems
I look forward to seeing those people reporting here and *gasp* maybe even providing a DEBUG log.
Whining on some other platform will not result in a fix.

If this is a widely known problem - except on this forum, it appears - then ANYBODY who uses this program could trivially turn on the DEBUG log before ascending and off afterwords, post the log here, and expect me to look at it forthwith. But complaining somewhere else and NOT doing that is ineffective. Passive aggressive, even.

20464 and 20465 should be reverted
I'm not going to do that, since that will guarantee that I will not get a DEBUG log. I can't stop somebody else from doing that, but if they do so, I throw up my hands, and it will become their responsibility to fix the issue, if the info I requested eventually comes in.

I have 20468, and will use it when ascending to give a debug log of exactly what happens, but until then, we should revert the changes, since they are visibly bringing a problem.
That's nice. Or, perhaps, any of the myriad other affected people will provide a DEBUG log sooner.
 
Last edited:
Top