Feature Add +5 <item> goal when an item drop familiar is equipped

[KeltiThePastaQueen]

Title says it all, really. I think this would be kind of handy as a goal no matter what zone one is in.

 

[Veracity]

I've wanted this myself. It should actually be +(5 - # of drops already today).

 

[slyz]

I use this alias:

[B]famdrop[/B] => ashq string d; string n;string f = my_familiar().to_string();switch(f) {case "Li'l Xenomorph":d="transponder";n="transporter transponder";break;case "Baby Sandworm":d="agua";n="agua de vida";break;case "Green Pixie":d="absinthe";n="tiny bottle of absinthe";break;case "Llama Lama":d="gong";n="llama gong";break;case "Astral Badger":d="astral";n="astral mushroom";break;case "Rogue Program":d="token";n="game grid token";break;default: return false;}int num=5-get_property("_"+d+"Drops").to_int();if(num>0)cli_execute("goals add "+num+" "+n);

 

[Theraze]

Having this as an automatic goal... wouldn't that screw up if you're trying to use them while completing another condition? For example, if you're trying to get a filth drone gland and it makes an automatic goal of 5 drops, won't that keep adventuring not until you have the gland, but until all conditions have been met?

 

[Veracity]

You are the first person to use "automatic" with "goal".

Adventure areas can have multiple default goals, although some have none. The suggestion, as I envision it, is to automatically add an additional goal to every area, which you can select or not, as you choose, from the dropdown list of default goals.

 

[Camber]

Here is a thought, and pardon my lack of knowledge of what is possible, but could the goal choice be dynamic and use the logic of slyz' alias to read your familiar, and if it has drops avail, add the goal to the list? or even check which familiars you have that do drops and add goals for each one?

 

[DoctorRotelle]

I actually fielded this question in /hardcore today. I have to say a resounding "NO" to this request until such a time as we have "or" options for goals. Having this issue AND a terrible memory, I use a BBS to handle familiar switching since I like my goals for my bounty hunt (etc) to not get overwritten by un-related familiar switching preferences:
http://whovian.zapto.org/kol/scripts/fam_switch.ash

Someone commented on doing this in their moods, but I didn't get an example of usage, so I didn't really understand how to do it...

Some notable thingies about my (and other) BBS scripts:
1) This conflicts with familiar equipping code in the case where I'd prefer to equip nothing, then a bag of confections on a mimic, or other non-IotM gear within my script. Something similar happens with the mini-hipster since it goes from nothing to an auto-acquired/equipped item. (after concluding adventuring in a location, the mafia code would kick in and change my gear, this gets annoying when farming !pipes. just abort, rerun the script or change the gear manually, then resume and all will be fine. It is the "nothing" at the start of an adventure run causing this code to fire after the adventure run concludes in each location.)

2) I use some custom combat script switching which is coded into this script (stoppers and static). Also, this has nothing to do with http://kolmafia.us/showthread.php?1240-Best-Between-Battle-Script-Ever-formerly-AutoMCD but you might be interested if you've gotten this far and want more of that kind of stuff to be automagic.

3) Z and I both require use of the betweenBattleScript variable for our scripts to be "active" during adventuring in any adventure location. These scripts don't fire when playing via the relay browser (by hand).

If folks have any other ingenious ways of handling familiar switching, please share! I'd love to learn what's being done by others.
Have fun folks!!
-=DoctorRotelle

 

[slyz]

I use this simple betweenBattleScript to cycle through item-dropping familiars until they all dropped numdrops items (simply edit the variable at the beginning of the script).

Once you have all the drops, it sets betweenBattleScript to "" and aborts.

I use this in aftercore, and all my familiars have their specific equipment equipped. One problem I have is that if I had familiar A out when I start automating turns, and the automation stops with familiar B, Mafia will try to equip familiar A's equipment on familiar B. I never really looked into it, but adding a cli_execute("checkpoint"); didn't solve this. It never was enough of a bother to actually make a bug report though ^^

 

[DoctorRotelle]

One problem I have is that if I had familiar A out when I start automating turns, and the automation stops with familiar B, Mafia will try to equip familiar A's equipment on familiar B.

I can verify this happens with my script. I lock my familiar equipment at login. Since the mayflower bouquet is removed when the script reaches my stocking mimic, there's room for confusion. I also switch back to a green pixie if my script is no longer in a wormwood region, which is when I tend to see this error. (note: that's a mimic -> green pixie switch caused by another script switching adventure locations)

-=DoctorRotelle

 

[Theraze]

As long as Camber's idea of only showing the goal if it's actually possible, that would make this as a possible choice a benefit in my opinion. However, if it's a generic "5 familiar item drops" goal, I'd see that as a negative change.

Regarding automatic, I took that the request was that if you have an item drop familiar equipped, add the (active) goal of +5 item drops. Not to have a goal based on parsing the _<item>drop variable available as an option.

Whether or not it's possible to make a dynamic goal, it should be possible to make a condition that, if you have a dropping familiar, check the variable.

For that matter, would it make sense to have our goals have some sanity checking included? I've accidentally gone to the wrong zone a few times because KoLmafia uses a slightly different name than KoL uses, and blown through most of a day's turns trying to get a specific drop for the sorc tower, only to realize that the item it's searching for will never be met... Where it applies to this is, if you set 5 item drops as your goal and your familiar doesn't have any, that would make you expend all your turns or at least, as many as you've given as possible for this adventure-set.

And yes, I've experienced the familiar equipment bug. Generally with having the code trying to equip one familiar's special equipment on another.

 

[Fluxxdog]

Mafia will try to equip familiar A's equipment on familiar B. I never really looked into it, but adding a cli_execute("checkpoint"); didn't solve this. It never was enough of a bother to actually make a bug report though ^^

Yeah, any time you have a piece of equipment intentionally permanently changed while automatically adventuring, it will always attempt to change it back when the automation stops, regardless of whether bBS or mood is used to call it, even if you don't have the equipment anymore. Very annoying when you morph stinky cheese mid automation.

 

[DoctorRotelle]

I've adjusted my version of the checkpoint command as follows:

package net.sourceforge.kolmafia.textui.command;

import net.sourceforge.kolmafia.KoLmafia;
import net.sourceforge.kolmafia.RequestThread;
import net.sourceforge.kolmafia.SpecialOutfit;

public class OutfitCheckpointCommand
	extends AbstractCommand
{
	public OutfitCheckpointCommand()
	{
		this.usage = " [clear] - remembers [or forgets] current equipment, use \"outfit checkpoint\" to restore.";
	}

	public void run( final String cmd, String parameters )
	{
		parameters = parameters.trim();
		if ( !parameters.equals( "clear" ) )
		{
			SpecialOutfit.createExplicitCheckpoint();
			KoLmafia.updateDisplay( "Internal checkpoint created." );
			RequestThread.enableDisplayIfSequenceComplete();
			return;
		}
		else if ( parameters.equals( "clear" ))
		{
			SpecialOutfit.forgetCheckpoints();
			KoLmafia.updateDisplay( "Checkpoints cleared." );
		}
	}
}

If anyone would like to try out this code, I'd be willing to commit it if others found it useful for their scripts. It adds the "checkpoint clear" version of the checkpoint command to forget mafia's implicit checkpoint and/or explicit checkpoint created within a script. I've noticed the error of trying to create a checkpoint (explicit) and understand that it doesn't overwrite the mafia generated checkpoint (implicit), as seen in slyz's post earlier in this thread.

I've been using this in my BBS which changes my gear under certain conditions independent of other activities. This is similar to the familiar equipment switching stuff, but seems to only apply to non-familiar gear. Maybe someone out there has some more ideas to further this concept into general usability and tie-in familiar gear. Use within a mood context is untested and needs feedback from those that use such a setup.

-=DoctorRotelle

 

[slyz]

It works =)

I have a bBS that chooses my familiar. At the end of a bout of automation, if the current familiar wasn't the same as the first one, Mafia would try to equip the first familiar's equipment when restoring the implicit checkpoint. Since familiar equips are part of the checkpoint, adding a cli_execute("checkpoint clear") after each familiar switch solved this problem.

Thanks!

 

[Fluxxdog]

Basically, "checkpoint clear" is to circumvent the built-in equipment swapping when auto-adventuring stops and re-equips items that you had before the start. I like it! Wish I could test it myself as that swapping breaks the functionality of several of my scripts, especially my stinky cheese.

... hyphen hyphen hyphen!

 

[Bale]

So, this allows me to swap equipment in a mood if I use checkpoint clear so that mafia cannot switch back to the gear at the start of the mood?

I've got a question. What would happen if the checkpoint existed for a good reason, such as currently wearing the KGE suit to purchase seltzer? It would be more helpful if I could checkpoint_equip() to change the checkpoint information so that mafia would switch in my preferred gear during checkpoint restore. As this stands I suspect it will cause as much trouble as it will solve.

Is my preferred method of checkpoint control possible?

 

[DoctorRotelle]

What would happen if the checkpoint existed for a good reason, such as currently wearing the KGE suit to purchase seltzer?

Great question! I had to research to find an answer. I found this in the AcquireCommand.java:

			SpecialOutfit.createImplicitCheckpoint();
			InventoryManager.retrieveItem( item, false );
			SpecialOutfit.restoreImplicitCheckpoint();

This should mean there's a new checkpoint created and restored around the request for any NPC store purchase.

My "hack" only exposes the forgetCheckpoints() function which has existed since build 7313. The code block and notes look like this:

	/**
	 * Method to remove all active checkpoints, in cases where restoring the original
	 * outfit is undesirable (currently, Fernswarthy's Basement).
	 */

	public static final void forgetCheckpoints()
	{
		SpecialOutfit.implicitPoints.clear();
		SpecialOutfit.explicitPoints.clear();
	}

I honestly don't know why or how the code works, it just seems to do the trick here. I wouldn't have the first clue as to how one would create and implement the checkpoint_equip() idea, nor the proper context one would use it in since you typically only have access to explicit checkpoints and the implicit ones were causing the item swapping issues. (You may notice all my code is borrowed from other parts of the project and adjusted slightly to add "more of the same" functionality.)

I pray folks will let me know if they see any issues with this! I don't want to commit this code without a proper test. I even sent kmails to folks I thought this might impact in hopes of getting their testing support. I can't see how it would break existing scripts, but I don't have the experience of this group. I'm depending on those that might find this useful to guide me further. I can't be sure this fixes everyone's issues within their contexts of usage. TBH, I'd like some suggestions for the "help checkpoint" output too. I've never been good with that "technical english" stuff.

checkpoint [clear] - remembers [or forgets] current equipment, use "outfit checkpoint" to restore.

Thanks for everyone's help!
-=DoctorRotelle

 

[Bale]

This should mean there's a new checkpoint created and restored around the request for any NPC store purchase.

That should mean that I could forget_checkpoint() without worry that I'll get stuck in the KGE. It sounds good to me now.

 

[DoctorRotelle]

To handle clearing checkpoints for these situations:
Committed revision 8842.

 

[bordemstirs]

familiar based goals

I was wondering if it would be feasible to add goals (not sure what the appropriate term would be, definitely not "default goal" but I suppose "pre-programmed goal" works) based on the current active familiar to the goals drop-down?

So if I have, say, my Baby Sandworm equipped, the goal "+5 agua de vida" (or less, depending on how many drops remain for the day) would be in the list.

Seems like it'd save me a lot of hassle when cycling through my Content familiars in aftercore.

 

[roippi]

I think this would require a bit of refactoring for default goals. They're pretty much all hardcoded from what I understand.