Turnip check?

As Hola said, "if Mafia tracked this it'd be a great proxy record", but since it isn't (at the moment at least) it cannot be added at this point.
 
I understand that, but I don't remember seeing any proxy record value that wasn't constant so I was asking if a state sensitive proxy record value was even possible currently.
 
Consider "familiar.charges" - the "charges" your familiar has (whatever that means for a given familiar) at the time you ask for the value. KoLmafia calls a function to generate the value afresh every time for every proxy value.
 
Does mafia know the difference between the desert hydrated and unhydrated to support the ops original use for returning 2 adventures spent on the hydrated desert without an active effect of ultra hydrated?

It does know the difference, but this is further complicated by the fact that a second turn is only spent if your last turn was hydrated and now it would be an unhydrated turn.
 
Which is why I threw out what it would cost for 10 desert turnips as an awesome possibility. If mafia actually knew it, would make finding best adventure costs really confusing. But sort of good. :)

If someone actually wrote a comparison for best consumption v. fishy consumption, etc.
 
Which is why I threw out what it would cost for 10 desert turnips as an awesome possibility. If mafia actually knew it, would make finding best adventure costs really confusing. But sort of good. :)

When considering ranges, the problem becomes more convoluted.

Consider a theoretical location where there's a 50% chance of a choice adventure that you can skip, the other 50% is a regular combat. Assuming your default action is to skip the choice adventure, that's a visit/adventure ratio of 2:1. Returning a value of 1 might suffice here but over 10 visits, 0.5 might be a better estimation. That's not taking into account any combat rate modifiers, either.
 
Any skip-adventure should probably be ignored. Give max-adventure estimate. However, the sea and desert both should follow 'standard' rules based on your turns of fishy and/or hydration.
 
Any skip-adventure should probably be ignored. Give max-adventure estimate. However, the sea and desert both should follow 'standard' rules based on your turns of fishy and/or hydration.

So, if I'm understanding you correctly, in the example of estimating against the oasis, if I had 5 turns of hydration and asked for the estimate over 10 visits, you would expect that to return 1.5?
 
Nope, 11. The total cost for 10 turnips is 5+1+5.

Or if we don't have the total-adventure check, the cost for 1 turnip if you already have hydration is 1.
 
Mafia does track this in AdventureRequest.getAdventuresUsed().
This is a really simple function though:
PHP:
@Override
public int getAdventuresUsed()
{
	if ( this.override >= 0 )
	{
		return this.override;
	}
	if ( this.adventureId.equals( "123" ) )
	{	// Desert (Ultrahydrated) may also visit the Oasis
		return KoLConstants.activeEffects.contains(
			EffectPool.get( Effect.HYDRATED ) ) ? 1 : 2;
	}
	String zone = AdventureDatabase.getZone( this.adventureName );
	if ( zone != null && zone.equals( "The Sea" ) )
	{
		return KoLConstants.activeEffects.contains(
			EffectPool.get( Effect.FISHY ) ) ? 1 : 2;
	}
	return this.formSource.startsWith( "shore" ) ? 3 : 1;
}

I'm not sure how to call the getAdventuresUsed() override of a specific location's Request class, although those mostly consist in Richards/Clan sofa, and items that give fights.

It could easily be added as a proxy record, but it sounds even easier to add something like this to a script.

I can understand the FR to avoid the need to maintain something that will be updated internally in Mafia anyway. What would be a good proxy record name?
 
Last edited:
It does know the difference, but this is further complicated by the fact that a second turn is only spent if your last turn was hydrated and now it would be an unhydrated turn.
And a third turn is spent (or isn't it?) if you go to hydrate, but the encounter is overriden by a superlikely (stone rose, pages - you probably shouldn't be adventuring in the desert if you have unfinished superlikelies in the oasis, but you *can*). Or by a wandering monster (again, will mafia just continue trying to hydrate, or will it fail/abort?).
 
And a third turn is spent (or isn't it?) if you go to hydrate, but the encounter is overriden by a superlikely (stone rose, pages - you probably shouldn't be adventuring in the desert if you have unfinished superlikelies in the oasis, but you *can*). Or by a wandering monster (again, will mafia just continue trying to hydrate, or will it fail/abort?).
According to this bug report if a wandering monster (a bee, in this case), overrides hydration, KoLmafia notices the failure but goes to the desert anyway. That's almost certainly not what the user wants.

Given that wandering monsters can happen just about anywhere, depending on the holiday or path or what your familiar has done earlier or ..., how can you reliably predict that it will take "1 adventure" to actually adventure in a particular location and see a combat, noncombat, or choice that is specific to that location?
 
What would be a good proxy record name?
Maybe expected_adv_per_visit?

Actually, it goes all the way back to the first svn commit. [...] In any event, those revisions are from back in 2006.
Yeah, "turnip" dates back to the CVS days. It was added to the UI on January 29, 2005 (so between KoLmafia 1.0 and KoLmafia 1.1) when there was some confusion about the shore (one of the main places people used KoLmafia to adventure in back then) since the little field next to the text box said '# of turns' (that field originally had its own label instead of appearing as a spinner back when the number of places you could go was so limited that it didn't need a filterable multi-select box).

Given that the first commit to the project was on December 15, 2004 and the first formal mention of it in the archived KoLmafia thread was on February 14, 2005, you could say it's practically as old as the project itself and be pretty accurate. It was a natural enough term for me to use such that when I added adventuring support to the CLI on February 20, 2005, that's precisely the term that I used in the CLI output, and it was established as the standard way of viewing it until I changed it to "visits" in April 2006 for reasons probably related to user-friendliness or something.
 
Back
Top