Bug - Fixed run_combat() got broke if you are not in a combat

[Bale]

The original functionality is that if you were not in a combat, KoLmafia would return the last combat page load when you ran run_combat(). This was a very helpful functionality. I tried it today and did not get the expected result as demonstrated in the following image:

It looks like run_combat() attempted to actually run a combat instead of reporting on the last page load. This came up because I attempted to answer Grabuge's question. Fortunately I decided to try my code before posting it.

 

[lostcalpolydude]

I wonder if run_combat() always tried to run combat, and KoL's redirect to main.php was recognized to not update the returned result. I think that's what I'm seeing, with the call in GenericRequest to FightRequest.updateCombatData() (line 2259) not being reached if fight.php redirects to main.php (line 2040).

Maybe run_combat() could be changed to not send a request if FightRequest.currentRound == 0, I'm not sure if that would have any unwanted results though.

 

[Bale]

Hrm. If that is true, then this is the result of a change to KoL not mafia. I'm not sure if that is really a "bug" then, but what the heck, I'll leave the current tag since the change to expected functionality may still be breaking people's script.

Maybe run_combat() could be changed to not send a request if FightRequest.currentRound == 0, I'm not sure if that would have any unwanted results though.

Alternately you can not update the returned result if you get the "You're not in a fight" response from KoL which we're now seeing.

 

[lostcalpolydude]

I made the change I was looking at in 14650. I'm pretty sure it's fine to do that, and that it should have worked that way to begin with (though the return value might have been different if that use case was anticipated, maybe).

 

[Bale]

It works perfectly. Thanks!

 

[Ezandora]

run_combat() had a hidden feature where you could use it to finish an open choice.php using the default choice setting. I'm not sure if this was intentional, but it was useful - there are choice adventures before fighting Dr. Awkward and Ed the Undying, for instance.

The change in r14650 removes that as a side effect. Is it possible for this behavior to be restored, or is there an alternative available?

If not I can write a similar function in ASH.

 

[Veracity]

I think the CLI command "choice-goal" will do that for you.

 

[Bale]

Veracity sounds unsure, but I will confirm that she is correct. It is helpful.

 

[DoctorRotelle]

choice-goal seemed to fix my gnome arena visit thing. i just have issues using cli commands in ash scripts as they can't be properly verified by the script checker.

 

[Bale]

Neither can the parameter of the visit_url() command, but it is still an essential tool. Perhaps you should make a feature request for an ash command.

• string choice( string url, int opt )
  Visits url and follows the indicated option number. If opt is -1 then it will continue to goal.
  It returns the final page load as a string, as visit_url() does.
  
  
• string choice( int opt )
  As the first, but assumes that the character is already in a choice adventure.
  Returns an empty string if the character was not in a choice adventure.

 

[Veracity]

I seem to recall a request for a run_choice(), a la run_combat(). I guess that would have been the equivalent of choice( -1 ). I think I like the name run_choice() better than choice().

Your suggestions seem good to me. Perhaps make a feature request, so that others who might be interested can comment and refine the syntax?

 

[DoctorRotelle]

can run_combat() just handle the choice.php request by handing it off to the choice-goal code? then nobody has to change their scripts to handle special cases where you can't be sure if you're going into a fight or choice adventure due to location, or what have you.

 

[Veracity]

I am confused. I thought that scripts called run_combat() when they knew they were in fight.php. Or, if you are not in a fight, to get the final page from the fight you just completed.

Why would a script call run_combat() before it knew it was in a fight? Isn't that what adventure() and its ilk are for?

 

[Bale]

I agree with Veracity. Please explain how you end up in a situation where you don't know if you are in a fight.

If I call adventure(), I expect that it will handle both fights and choices equally well. If I was calling run_combat() it would be because I had entered a situation with visit_url() and my script could easily figure out what to do from there.

 

[DoctorRotelle]

First case to consider, scripts re-starting after a mid-fight/choice abort. During the process of script writing, I often forget I'm still in an aborted sequence. Like today, during my breakfast routine, the script aborted (mid arena gnome choice). The case that brought me to this thread was actually visiting the arena for the free gnome item. We have that spiffy choice options in the item tab, but how do we call it and make it work without one of these extra commands or functions (choice-goal or run_combat())? The case where I have all these scripts of other folks' where I don't want to have to wait for them to fail / update before I know how to change their implementation of run_combat(). To me this is a big change to expected behavior. I have 18 scripts that use this function. Of which, I only wrote 1. I am most worried about the trick-or-treat script. And I fear this conversation will be lost in my mind long before we get past 4 days, let alone the 44 until it can be tested. Someone was making noises about the shieldgen script not working, but I'm not in a position to tell if that was caused by run_combat() in that script or something else as I've completed that mission on all my available multi's and can't test it until tomorrow.

 

[Veracity]

I am afraid that I was unable to parse that wall of text. I think you said that you have 18 (unidentified) scripts that use the run_combat "command" (I assume you mean function), but, since they are not your scripts, you have no idea what they are doing with it.

I think that we need to wait until somebody who is the author of a script which uses run_combat chimes in and wants to talk about how their script no longer behaves the way they expect.

 

[Theraze]

How about when you hit Ed the Undrowning, and ashq run_combat() won't start the fight anymore because it doesn't believe it's in a combat, but text main.php will automate the combat for some reason.

 

[Veracity]

Maybe if somebody made a bug report about that, somebody would know to look at it?

 

[Theraze]

Just seemed like that was precisely the example of what was asked for, and it happened today just before my computer logged off due to whatever HP bloatware is leaking memory messing things up. So... nothing useful except for session logs that don't really show much of anything useful.

 

[Bale]

First case to consider, scripts re-starting after a mid-fight/choice abort. During the process of script writing, I often forget I'm still in an aborted sequence. Like today, during my breakfast routine, the script aborted (mid arena gnome choice). The case that brought me to this thread was actually visiting the arena for the free gnome item. We have that spiffy choice options in the item tab, but how do we call it and make it work without one of these extra commands or functions (choice-goal or run_combat())? The case where I have all these scripts of other folks' where I don't want to have to wait for them to fail / update before I know how to change their implementation of run_combat(). To me this is a big change to expected behavior. I have 18 scripts that use this function. Of which, I only wrote 1. I am most worried about the trick-or-treat script. And I fear this conversation will be lost in my mind long before we get past 4 days, let alone the 44 until it can be tested. Someone was making noises about the shieldgen script not working, but I'm not in a position to tell if that was caused by run_combat() in that script or something else as I've completed that mission on all my available multi's and can't test it until tomorrow.

You make this sounds much more terrifying than it actually is. If you got caught in an abort, just open it in your relay browser and look at what it says. The answer to how you can resume it is usually pretty obvious.

And TrickTreat is actually a pretty robustly written script which checks the return value of visit_url() to see if it needs to run_combat() even though it should know the answer in advance. (If it isn't in a fight, it doesn't have any need for run_choice() since the non-combats have no choices.) I promise you that it should be just fine in 44 days.

The case that brought me to this thread was actually visiting the arena for the free gnome item. We have that spiffy choice options in the item tab, but how do we call it and make it work without one of these extra commands or functions (choice-goal or run_combat())?

Well, my loginScript will be changed if run_choice() gets implemented, but I have always done it without choice-goal or run_combat(), like this:

void gnome() {
	// Ensure that you have body parts with the following priority. Otherwise snag the kgnee
	int gnome_part() {
		foreach i in $items[gnomish housemaid's kgnee, gnomish coal miner's lung, gnomish athlete's foot, gnomish swimmer's ears, gnomish tennis elbow]
			if(available_amount(i) < 1) return (to_int(i) - 5767);
		return 4;
	}

	if(have_familiar($familiar[Reagnimated Gnome]) && !($strings[Avatar of Boris, Avatar of Jarlsberg, Avatar of Sneaky Pete] contains my_path())) {
		familiar f = my_familiar();
		try {
			use_familiar($familiar[Reagnimated Gnome]);
			visit_url("arena.php");
			visit_url("choice.php?pwd&whichchoice=597&option="+gnome_part());
			if(equipped_item($slot[familiar]) == $item[none])
				equip($item[gnomish housemaid's kgnee]);
		} finally
			use_familiar(f); // Restore original familiar
	}
}