EatDrink.ash: Optimize your daily diet (and see how your old diet stacks up).

Point noted, but the bottom line is the official version manages milk so that I never see the message whereas the beta does not. If Theraze says the code is different when ((fullness to be consumed > 1) AND (milk == 0)) compared to ((fullness to be consumed) > milk) then the distinction is important and I will make it next time.

Is the bunny smiling behind that cookie? I would be.
 
Yeah... the question is whether it used the first set of milk and ran out, or why exactly it happened... Starts with checking for milk every time through consume_one. I'll need to test the latest tweaks to make sure I didn't put it into an infinite loop when I break into (brief) aftercore hopefully tonight...

Wait...
Hmm...
I think the problem may be that it never actually tries to acquire the milk now, since I moved the acquisition code out of the consume_one code...

Nope, wasn't that. It's the getone section checking how many items were needed. Since milk isn't an official part of the stack, needed never got incremented and it never decided to try for it. Put a check in there that sets needed to 1 if there's nothing in the stack but it's still requested. This (attached) EatDrink should actually be able to acquire out-of-stack items again.
 
If that's the question then it acquired one and ran out but continued to try and consume.

I'll try the 882 version tomorrow.
 
Eh, that one has an infinite loop if you try to get milk and it can't. Lovely. This one fixes that, but should still try to get milk if possible.

Edit: Used this one yesterday with no problems. As I said, the one above will try to get milk forever, and also requires trying to get more milk than you need, which gets into problems because mafia doesn't let you take more milk than you can use, which is where the infinite loop comes in.

Next problem... since we're now able to buy ingredients from the mall, barring being unable to make something because of skills, in aftercore it almost always tries to make it instead of buy the finished item, because it IS creatable and that's the way the system works... What I'll need to figure out is the best way to decide between creation and mallbuying. One way would be to just throw together something like:
Code: 
int makeprice = 0;
foreach i,c in get_ingredients(item) { makeprice = makeprice + mall_price(i)*c; }
if (makeprice < mallprice) { grub[item].price = makeprice; grub[item].shouldmake = true; }
But I'm not sure if that's the 'best' way to do it. If I were being extra picky, I could keep skipping down and looking for cheaper components... but should I even bother? That might be a bit on the overkill side... if we're going to go there, to speed things up, I'd need to initialize a table to keep track of the ingredients and the best/cheapest way to get them similar to the current grub map, but that doesn't actually get wiped out when we reinitialize the grub since it's just about what's the best way to do things, not what's actually possible.
At least, that's what I'm thinking now... it's early and my brain is hating the stress of trying to think.
I think a good thing to do would be removing the partially functional ED-WIP versions above. Doing so to help confuse people less.
 

Attachments

Last edited:
I'll run with #884 today.

Can't you edit your posts to delete attachments? If not let me know and I can delete interim version.

If I have used mall_price to determine my course of action, I am content to let the function acquire actually obtain the item because it is smarter than I am when it comes to make/buy decisions in KoL. I realize that ED does get fiddly about Hagnk's pulls and so on but if ED gets to the point where it expects to either make or buy the item then I have no problems if it is somehow suboptimal to defer the decision to acquire.

I agree a speculative version of acquire that actually reported what it would do to obtain the item would be extremely useful. I'm not prepared to write it yet and I'm not sure it can be easily done in ash.
 
fronobulax said:
I'll run with #884 today.
Click to expand...
Spiffy

Can't you edit your posts to delete attachments? If not let me know and I can delete interim version.
Click to expand...
Did so, was just trying to tell myself what to do next, and note that it had happened, so that if people with way too much time on their hands were reading through and wondering what happened to the attachments that the posts say should be there, they'd get some input.

If I have used mall_price to determine my course of action, I am content to let the function acquire actually obtain the item because it is smarter than I am when it comes to make/buy decisions in KoL. I realize that ED does get fiddly about Hagnk's pulls and so on but if ED gets to the point where it expects to either make or buy the item then I have no problems if it is somehow suboptimal to defer the decision to acquire.

I agree a speculative version of acquire that actually reported what it would do to obtain the item would be extremely useful. I'm not prepared to write it yet and I'm not sure it can be easily done in ash.
Click to expand...

Yeah... I'm using the same order for getting ingredients that the normal acquisition uses, save that I made the order as follows:
1) Own already (Inventory)
2) Closet
3) NPC Stores
4) Mall
5) Create

Normal order is:
1) Own (Inventory)
2) Closet
3) Make (except digital KLP, should probably skip star KLP as well)
4) Storage
5) NPCs
6) Mall

Basically, I put creating ingredients to make ingredients from step 3 to the end of the list... It saves a few server hits and so on, but it does mean you'll end up with more ingredients in the end. I'd be sort of tempted to move it above the mall, at least... if it's available from NPCs, that's probably cheap... but making it yourself may be even cheaper.

It all goes to the whole question of what's how expensive. Buying grapes and fermenting powder from the mall will cost you 170, buying fine wine will cost 132. Even if you have the stores fully available, it'll cost 140 to buy the items and craft it yourself... As such, it's cheaper to just buy it rather then craft it. How much do we care about making it save meat? Do we just care about making it get good stuff, or do we want it to scrimp and save as well?

Edit: The direct problem with using 'acquire' is that we're using EatDrink's preferences for getting items, not the normal mafia preferences. As such, to make mafia preferences work, we'd need to override the mafia settings and fix them when done...
 
Last edited:
#844 behaved nicely, especially in regard to TPS and milk.

Personally I have a problem with ED and mafia having separate preferences. If I ever rewrote ED, which I am less likely to do now that you seem to have taken it on as a project, I would force ED to use existing mafia preferences and make all of my calculations and pseudo-optimizations consistent with those.

In your Fine Wine example, I would buy, not craft unless something prevented me from buying, such as path, preferences or meat on hand.
 
Sure, why not... Let's rework it and just scrap the extra zlib bits. Using autoSatisfyWithCloset, autoSatisfyWithStash, autoSatisfyWithNPCs, and autoSatisfyWithMall instead of the eatdrink values it had before... So, do we want to use eatdrink_budget or just use autoBuyPriceLimit? I can see a major argument for having a separate budget for EatDrink. In a similar way, I can see an argument for the mall, but...

Other tweaks, changed wants_ode to a single line instead of 3 using ternary operators, and added the star key lime pie to not be a creatable item.
 
Wow. Without regard to where the preferences are now, I want two safety valves. One is a max per item - no matter what else, ED will never buy a single item for more than X meat. The other is an overall budget. Regardless of what else happens ED will never spend more than Y meat. I have something close to the latter with an Ascend preference. There is a budget amount and a used amount, the latter of which is a KoLmafia daily preference. In Ascend, it closets all but Budget-Used meat before running ED. It looks at the meat available when Ascend returns and increments Used appropriately. Since used is a Daily preference mafia takes care of clearing it. The problem with this is that since Ed will acquire boxen or MP to cast Ode, those amounts count against the budget.

As a philosophy, if two parameters mean essentially the same thing or are in practice used the same way then I am in favor of having just one parameter. However, explaining to the user how they really are different is also appropriate.
 
Well, if we're using mafia's preference autoBuyPriceLimit that works as a max price per item, as long as we're using acquire (retrieve_item is the ASH equivalent, yes?) to get it. I'll need to validate next aftercore that RI will still mix baking and buying, but if it does, that should work as a budgetting system. If it actually works based on VALUE_OF_ADVENTURE to decide whether it's worth using an adventure or buying the item, etc... so much the better.

Eventually, I want it to budget for ode using the UR meatpermp setting, if anything is in there. If mafia can somewhat intelligently figure out how much that restoration will cost, if it's actually needed at all... great. :) If people aren't using UR, we can either budget it out at 17 meat per mp (using Galaktik, without the quest) or...?

Guess we do still want to keep in ED's Budget value though, for max total budget. :)
 
It's actually means that you have it as a favourite, but it takes more appetite to eat it than you have remaining. If you have eatdrink_favUse on, it will always try to use whatever is a favourite, regardless of whether or not it's a good choice. Basically, it's a way to try to force White Canadians or something else that you're trying to get a trophy on, turn it on. Otherwise, disable it...

I'll default that to false now, so it doesn't keep screwing things up like that.
 
Theraze said:
It's actually means that you have it as a favourite, but it takes more appetite to eat it than you have remaining.
Click to expand...


Then something was more bugged than I thought. I hadn't eaten anything yet and should have had 15 fullness available. No way was that too fattening.
 
But it calculates the whole stack (of that type) before you take your first bite or sip. So in the mind of the stack, yes, it was too fattening. And because it recalculates several times based on speculation, with 500 VoA (default), it would have run through 3 stacks total and have printed that 3 times. With higher VoA, it would have printed more times as there would have been more speculative stacks.

Since 22 is more than 20 we are using the speculative stack.
Click to expand...
Adventures: 22. Muscle: 8. Moxie: 14. Mysticality: 4.
On step 2 your best value was recalculated as 300.
Click to expand...
Little example from today's beecore low-meat consumption on how the speculative stack works. If it had just used up my 148 meat, it would have ended up at 20 adventures and probably 1 or 2 inebriety wasted/left. Using a VoA of 300, it changed things up and ended up giving me 2 more total adventures...
 
Theraze said:
But it calculates the whole stack (of that type) before you take your first bite or sip. So in the mind of the stack, yes, it was too fattening. And because it recalculates several times based on speculation, with 500 VoA (default), it would have run through 3 stacks total and have printed that 3 times. With higher VoA, it would have printed more times as there would have been more speculative stacks.
Click to expand...

So . . . what is the purpose of this behavior? It seems that it's going to cause a lot of drag as it calculates and recalculates stacks costing me even more time than the version in the first post does. Especially when my VoA is at 850 or higher (which is where I put it once I reach a point where I can do some decent farming).
 
It appears eatdrink was hardcoded to using signs to determine restaurant/bar accessibility, which is no longer correct. I'll put in a patch when I get time, but it's something that I feel could easily be overlooked.
 
The total additional calculation took me an extra 2-3 seconds, if that, less than one default 'pause' timer. The biggest delay currently is pricing out all of the items that are newer than historic_age and officially possible. That part takes ~30-60 seconds once a day currently. The speculation? Fast...

The purpose? Get you extra adventures. As my example showed, I got 2 additional adventures because it reconsidered.

shazbot said:
It appears eatdrink was hardcoded to using signs to determine restaurant/bar accessibility, which is no longer correct. I'll put in a patch when I get time, but it's something that I feel could easily be overlooked.
Click to expand...

No clue where you're getting that... I don't find either in_<stat>_sign or <location>_available in my copy of EatDrinkO. For that matter, "sign" only finds the word significant twice, and "_available" gets 0 hits.
 
Last edited:
Here's a version that's a bit more odd. I'm using retrieve_item along with try/finally to set (and replace) autoBuyPriceLimit. This should do whatever's cheapest, using mafia's settings... the EatDrink settings are still used to decide what'll be the best food item, but this simplifies the whole acquisition code along with figuring out if it's cheaper to do ingredients or mall-buy.

If I do end up sticking with this version, I'll end up doing one or both of the following: try to see if it's possible to make a simple 3 variable version of retrieve_item that will accept a max price value, and come up with alternate code that will avoid using star key lime pie and digital key lime pie until after get_ronin returns false. Should be easy... when parsing items, if get_ronin is true, skip those items from the possible list. Actually, let me add that now before I upload. The other is another mafia tweak, and I won't propose-FReq/offer-that-patch until people have checked if this is actually useful. :)
 
Last edited:
I'll try #899 after rollover since I burned today's turns.

I don't really care why but the beta versions with speculation do take more time than the official version. Admittedly we are talking about seconds but it is noticeable. This is an observation and not a suggestion that something be done.

What is not amusing me is price updates for items that as far as I can tell are never seriously considered. The price sharing option will update the historical prices so, in general, using historical prices should be close. Would ratcheting up eatdrink_maxAge pretty much guarantee that ED would never look up the price of an item unless, of course, the historical price of that item was never getting set?
 
You must log in or register to reply here.
Back
Top