Rinn's Quest Scripts

I don't believe the screambat will show up that often. The batrat area has the best drop rate, but it's always worth burning some turns on beanbats until you have an enchanted bean since you need it later anyway, then going back to the batrat area.
 
Anyways, updated the Level 4 script and uploaded the newest version to dropbox. Should work. Haven't tested it yet. Does also get the pine-fresh air freshener for stench resistance if you don't have it yet, and runs a maximize 1 max stench resistance, -tie so it should work if you don't have it yet.
 
The screambat appears every 8 turns guaranteed. Regular as clockwork. That should be enough to figure out. Just run the adventures in 8 turn batches and you should know how many sonar in a biscuits you'd need to finish the job.
 
Hmm... so is best efficiency doing beanbat for the extra free beans, or batrat for the faster sonars?
 
Guano junction for the first sonar, batrat/ratbats for the second one (due to the higher drop rate), beanbats until you get an enchanted bean, then back to batrat/ratbat if you still need the third sonar.
 
I don't know if it would help, but here's a snippet from my own that I use for bat hole status:
PHP:
//Level 4
case $location[Bat Hole Entryway]:
	if(been_there(address)) return tough_test(13);
	else if(my_level()>=4 && tough_test(13)){ //Am I high enough level AND tough enough?
		council(); unlock_area(address); return true;} break;
case $location[Guano Junction]: //Need to have Guano Junction open AND stech protection
	if(elemental_resistance($element[stench])>=10 && location_available("Bat Hole Entryway"))
		return tough_test(13); break;
case $location[Batrat and Ratbat Burrow]:
case $location[Beanbat Chamber]:
case $location[Boss Bat's Lair]:
	if(address==$location[Boss Bat's Lair] && quest_check("LV4council")) return false;
	else if(been_there(address)) return tough_test(13);
	else if(tough_test(13)){  //Why check if I can't go in?
		int batse=to_int(excise(visit_url("bathole.php"),"bathole_",".gif"));
		if(batse==1){
			batse+=to_int(use(1,$item[sonar-in-a-biscuit]));}
		if(batse==2){
			unlock_area($location[Batrat and Ratbat Burrow]);
			batse+=to_int(use(1,$item[sonar-in-a-biscuit]));}
		if(batse==3){
			unlock_area($location[Batrat and Ratbat Burrow]);
			unlock_area($location[Beanbat Chamber]);
			batse+=to_int(use(1,$item[sonar-in-a-biscuit]));}
		if(batse>=4){
			unlock_area($location[Batrat and Ratbat Burrow]);
			unlock_area($location[Beanbat Chamber]);
			unlock_area($location[Boss Bat's Lair]); }
		if(address==$location[Boss Bat's Lair] && quest_check("LV4council")) return false;
		else return been_there(address);} break;
It has to check the URL, but until mafia has a way of determining Bat Hole status, this has been my best option. It uses some zlib, but I think you get the idea.
 
Yeah... think I have it properly checking for scream/sonar collection. As it stands, I'll probably leave it collecting beans... can always cook them into burritos, and it's useful to have for the nemesis quests if you're running them as well.
 
Ran through Level 11 successfully... took forever to get the ILY book, but that could just be RNG hate or one of those lovely delay counters.

Added this to any snarfblatted adventure today:
PHP:
 if (my_hp() / my_maxhp() < get_property(hpAutoRecovery))
  restore_hp((my_maxhp() * get_property(hpAutoRecoveryTarget)) - my_hp());

If I'm working through it properly, it should check if you're below the recovery line, and if so, heal you up to the recovery target. If possible.

This should reduce how often I die unlocking the temple early on when I don't have enough moxie to have it be fully safe yet. :)

Edit: The above snippet is bad, as it will try to recover you to the difference between your current level and your target, instead of recovering you to your target. If you want to recalculate and be mistrustful, you should do the following:
PHP:
 if (my_hp() / my_maxhp() < get_property(hpAutoRecovery))
  restore_hp(my_maxhp() * get_property(hpAutoRecoveryTarget));
On slyz's suggestion, I've converted them to do the following which should do exactly the same:
PHP:
 if (my_hp() / my_maxhp() < get_property(hpAutoRecovery))
  restore_hp();
 
Last edited:
I might be wrong, but I think s simply calling:
PHP:
restore_hp();
will restore you HP according to your settings.

Oh, and the int passed to restore_hp() is the target HP, not the amount you want to restore.

At least that's what the wiki says =)
 
Depends... not passing anything means you're passing a value of 0, which means that it should use the automatic settings.

You are right that the value passed is the desired level though, not the amount desired. Stupid multiple meanings of 'desired' in my brain. :)

I pondered doing the 0 passing, and decided to overcomplicate things. I think I'll leave the check to see if health has dropped enough for restoration, but convert the rest to just do a straight restore_hp()...
 
Huh... surprise.
Function 'restore_hp( )' undefined. This script may require a more recent version of KoLmafia and/or its supporting scripts. (level 2.ash, line 6)

Guess you can't actually do that. Works in gCLI, doesn't work in ASH. So doing the following now...
PHP:
 if (my_hp() / my_maxhp() < to_int(get_property("hpAutoRecovery")))
  restore_hp(0);
 
Why are you surprised? If a function in ash requires a parameter it will never work without that parameter. All functions work that way in ash, although some are defined with varying number of possible parameters.

Works in gCLI, doesn't work in ASH.

Actually it does not work in the gCLI. If you tell it restore hp it will attempt to restore to your current hp plus 1. that ensures that it will restore even if the restoration threshold is less than your current HP. Then mafia or UR will bump that up to your restoration target if the target is larger than requested HP.

That's why I use ashq restore_hp(0) in the gCLI. I have an alias for that.
 
Why are you surprised? If a function in ash requires a parameter it will never work without that parameter. All functions work that way in ash, although some are defined with varying number of possible parameters.
I'm just surprised because usually, when someone suggests a function, it works as they suggest, no modification needed. ;)

Actually it does not work in the gCLI. If you tell it restore hp it will attempt to restore to your current hp plus 1. that ensures that it will restore even if the restoration threshold is less than your current HP. Then mafia or UR will bump that up to your restoration target if the target is larger than requested HP.

That's why I use ashq restore_hp(0) in the gCLI. I have an alias for that.

Oh? In RecoverCommand where it says
PHP:
  if ( parameters.equalsIgnoreCase( "hp" ) || parameters.equalsIgnoreCase( "health" ) || parameters.equalsIgnoreCase( "both" ) )
  {
   target = (int) ( Preferences.getFloat( "hpAutoRecoveryTarget" ) * KoLCharacter.getMaximumHP() );
   RecoveryManager.recoverHP( Math.max( target, KoLCharacter.getCurrentHP() + 1 ) );
  }
  if ( parameters.equalsIgnoreCase( "mp" ) || parameters.equalsIgnoreCase( "mana" ) || parameters.equalsIgnoreCase( "both" ) )
  {
   target = (int) ( Preferences.getFloat( "mpAutoRecoveryTarget" ) * KoLCharacter.getMaximumMP() );
   RecoveryManager.recoverMP( Math.max( target, KoLCharacter.getCurrentMP() + 1 ) );
  }
would seem to suggest that it does heal up to either your target, or +1 from your current, whichever is higher... So no, it's not attempting to restore to your current hp +1... it's attempting to hit your target level, but if you're already above that, it'll do the cheapest restoration to get +1 point higher.

Or am I misunderstanding that? :)

Not saying that the ashq restore_hp(0) is a bad idea. That should be about the only way to get it to actually respect your settings and stop when it's passed the line, no matter how many times you run it. For that matter, an ashq restore_hp(my_maxhp()) wouldn't be a bad one for running the shadow and other such edge cases where you just need a bit of extra attention. :)
 
Or am I misunderstanding that? :)

I think that is exactly what I said in slightly different words, so you definitely understand that.

For that matter, an ashq restore_hp(my_maxhp()) wouldn't be a bad one for running the shadow and other such edge cases where you just need a bit of extra attention. :)

Actually I use restore_hp(9999) for the shadow, but your way works also. :D It's just less typing my way.

Code:
alias rhp => ashq restore_hp(%%)

alias rmp => ashq restore_mp(%%)
 
Last edited:
Actually it does not work in the gCLI. If you tell it restore hp it will attempt to restore to your current hp plus 1. that ensures that it will restore even if the restoration threshold is less than your current HP.

Eh, I took that to mean that it always aims to cure 1 hp, not that it aims for target or +1 hp, whichever is higher.
 
Yeah, but it's not that... it's that it always starts at that in the first place.

Maybe it's just a different way of looking at things, but when your initial "where do I restore to?" question comes in a Math.max, I don't see it as ever requesting the lower in a bumpable way. The lower is simply ignored.

But I guess that's just a matter of how do you look at priorities and calculations. :)
 
The difference is that I could have written UR to behave differently from mafia's restoration. UR is called with my_hp() plus 1, not max(target, HP+1) and I could simply elect to restore to HP+1 instead.
 
Back
Top