Feature Allow property = value as condition for auto-adventuring

There quite a few cases where it would be extremely handy if mafia had some framework for allowing property string matching as a condition, i.e.

conditions add property oilPeakProgress 0
adventure * oil peak

or

conditions add property walfordBucketProgress 100
adventure * ice hotel

or

conditions add property questSomeQuest step3
adventure * quest location

Mafia would then adventure until the specified property equals the specified value, at which point the property condition would be satisfied and auto-adventuring would complete.

Anyone else think that would be awesome?

This is something I'd love to see.

That would be awesome, and would have lots of obvious uses for completing quests. Even looked into implementing it myself a couple months back, but didn't get very far.

All non-item goals (pirate insults, substats, factoids, flyer ml, health/mana) are currently emulated via an AdventureResult (essentially name + quantity). This would be a departure from the base code if we allowed for arbitrary preference matching. Further, what do we do if the user mistypes the preference or the stop condition? Additionally, how do we tell if we overshoot? Is the condition only met if we have an exact match of the preference?

If we didn't want to depart from the existing paradigm of treating goals as AdventureResults, I could imagine an implementation where we could work with two special types of conditions: increasing numeric values, and quest values. Notably, we would not be able to handle oilPeakProgress, as that decreases.

I don't think I'd want to implement this as-is without first overhauling how goals are handled internally.

A less polished, but possibly more easily implemented and more flexible way could be to allow a type of condition that contains an ASH expression that evaluates to boolean. So it'd look something like "condition set $ash[get_property("bla").whatever() != blub[blab]]" or whatever syntax would be considered desirable and unambiguous. As an aside, one could probably do something similiar with currently available means by stuffing the predicate into some property, adding a bogus item condition (like good old +1 steaming evil) and checking the desired predicate in a postAdventureScript, clearing the item if the predicate is true.

It'd undoubtedly be pretty hacky, but I'd look for something that can handle three types of expression. preference = exact text match. preference <, = or > numeric. questPreference = or > quest step. It is something I started a thread about before, but didn't get far looking into it. I think it'd mainly be adding a load of code to AdventureResult, which is definitely one of my least favourite pieces of code.

My thinking was to start small, but the comments thus far seem to indicate a willingness to go right for something much bigger.

Implementing = struck me as the obvious first step, but allowing comparative operators for checking property conditions would be even more amazing. For properties beginning with "quest", we could have special handling (where "started" < "step1", "finished" is always > anything else, etc.), and beyond that, if both the property value and the target value convert to float, treat the comparison numerically. A bit of sanity checking could be added as well (don't allow nonexistent properties, don't allow < or > for non-numeric values) but would not be strictly necessary.

Suggested syntax is as demonstrated above (i.e. no "==" necessary for equals), but allowing < > <= >= as well would be a fabulous expansion. I can see >= being much safer for quest properties than simply =.

Just in case we're looking at a larger overhaul of goals, I would like to mention another feature request I was planning on making sometime down the road: some way of allowing logical operators to connect conditions. For example, adventure in the Black Forest until you get "1 blackberry galoshes" OR "property blackForestProgress 5". That is a much bigger can of worms though so I was planning on sitting on it for a while. I'm merely mentioning it here in case it helps shape the structure of a goals overhaul.

@gulaschkanone: Everything suggested so far can already be easily accomplished in ASH (by either a script or using the "ash" command in the CLI). The purpose of this request is to allow mafia's already excellent auto-adventuring framework to be accessible for an even wider range of cases, without needing to use ASH.