Feature - Implemented postPrismScript

[lostcalpolydude]

As suggested here, it would be nice if a script could automatically be run when you free the king. I believe that in GenericRequest,

		if ( urlString.startsWith( "lair6.php" ) && urlString.indexOf( "place=6" ) != -1 )
		{
			KoLCharacter.setHardcore( false );
			KoLCharacter.setConsumptionRestriction( AscensionSnapshot.NOPATH );
		}

would just need

			KoLmafiaCLI.DEFAULT_SHELL.executeLine( Preferences.getString( "postPrismScript" ) );

added, and the setting added to defaults.txt.

 

[Bale]

I would use this.

 

[Weatherboy]

Oh, I would too.

 

[Fred Nefler]

How about a pre-prism script? It could be used to look for trophies that have to be bought before freeing the king, or for autoselling your entire inventory when in fist and you don't have the donation trophy.

 

[lostcalpolydude]

What would trigger it?

 

[Fred Nefler]

Executed when you click the prism, but before mafia sends the request to break the prism to the server.

 

[Bale]

Well, I wouldn't use that. It seems kinda niche. If I was working on one of those two trophies I'd bloody well know that I was doing so.

 

[Grotfang]

it would be nice if a script could automatically be run when you free the king.

The text you get in response to freeing the king is a once-per-ascension event. Could the same thing not be produced with a relay override script?

 

[lostcalpolydude]

If my suggested code change has any chance of working, then mafia uses the URL for the page rather than the page contents to recognize when you free the king.

 

[Grotfang]

If my suggested code change has any chance of working, then mafia uses the URL for the page rather than the page contents to recognize when you free the king.

That's true, and responds to my question. I should have phrased it better. I understand what the differences in processing would be. Why wouldn't a relay override for lair6.php that checked for the prism-breaking text have the exact same result as far as the user is concerned (albeit via a different mechanism).

 

[lostcalpolydude]

Oh, I completely misread your question. I thought you were wondering whether a relay override script would prevent this from working.

I guess there's no reason that a relay override script can't be used, so this could be rejected. I will be sticking with the change I suggested in the first post since one more line of code seems cleaner than another file in /relay.

 

[Grotfang]

Oh, I completely misread your question. I thought you were wondering whether a relay override script would prevent this from working.

Not a problem. As I said, I should have phrased my question more clearly

I guess there's no reason that a relay override script can't be used, so this could be rejected. I will be sticking with the change I suggested in the first post since one more line of code seems cleaner than another file in /relay.

I'll leave it for someone else to weigh in on. If there is a developer who thinks this deserves inclusion then I have no issue with it being included. My thinking is simply that there is a risk of over-complicating things by adding script options that can be produced via the native functionality. If a relay script could be used creatively here, much like Bale's woods.ash, then I would be happier sticking with that.

 

[lostcalpolydude]

From another thread:

This is a good idea. Please make a Feature Request.

So I will bump the existing one instead. kingLiberatedScript sounds like a better name anyway.

 

[Veracity]

Revision 10250 changes how we detect when you free the king.

Previously, when you are about to submit the URL, we cleared hardcore and path first.
When the response to the URL came back, we did nothing special.
However, if you happened to have submitted it in the Relay Browser, we noticed, and called kingLiberated() to set the setting and manipulate a lot of internal state.

If you happened to submit it in a script, say, none of that processing happened. And, I notice that kingLiberated() had special checks to see if you had been in in Hardcore before, which could not have worked, since Hardcore was cleared before the URL was submitted.

I changed it such that kingLiberated() is called AFTER the URL has been submitted and has returned a response. We no longer clear Hardcore and Path before submitting the URL. Instead, we clear them after in kingLiberated().

As its final action, kingLiberated() calls a user supplied kingLiberatedScript.

I hope this works as you wish. I'll see for myself, tomorrow.