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

The 'working properly' is that now ED is showing the right values now that we have that hack in there. Morgoth reported in post 1950 that mafia itself appeared to be showing an incorrect value for hot hi mein adventures in the item manager that doesn't properly take saucemaven into account, since it was showing 28.5 instead of the proper 34.5 adventures. Not sure why it apparently believed that SM gave 4 adventures.

But sorry. :) I try not to post bug reports until I can personally make it verifiable. Since EatDrink pulls directly from mafia's information on consumable stats, the question is whether or not the 'right' thing to do is note that the skill has an effect and show the modified adventures or not. When I made an official FReq to expose the modified values for food with pizza lover and saucemaven, it didn't get any attention, which is fine. It just means that we repeat the work that mafia already has done in the item manager. Sometimes that means that bugs might not get reported because I never see that apparently mafia's calculated adventures are wrong.
 
Any chance that this is going to be updated to account for the Mayo Clinic? That would really make life so much nicer.
 
If I had a Mayo Clinic? Maybe. Without one? Probably not, unless there's very specific requests on what's supposed to happen.
 
Theraze said:
If I had a Mayo Clinic? Maybe. Without one? Probably not, unless there's very specific requests on what's supposed to happen.
Click to expand...
This is an IotM that I'm skipping because it looks like a pain and since mayo packets can't be traded, I can ignore them.
 
Avoiding the largest fiddliness of blood-mayo concentration, because that's all about NOT getting adventures for your food, and EatDrink is about getting the adventures, and if you just wanted to do it all as BMC, you can simulate and then run it as mayo yourself. Avoiding mayozapine, since we don't consider effects in ED (all about those adventures) and stats won't be enough to matter appreciably, especially in aftercore.

That leaves 2 mayo-types we might care about: mayoflex and mayodiol.

So, it looks like any potential handling would basically be:
1) Is your VoA higher than 1000? Consider buying and using mayoflex. Add one adventure to each food item and 1000 to the total cost. This makes tiny food better.
2) Does your best food without bonus adventure and the 1000 bonus cost have a better average than your drink average? Consider using mayodiol to turn a fullness into drunkenness.

Four things tied into potentially handing those options:
1) It means iterating over the food lists at least 3* as much, which means that executing will take at least 3* as long. Because we need to compare the pure food, mayoflex food, and pure drink. Pure food compares to both mayoflex and drink. Which means that to make this work best, you'd probably need to run drink first and recalculate food against drink on every consumption - we'd still construct the full set of potential drink items, we'd just abort the consumption after every step if the next item isn't the same as the last. This means that if you're consuming 4 different SHC drinks, it's going to redo the comparison at least 5 times - for the SHC drinks and then your filler after - and the drink consumption will take way more time.
2) The mayo minder apparently overrides whatever mayo you're manually using, which makes it significantly harder to actually control this. This means that what we'd probably do is auto-closet all mayo not of the right kind before using retrieve_item to collect the desired one. This may leave large colonies of mayo languishing in the closet. But really, isn't that where mayo belongs?
3) This means that we do the food AFTER drink rather than before, like currently, since we don't know if our food option will be better than our drink option until we are into the drink. So as listed above, we'd go through drink one item at a time until there's no space left, at which point we no longer care about mayodiol.
4) Additionally, we need to compare the bonus value from converted drink against the bonus value of the extra adventure, keeping in mind that each will run us an extra 1000 meat for the helper.

Any potential handling would also be behind a zlib variable, so that people who possess a mayo clinic but didn't want ED to take 5-10* as long to run could handle things themselves.

If you have a different scope of what you'd like the handling to be, let me know. This is just based off reading the wiki pages and the top of my head.
If that does sound good, you can send Theraze the clinic or Mr A.

Yes, it'll be fiddly and make ED run like a slow beast when enabled for a few bonus adventures. But the only change non-mayo-runners are likely to experience is that the order of consumption will probably change from EDSO to DESO. Which won't change the inputs, just the actual execution. :)
 
Theraze said:
2) The mayo minder apparently overrides whatever mayo you're manually using, which makes it significantly harder to actually control this. This means that what we'd probably do is auto-closet all mayo not of the right kind before using retrieve_item to collect the desired one. This may leave large colonies of mayo languishing in the closet. But really, isn't that where mayo belongs?
Click to expand...
I don't see how this can be the case, as once you've used the mayo it is already in your mouth. Will test tomorrow, though, just in case.
 
That was based on talk about the Mayozapine.
http://kol.coldfront.net/thekolwiki/index.php/Talk:Mayozapine

Specifically, this:
This seems to have been removed. I initially discovered the effect with Every Day is Like This Sundae granting 200 turns of Smithsness Dinner, but when I did it again just now, it granted its normal 100 turns. I suspect it was a bug. --billybobfred (talk) 02:37, 5 May 2015 (UTC)
Alternately, I screwed up how the Mayo Minder works. Manually-used mayo is overridden by Minder mayo. --billybobfred (talk) 17:07, 5 May 2015 (UTC)
Click to expand...

Unfortunately, the Mayo Minder talk page doesn't have any discussion about priority of mayo or overriding or anything else similar. Since it doesn't exist yet.
 
I am 99% sure that manually used mayo does take priority (I used the stat/buff doubling mayo manually, and it worked properly despite having mayo minder set to the bonus adventure). Only tweaks I could see would be accounting for any shop discounts (mayo only costs 950 with five finger discount), and maybe accounting for the stat doubling one since there are meat values associated with substat gains (although probably not on that one since adventures are definitely king as far as I'm concerned, and it would probably way overcomplicate things). That and MAYBE accounting for the leftovers mayo if you are very low on food (could be useful in ronin/hc), although that is also not a huge priority.

But yeah, the extra time spent on recalculating to account for if the fullness -> liver mayo sounds worth it imo, and that is really just such a complicated beast that I don't want to deal with it myself.

Anyway yeah I'm more than happy with your outline of how to approach it, so I'm gonna go send you a clinic now :)

Also as an upshoot, with eatdrink automatically accounting for mayo, the mayo minder would be unnecessary anyway, so worst case scenario, if it turns out to mess with manual mayo usage, you can just advise people against buying it!
 
Note 1: I'll keep referring to 1000 meat in general despite there being 3+ ways to reduce that by 5%, but will use npc_price to get the accurate pricing out of mafia.
Note 2: Theraze is level 12 in HC and out of adventures. Should break prism tomorrow and get to start testing. Won't be tonight, since this is the celebreation of date-aversary - the anniversary of the first date with my my wife - and that means that there isn't going to be computer time tonight.

Well, the leftovers mayo is tradable (though it apparently doesn't work with size 1 items), so that's actually relatively easy to check against... just add the value of the appropriate mayolus - 1000 meat (for the mayo) to the value of food item bigger than 1 fullness. Since ED is about meat value, it's the same meat value whether you gain the item through mayo-recovery or the mall...

What we can probably do is rather than just boolean on/off for the mayo clinic, choosing which options you want - either with a bitmask or with human readable.
The bitmask is nice because people can't really confuse what to put in, and how to do multiple. Since we're only doing 4 potential automated choices, that means that bitmask would be 0 (no mayo calculation at all) up to 15 (calculate everything).
The human readable is nice because if you can follow directions, you can tell with a glance what you've got in there. The problem is that people sometimes typo letters, add (or remove) commas, put spaces in the wrong spot, etc. It's harder to troubleshoot when things don't go the way people think it should.
Regardless of how we have it look when it's stored, it'll probably be a bitmask inside the script. Or 4 booleans. But it's easier to test for mayoChoice == 0 to abort rather than testing for 4 booleans, so...
Default would probably be either off or everything on, and I could be easily convinced on either side. Off is good because it shouldn't slow things down for anyone who hasn't asked to be slowed down. On is good because then it uses what's available without needing to think about it, even if it does take longer to run.
 
Mayolus might be a bit more complicated than that, since you can't benefit from other mayo effects if you create it, and I don't think (but am very much not sure) that it can benefit from mayos either. Personally I'm fine with it being an all or nothing toggle, since I don't mind it taking a while (barring it starting to take like, half an hour or something like that), but having a bitmask sounds good too. Human readable would be nice for input/output, just so you don't have to remember which bit is which, but yeah.

Anyway, this all sounds great! :D
 
Oh, are the others additive? Can you get the 1 fullness to inebriety, +1 adventure, and double stats/effects all from a single food item? It sounded like it was one mayo-effect at a time and we were aiming for the single best for each unit of fullness-consumption.

If they're additive, we can calculate between each of the options. It just means that we have up to 9 calculations per food item - the 2*2*2 options for the 3 additive mayos, plus the mayolus option; it would be faster if we only had to worry about the base options, but if they do stack, we should calculate for it as well. Stuff for testing tomorrow or the day after, to try to get things right. Or if people already know that, then I can start to do more than just the swapping of iteration 1 and 2. Heh.
Since it tends to run (for me) in about 30 seconds, if it were 10* as long, that would still be done in about 5 minutes, and might provide either 15 bonus adventures or the extra 150k meat for selling mayolus bits. For most people, they're probably not breaking 10k profit per adventure. That being said, mayolus prices should drop soon. Especially the hyper-inflated bad options which are at 400k+ each.
 
Oooh, I see what you meant now. I hadn't even thought about SELLING mayolus. No, the mayos aren't stackable.

If you do account for selling the mayolus though, which I can imagine would make it the best bang for your buck when selling it compared to what you could expect to get from a single bonus adventure (then again you can't get mayolus from 1-fullness food apparently, so it would be a bit more complex than that, but still), I would definitely want an option to disable accounting for SELLING the mayolus, since I'd rather just have more adventures if I'm in run. But yeah, that's really neat!
 
Good, non-additive means that we can cut our projected time in half. Excellent.

You've already said what profit you expect to make from a single bonus adventure by setting your Value of Adventure preference. That's what it's about.
So if your 2-fullness food that costs 1500 meat would normally give you 12 adventures and you've set your VoA to 2000, that means that your food value is 2000*12=24,000 total profit, minus 1500 meat for getting it, for a total (starting) value of 22,500. Per fullness, the value is 11,250 per unit.
With the +fullness mayo, you'd instead get 13 adventures and it would cost an extra 1000 meat, so your total value is 23,500 (25k-2.5k), with a value per fullness of 11,750.
With the +mayolus mayo selling for 10000 (it's higher now, but I expect it to drop some with more people using it), you'd still get 12 adventures and it would cost an extra 1000, so your base value is 10,750 per unit. BUT you'd also get the resellable mayolus, which would change the total value up by its mall price (whether you sell it or not). So rather than having a total value of 21,500, you'd have a total value of 31,500, and a per unit value of 15,750.

But if you don't want to get the items in-run (or ever), you can always disable that check and just go for straight farming-goodness. Options. :)

What I'm currently thinking about the eatdrink_mayoClinic variable is checking the length. If it's less than 3, I'll turn it into an int for the bitmask. If it's not, then I'll parse for words - adventures, stats, effects, inebriety, drink, mayolus, items. Probably.
 
Well, I'd like to have the option to account for mayolus in regards to EATING them, in case I have a very small amount of epic food available, like in run, while not accounting for selling them (since I'm less concerned with making meat in run). But yeah, I'm excited for this accounting for the mayo clinic, it's already such a nice script :D
 
Yeah... the script can't really do that. Unless you have a wrapper script check if you have epic food available and set the consideration based on that. Not unless you want the execution to take 20* as long as it calculates everything, decides whether or not it thinks it might potentially become useful, scraps everything except for that memory, creates all items, consumes one, and starts over from the initial consideration from before it decided whether it would have been a good idea to create a mayolus.

I don't think you probably want it to take an hour to consume while in hardcore. :)
 
soolar said:
Well, I'd like to have the option to account for mayolus in regards to EATING them, in case I have a very small amount of epic food available, like in run, while not accounting for selling them (since I'm less concerned with making meat in run).
Click to expand...

You mean, like, if you would otherwise have to fill your last point of stomatch with a mugcake, then having a mayostat with an epic food is *very* good, because it lets you eat an epic mayolus instead of the mugcake?


Theraze said:
Yeah... the script can't really do that. Unless you have a wrapper script check if you have epic food available and set the consideration based on that. Not unless you want the execution to take 20* as long as it calculates everything, decides whether or not it thinks it might potentially become useful, scraps everything except for that memory, creates all items, consumes one, and starts over from the initial consideration from before it decided whether it would have been a good idea to create a mayolus.

I don't think you probably want it to take an hour to consume while in hardcore. :)
Click to expand...


There's a reason NP-hard problems are called NP-hard and not NP-easy ;)
 
Last edited:
And hey, if you tell it to consider making mayolus and stop at 12 fullness (after 4 painful penne or whatever), you could manually eat your 3 mayolus to fill up. But again, that would just be you telling it when to stop so that you can control things. You can take care of those bits without too much work... it's just a matter of deciding that you'd rather get adventures for the 5000 meat per adventure cost or whatever it's at. :) ED proper is all about balancing meat against the mall, which doesn't mean that you can't tell it to ignore 'good' decisions sometimes. Just be sure you simulate first.
 
Next implementation question:
Is there any good reason to save the non-preferred version of an item along with the good one?

What I'm kind of pondering currently is comparing all possible versions of the consumable and adding a new 'helper' value to the record. If the helper is empty, consume normally. If helper is set, do that first. Incidentally this would easily be expandable to any other helper item we wanted to support. If we ever get another current list of which (other) helpers people would be interested in ED considering. :)

The reason why I'm considering only saving the one 'best' item is that it simplifies ingredients and item stacks in that we don't need to have 4 consumable stacks which we're constantly comparing against - we'd just have the one stack which we'd iterate through multiple times to see which we want. If the new value is better, we simply tag the consumable and move on to the next iteration.

The sticky point is the fullness to inebriety mayo. That will almost certainly require another stack (at least) to handle the food comparison while we're supposed to be comparing drinks. The question is, how far out do we want to go...
If we limit it to single-fullness items which fully go into inebriety, then the check is trivial and we don't need to worry about sabotaging our fullness for the sake of a bit of inebriety. We'd have two item-stacks during the booze checks - one for the booze, one for one-fullness food with the extra 1000 cost for the mayo. We can directly compare the two, since they're both just raising inebriety.
If we include lasagna and hi meins and other larger items, we have potentially more benefit but the calculations will be slower and a higher chance of sub-optimal choices. To do this well, we'd need to add another stack - one for the booze, one for food with the extra 1000 cost for mayo, and one for regular food with the other mayo considerations. We'd need to check if the average value benefit of the mayo-ed inebriety compared to the best normal booze is better than the average value lost through not having those spots for fullness. Which is a little squirrelly to explain, but basically if your best booze has a value per fullness of 3000, your best food has a value per fullness of 5000, and your best converted food has a base size of 2 and value per fullness/inebriety of 3500, then you're gaining 500 for the bonus but losing 1500 compared to the best for a net loss of 1000 meat - you'd be best off just sticking with the booze rather than mayo-ing for the bonus.

So, how complicated do we want to make this? :) Unless people have a major objection against the thought, I'll probably implement the helper value and the basic food-only mayo options within the next 24 hours.
If we get a solid idea on what to do for the inebriety, I'll implement it. If we really wanted to make this complicated, we could let people pick between the two options, but at a certain point we give people so many choices that they don't want to think about how to set them and just avoid the script entirely. :)
 
You must log in or register to reply here.
Back
Top