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

It isn't nondestructive to eat 5 less fullness though, since there's a reasonable chance it will result in the script picking inferior items both times through to fit the awkward fullness space. An example is if it would normally fill 15 fullness with 5 lasagna (with field gar), and that value is split up into fullness chunks that aren't a multiple of 3.

Exactly... if you wanted to eat 15 points of fullness, but you have a steel lasagna available, you actually only 'fill' 10 points of fullness. Because your fullness max went up by 5 as well. So you end up with a 10 fullness consumption as well as a 5 fullness consumption, and you just need to hope that it ends up being something near as good. You're much more likely to end up not being able to fill up optimally if you need to break it up twice.

Aoi said:

I'm inclined to say that the script should do what it's told and only eat up to what the user sets the limit as

Click to expand...

+1

By that definition, you told the script to efficiently (using whatever definition applies) get as many turns as possible using the specified fullness. The steel lasagna doesn't give any adventures, so the script shouldn't be eating it at all unless it has some special handling for that case. But I don't think anyone would say it's better for the script to not use the steel lasagna.

It has special handling to make it use the steel lasagna first, if at all possible. Since there's not really any time you'd want to skip them.

The question is, if we go from 0-15 (15 total) fullness, do we want to still do 5-20 (15 total) fullness, or 5-15 (10 total) fullness?

I'd be inclined to make the script abort after using the steel organ.

Annoying to have to run the script again, but it forces the user to re-enter the amount of fullness/drunk/spleen they wish to use, meaning it will be correct.

Just my 2¢.

Can anyone make a compelling case that the steel item should always be consumed if it is ever discovered in inventory and fullness permits? If so then there should be a FR for mafia to do so. If not, however, then ED should also ignore the presence of a steel item unless explicitly asked or allowed to do so.

Sometimes 15 means 15 but sometimes it means "as much as I can handle". ED probably should not be guessing which is which although I would guess the latter is more likely.

I fear I am about to suggest Yet Another Preference, EDautoSteal. If true then ED will consume any steel item that it can and then adjust the target fullness accordingly based upon success. If false then ED will not consume the steel and just consume to the target fullness. If false then it is almost certainly true that the user can find ways to feel they have been screwed by ED so it probably defaults to TRUE.

I have no problems with adding the preference... I'm just wondering if there's anyone out there that would ever actually NOT want to use it if they have it available. Since it's not affected by any of the helpers (has anyone ever tried it with munchies?), there's no reason to delay using it.

In both of your cases of 15 means 15 or 15 means as much as you can handle, you're consuming 15 fullness of useful consumables. You're not wanting it to be consuming 10 useful fullness. In the same example, say you want to leave room for a cookie, and you go to 14 fullness instead (so you have room for 1 FC). That 1 fullness for FC, with steel lasagna, is actually at 19, not 14. You've consumed the same (useful) 14 fullness.

I can variable-bloat if we need to, but it just seems like your example supports the auto-consumption and fullness update version. Since you still have the same usable fullness that the user requested...

Theraze said:

In both of your cases of 15 means 15 or 15 means as much as you can handle, you're consuming 15 fullness of useful consumables.

Click to expand...

No. If I mean 15 and the steel is consumed then "normal" food only adds 10. If I say I mean 15 and mean it then i would not be full if steel were consumed.

Not sure there is a real good use case for that but it seems every time I presume people would like things "my way" I her from people who don't.

Dunno for stomach, but for liver there's pool table - you don't want to be over X (10? 12?) drunkness for optimal pool trolling.

Okay, so with liver (fullness/inebriety/spleen all count the same for this, so let's not over-confuse ourselves) having a reason why you wouldn't want to go over an amount, we have a specific case causing exactness being optimal.

So, second question. Consume or abort? Do we do what they say, minus the 5 for steel, or just consume the steel (if they asked for at least 5) and then abort, as zanmatoer suggested? Both sides have their benefits...

Consumption
Pro - means that we did what they asked us, and they have adventures, better for people running full automation.
Con - possibly less than optimal options.

Aborting
Pro - means we CAN do what they want, and do it as optimally as possible.
Con - if they're automating, they'll probably miss out on that entire section.

Pardon my noobiness. I'm very new to all these scripts, but im learning along the way...

Anyway heres my question:

Does this script check the mall only for the items in your inventory, or does it go through a list of 'recommended' food/booze/spleen items that consults for the best current adventure : price ratio? (That was my initial thought when i first saw the script)

Reason for my question was cause i got this:

Starting EatDrink.ash (version 3.1.7).
Consuming up to 15 food, 19 booze, and 15 spleen and then finishing off with the stiffest drink we can find.
Considering food from inventory Hagnk's. Per-item budget cap is 25000.0.
Retrieval cap is 20000. Price will be a factor if you own it already.
An adventure has the value of 500 meat. Muscle subpoint is 1.0. Nonprime stat subpoint is 1.0.
Simulating only; no purchases or food/drink/spleen consumption.
food: At 0, consuming to 15 with 20000 meat.
Best find was none with a value of 0. That's no good, so not consuming and moving on.
drink: At 0, consuming to 19 with 20000 meat.
spleen: At 0, consuming to 15 with 20000 meat.
At drunkenness of 0. Overdrinking with 20000 meat.
Finished. You had -Ode to Booze in effect. Adventures listed above does not reflect that, but this does:
Spent 0 meat for a value of 0 meat. Gained Fullness: 0. Inebriety: 0. Spleen: 0.
Adventures: 0. Muscle: 0. Moxie: 0. Mysticality: 0.
Eating, drinking, and spleening complete. Commence merrymaking (at your own discretion).


As you can see. I completely have no idea how to use this script... I already have meat on hand, but im too afraid to hit false on the simulator. Hope someone can enlighten me on this.


ETA: also, what does "Retrieval cap is 20000" mean? My guess is the amount of meat the script will spend to buy all these goodies? Is the value a total, or individual for each item category? (like will the bot spend 20k for all 3, or 60k total?)

Fwoosh said:

Does this script check the mall only for the items in your inventory, or does it go through a list of 'recommended' food/booze/spleen items that consults for the best current adventure : price ratio? (That was my initial thought when i first saw the script)

Click to expand...

It will check whatever you tell mafia to check. I'll elaborate as we go on a bit, but Let me snip random bits.

Considering food from inventory Hagnk's. Per-item budget cap is 25000.0.
Retrieval cap is 20000. Price will be a factor if you own it already.
An adventure has the value of 500 meat. Muscle subpoint is 1.0. Nonprime stat subpoint is 1.0.
Simulating only; no purchases or food/drink/spleen consumption.
food: At 0, consuming to 15 with 20000 meat.

Click to expand...

Top line is which locations you've told mafia to consider using automatically. In your case, you've only allowed mafia to use your inventory and storage automatically... no NPCs, no mall, no coinmasters. If you want EatDrink to consider them, you need to turn them on as valid options. Go to preferences, Item Acquisition, and look through there.

Per item budget cap is the most valuable item considered... if it costs 25.1k, it gets eliminated, even if it's in your inventory. That protects things like breaded beer and other rare items.

Retrieval cap is how much it can spend to get items from the mall, NPCs, or coinmasters... if you let it. Again, note above, you haven't allowed it to consider them at all.

In the last line about consuming to 15 with 20k meat, that's the total amount of meat allowed to be spent for that whole category. So with 3 (or 4, if you're overdrinking) categories, EatDrink shouldn't ever spend more than 80k meat.

Retrieval cap is based on your mafia preference autoBuyPriceLimit. Category max is your eatdrink_stepMeat zlib variable.

Theraze said:

It will check whatever you tell mafia to check. I'll elaborate as we go on a bit, but Let me snip random bits.

Top line is which locations you've told mafia to consider using automatically. In your case, you've only allowed mafia to use your inventory and storage automatically... no NPCs, no mall, no coinmasters. If you want EatDrink to consider them, you need to turn them on as valid options. Go to preferences, Item Acquisition, and look through there.

Per item budget cap is the most valuable item considered... if it costs 25.1k, it gets eliminated, even if it's in your inventory. That protects things like breaded beer and other rare items.

Retrieval cap is how much it can spend to get items from the mall, NPCs, or coinmasters... if you let it. Again, note above, you haven't allowed it to consider them at all.

In the last line about consuming to 15 with 20k meat, that's the total amount of meat allowed to be spent for that whole category. So with 3 (or 4, if you're overdrinking) categories, EatDrink shouldn't ever spend more than 80k meat.

Retrieval cap is based on your mafia preference autoBuyPriceLimit. Category max is your eatdrink_stepMeat zlib variable.

Click to expand...

Hooaaahhh! Somehow everything seems so much more obvious after that. (can't believe I never bothered to look through the KoLMafia preferences first, d'oh)
I have a good idea on how to proceed now, you just made my day! Thank you sooo much for the explanation!

Now... time to go tinker around with settings :3

Not a problem. Also, if you're trying out lots of simulations first, I'd play with different step meat values and so on. Personally I'm currently running at the 20k default stepmeat, but with 1250 value of adventure (default is 500), 12.5k budget cap (default is 20k), and 10k autoBuyPriceLimit (default is also 20k). This means that eating one thing that takes up my whole budget isn't possible, so wrecked generators (which cost 19.9k) are out. Even if I have some in my inventory. And I'm fine with that.

Anyways, play with values, if you have questions about anything, let us know and we'll try to get you sorted quickly.

Not sure if this has been brought up before, though I couldn't find it by searching the thread. Could EatDrink be improved to support fortune cookies using the CounterChecker script? Would be nice if these could be incorporated into the proposed diet. I imagine the following:

• If there are no fortune cookie counters present, ED reserves 1 fullness for a fortune cookie, and includes it in the proposed diet so that it benefits from milk.
• If there is a counter present, but the projected adventuregain from the rest of the diet approaches (current counter value + 160), ED reserves another fullness for an additional fortune cookie (but doesn't eat it), and thus recalculates the proposed diet based on -1 fullness.

This should of course be optional/configurable by setting a zlib var.

I really hope this is possible. It would be really cool if I didn't have to manage my semirares manually anymore!

bsander said:

Not sure if this has been brought up before, though I couldn't find it by searching the thread. Could EatDrink be improved to support fortune cookies using the CounterChecker script? Would be nice if these could be incorporated into the proposed diet. I imagine the following:

• If there are no fortune cookie counters present, ED reserves 1 fullness for a fortune cookie, and includes it in the proposed diet so that it benefits from milk.
• If there is a counter present, but the projected adventuregain from the rest of the diet approaches (current counter value + 160), ED reserves another fullness for an additional fortune cookie (but doesn't eat it), and thus recalculates the proposed diet based on -1 fullness.

This should of course be optional/configurable by setting a zlib var.

I really hope this is possible. It would be really cool if I didn't have to manage my semirares manually anymore!

Click to expand...

+1

This would be amazing, but looks to be a massive undertaking.

You can also make sure to call eatdrink with fullness_limit()-1 if you fulfill any of the above mentioned bullet points, a lot easier

The first, maybe. The second, probably not.

Reasons:
1. Having a configurable option to say that you'd like it to prefer a fortune cookie if

> ash (get_counters("Fortune Cookie", 0, 200) == "")

Returned: true

Click to expand...

does return true, like that, sort of works. It means that you can definitely make use of a single cookie. It doesn't guarantee anything if you actually need two to get to exact semi-rare happiness, but... preferring a fortune cookie and throwing a recalculation on the stack anytime a fortune cookie is the best option, relatively easy. I think.

2. There's been strong pushback from fronobulax and the general community regarding the script doing anything besides what you tell it to. Case in point, the steel organs. Currently they get prioritized, which is fine... but they don't cause the system to recalculate and fill up 5 more, which would also be relatively easy. They just make it leave you with 5 more room for later.
As such, I think Winterbay's suggestion of asking the script to stop earlier if you want it to stop earlier is the best solution there. You can even just do a fairly simple ternary to decide if you need to -1. Or a more complicated ternary to decide if you want to -2.

Edit: Part of the problem is that when we're lazy, we can't tell how many fortune cookie counters we have...

> ash (get_counters("Semirare window", 0, 200))

Returned: Semirare window begin Semirare window end

Click to expand...

You can see that the two semirare counters are both squished in there. We can't use count to see that there's two, and that causes the same problems with detecting how many FC counters we have. For best results, we'd need to detect >3 (you need to adventure, we're just wasting your meat and fullness), >1 (time for another cookie!), <1 (you need a cookie), and aborting if we have exactly 1. Now, I might be able to do this by checking length of the whole mess... maybe... but that takes a lot more thinking than I'm capable of doing at this point of the morning, so I can't remember if it lists a single item or all of the entries.

And yes, I know the problem has been solved, repeatedly. But I'm tired right now. And this seems like a good lazy excuse, tied into the "official maintainer has vetoed any changes involving script not doing what you ask it to" excuse.

Maybe, though the problem I have with that is that it may reduce the effectiveness of milk. Say the script detects I have no counter active and so runs to 14 instead of 15, but then in the next step it spends a turn crafting a peppermint booze or something. That effectively costs me a turn (or meat for a new milk). So I have to do it manually the way I do now: use milk; eat fortune cookie; eatdrink;.

I do agree that managing multiple fortune cookies to ensure a single counter is out of the scope. I guess optionally the script could abort if it detects multiple counters after eating a cookie, though.

I don't really see the big problem with your second point, however. I tell the script to manage my diet, and so that's what it does. Of course there should be a possibility to include/exclude fortune cookies from the diet for the people that want maximum turngen, but it's not really outside the scope of the script.

I would already be pretty happy if the script fulfills point #1 (and automatically eats the cookie to fully utilize the milk), but I don't really see why point #2 couldn't optionally be included too if the issue stopping it is not a technical one.. Then I say make it configurable and disable it by default.