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

Okay, done. Now we just need validation that the hardcoded 5k/30k chef/bartender does actually rebuild properly, and we can change that over to a new variable and pop a version for people to test. And/or frono to release.
 
Okay, so this version has support for the 3 new chocolates on the normal fancy counter, as well as turning GET_CHEF and GET_BARTENDER into ints by default. It checks for true first, setting them to 5k and 30k if they're set as true. If set as false, it uses 0. Otherwise, it uses the value as an int. This is a bit slower (3 checks instead of 1) but means that users won't have their values changed without their permission and won't see error messages for failed to_int checks. If you've set your get to -1, it will use 999999 instead, as you're telling it that money is no object, but we really don't want to mess you up if something goes REALLY nuts with the economy, so...

Edit: Checked it and zlib is too smart for me... when it runs the setvar, it normalizes, like so:
> seatdrink

The string "true" is not an integer; returning 0 (zlib.ash, line 65)
The string "true" is not an integer; returning 0 (zlib.ash, line 65)
ZLib setting eatdrink_getChef normalized: 'true' => '0'
The string "true" is not an integer; returning 0 (zlib.ash, line 65)
That means we can't actually convert in place as easily. On a 'positive' note, it means that the default won't cost people meat... but...

Edit2: Okay, checking if chef/bartender are true before we run the setvar and if so, setting them to the 5k/30k values. This works silently, because we're hitting it before the type check. If your values are currently set to false, it will visibly change as above, but normalize to 0, which is where we'd set it anyways. May as well not waste people's normal execution times with 2 additional checks when one will do. Tested and this seems to work properly with true/false/deleted/existing.

Edit3: By the way, all the edits except for this one happened before posting. But they did turn around the direction of the post, so... edit! :D
 

Attachments

Is there a way to set EatDrink to set 1-drunk/full/spleen items as "filler" instead of attempting to say, use 19 Go-Wassails for my daily diet?
 
If 19 Go-Wassails are your best daily diet, why not use them? If something else is your best daily diet, why did EatDrink skip it?
 
If 19 Go-Wassails are your best daily diet, why not use them? If something else is your best daily diet, why did EatDrink skip it?

I'd rather use non-limited (granted, it'll be a loooooong time before Wassails become truly limited) items to fill myself, if it's going to come to that. I had been running Peppermint Drinks all through Crimbo with a single Wassail to bring me to 19 Liver; however, something happened with the Peppermint prices (instead of seeing them for 8-8.5k, they were, as of the last time I checked, 9.5k-12k for the lowest ones), and now EatDrink is running with a liverful of Wassails. While I understand some are happy whittling away at a finite resource, I'd prefer to use things that, unless the encounter they or their parts come from is retired, are continually available.
 
Well there is an existing "avoid" mechanic so (presuming it still works as intended) perhaps that should be used?

Code:
setvar("eatdrink_avoid_"+replace_string(to_string($item[wet stew])," ","_"), true);

That sets a zLib variable that should cause ED to avoid wet stew. Several ways to get it so Go-Wassail is similarly avoided.

Tangent - perhaps someone should put together a set of "avoid" variables so that EatDrink will only consume renewable resources. Green EatDrink?

Tangent - Is it time for another update? I seem to recall waiting for some boxen changes to be tested but last time one exploded for me ED did something reasonable and expected so that may be as tested as it is going to get.
 
Yeah, 1563 should have all the box changes we talked about, and nobody's complained or reported any issues with it.

The issue with trying to limit to only 'renewable' items is that there's no currently-good way to set or track that with current known data. Nothing in the data file says "limited, save this!" except for price... ED is rather unlikely to be drinking any breaded beer or such items, but that's only because people want them. Even if we/ED tries to limit specific items, that just means smart users will end up buying/drinking 19 manually. No difference, except someone actually had to think about the item they're using. If you want to avoid them, put in an avoid. If you want to use the best possible diet, don't. If you want to have just one, put in an avoid and drink one manually.
 
put in an avoid.

If I actually were to implement the Green ED behavior I would just have a text file with "avoid" parameters for all of the non-renewable items that I had manually identified and just use Ye Olde Text Editor to add and manually merge them into the various var files.

I'll release a new version in the next few days, then. Thanks for your work on this.
 
It's trying to buy a box in hardcore and stops the script if it can't get one :(

Getting 1 chef-in-the-box in 3 seconds
Countdown: 3 seconds...
Countdown: 2 seconds...
Countdown: 1 second...
Waiting completed.
autoBuyPriceLimit => 6250.0
Verifying ingredients for chef-in-the-box (1)...
Verifying ingredients for nothing-in-the-box (1)...
You need 1 more box to continue.
autoBuyPriceLimit => 20000
Unable to get your chef for under 5000 meat!
 
You've told it to get a box and abort if it can't. It's aborting. Where's the bug?

Or do we want the get-a-box bits to only work properly outside ronin? Currently they run all the time... as per the abort. Another option... we could have a ronin price for the two as well, and then people who want to only have it happen when the mall is available can set that and unset the current entry.

Edit: The only change to this behaviour is that now when it fails, instead of silently disabling your preference to retrieve the chef, it aborts. In my backup of 3.1.7, you can see this... if retrieve_item chef in a box succeeds then use it, else turn GET_CHEF to false.
 
Last edited:
I've run into the problem where I run this script as part of turn-burning scripts like Harvest, and it occasionally decides to eat things like bags of QWOP and centipede eggs. Is there any way to make this script autocure bad effects with soft green whatevers or to avoid eating harmful foods?

(Otherwise, it's great!)
 
This script, no. You setting it, yes... you should already be running Bale's awesome Universal Recovery script, which will cure those for you. As well as giving you incredibly reduced rates at healing, if possible. Unless you have a great reason not to, it should be a part of your farming toolkit.
 
I guess I'm the only one who would prefer it to fail silently in hardcore since I don't have access to the mall?
 
If you've set it to require it and it fails and continues, that's not running as designed.

Options:
1) Additional 1-2 values (either skipBoxeninHC or getChefRonin/getBartenderRonin) to set this.
2) People set getChef/getBartender themselves in their kingLiberatedScript and postAscensionScript and get exactly the settings they want using what's already available to them without any script changes.
 
Can someone tell me how to get it to select the pastes for spleen usage? I have valueOfAdventure=500 and set the other options to spend more but it does not pick pastes
 
You need a VOA of about double that before 4-fill spleen items are profitable to use. So either set that, or deal with what 500 VOA gives you.
 
Back
Top