I'm still not seeing how this is an improvement over the current implementation, especially since you postulate a failure mode that could waste turns of ode or milk which is the only motivation for the change that has made it through my dense skull.
I solve this kind of problem a lot and a "Plan than Execute" pattern seems to work pretty well. Right now consumption is a multi-step process and EatDrink Plans one step than Executes it. ConsumeLast should Plan all steps and then Execute them. Ideally a Plan would never fail. It would always Execute to completion. In the absence of that Ideal, Execution should always Abort if it is unable to complete the current Plan. Furthermore Execution should be ordered in such a way that if it aborts without completing a Plan, the completed steps are the most beneficial/least harmful. Thus, ConsumeLast probably tries to obtain all ingredients first and abort if it can't get something. This includes obtaining MP regen items if Ode is to be cast and milk. Next it probably creates every item and aborts if it can't create things. Finally it casts the desired amount of turns, aborting if that is not achieved and consumes. Phrased like this, a failure to ConsumeLast should return control to whatever called EatDrink because these failures usually indicate something that EatDrink Planned on is not feasible. In an environment where automation trumps all then either the calling entity needs to be aware that EatDrink might fail and handle that accordingly or EatDrink needs an alwaysContinue type of flag that would Plan and Execute as best it could until the original fullness goals had been met or shown to be unfeasible.
The current problem is that, if you have Value of Adventures set below the price of a single milk, or it costs more to restore mana to cast ode then you'd gain for that amount of booze, ED will skip it as a bad idea. We'll call this problem 1. As well, ED will, if you aren't using box servants, happily burn away your milk or ode crafting. This is problem 2.
Problem 1 can be solved in 4 basic ways, we'll call these a-d.
1a) Ignore it. People can deal with it, or raise their VoA.
1b) Ignore prices and always buy milk/cast ode, basically ignore VoA. [sarcasm]The admins would NEVER do something that made milk or a formerly cheap restorative go sky high in the mall. Ever.[/sarcasm]
1c) Moderately ignore VoA by assuming that people always have as much food as they want. [sarcasm]If someone, as a level 1 casual on their first additional ascension, currently possessing 2000 meat (their first ascension sort of sucked), wants to eat up to 15 appetite, of COURSE they'll be able to afford 15 decent foods after buying two 900 meat milks.[/sarcasm]
1d) Implement an intelligent crafting/consumption stack, that actually knows how much it can consume, crafts it all first, then uses its milk and ode to consume it. This would be aware of how much milk and ode is actually needed for the amount being consumed.
Regarding problem 2, we really only have 2 options, so we'll call those a and b.
2a) Ignore it. It's their fault for not knowing in advance what they wanted.
2b) Implement a crafting/consumption stack that crafts it all first, then uses its milk and ode to consume it. This would mean that milk and ode only get burned off by the food, not the crafting.
Options 1a and 2a all have the advantages of us not doing anything.
Option 1b has the advantage of being easy. Instead of actually checking VoA and the consumption stack, we just toss a "can they?" check into the milk/ode validator, and move on.
Option 1c has the advantage of ease as well. We just use the requested amount by the player and expect success at all times. No complicated futzing with the details.
Options 1d and 2b are what I'm proposing to do with ConsumeLast. Make ED actually aware of what it's doing, save adventures, and respect the player's desires.
So, you've changed desires from your post in 788?
I'm not sure ConsumeLast is of any benefit to me unless it recognizes that a consumption stack is "invalid" and readjusts the stack until it can be executed. Any implementation of ConsumeLast that requires ED to be rerun will be looked at in an unfavorable light. I'm adopting the point of view that automation trumps efficiency which I believe is consistent with dj_d's vision for Ascend which is what drives me while I am a steward.
to this:
Ideally a Plan would never fail. It would always Execute to completion. In the absence of that Ideal, Execution should always Abort if it is unable to complete the current Plan.
You gave that initial 'nay' to this question:
Should ConsumeLast stop trying to craft (and possibly consume the stack up to that point) once you run out of adventures, should it keep going knowing that your crafted food will almost certainly be suboptimal, or should it have a preference to allow the user to decide? If it's a preference, would probably have 3 options... continue (good for automation), repeat internally (use what's on the stack and rerun that stage of the consumption, like continue in automation, but might still cause suboptimal milk/ode usage), or abort (use what's on the stack and go on to the next step, will take running ED 2 times to actually get full consumption done).
It appears that you've changed your mind, and want it to have a preference as I proposed, yes? Though the specifics may be slightly varied... we'd probably just have a preference for abort if stack-failure. If you run out of adventures while running ED and started with adventures, it should consume the stack up to that point. If the abort-preference is set, it could either move on to the next consumption type (alcohol or spleen) or completely abort the script. If it's set to continue, it should then rerun its 'best' check, and find out what fancy items it next wants to craft. The consumption of the first few might have made a different item more appealing, and the initial filtering was based on how many adventures you had at the time... because of that, your "initial plan" was based on running out of adventures and crafting suboptimal food.
We can continue to run your initial plan if you prefer, but that's not the best plan, and it won't give you food results as good as the current EatDrink does. Because the current EatDrink will consume the best item until it can't anymore, then it will find the best item based on your current state... it won't give up on fancy crafting because you started crafting with 1 adventure left.
