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

Theraze said:
the "official maintainer has vetoed any changes involving script not doing what you ask it to" excuse.
Click to expand...

I am both cranky and inconsistent. Sometimes both at once. While I have thrown my weight around, at this moment I consider you the most knowledgeable maintainer of EatDrink and if the only reason for not doing something is me then perhaps we should revisit the feature. Of course, since there are alternative ways to achieve the same effect, EatDrink might not be the best place but...
 
Well, xKiv pointed out a good specific case for why you'd want to drink to a specified inebriety level regardless of max. As such, it seemed we had our "this is why we aren't changing it" reason and discussion ended. :)

I could probably be dissuaded into changing either one, but... if we reopen the steel organ question, I'd have a bunch more thinking around it I'd want to do before implementing it. Because of the issues around it, I'd be curious whether we actually want "intelligent" cookie eating at potentially 3* as long for total food consumption as now, or just rushing through with a single cookie thrown in. As well, with "intelligent" eating where it looks at counters, it needs to do that before it calculates future eating, so any crafting required will be happening AFTER you drink milk for the cookie and be burning down turns. Not bad for saucerors with sauciness, sucks for anyone else.

The best option is probably to tell people who care to use ED to get to 13 fullness, eat their cookie or cookies, and then use either ED or a mugcake to finish up that last fullness if they only needed one.
 
Theraze said:
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.
Click to expand...

Actually, you are wrong. It is quite possible to detect the number of counters. The character between the two counters is a tab, not a space, so you would detect the number like this:

Code: 
> counters

Last semirare found 30 turns ago (on turn 431) in Giant's Castle

Unexpired counters:
Semirare window begin (130)
Semirare window end (170)

> ash count( split_string( get_counters("Semirare window", 0, 200), "\t" ) )

Returned: 2
 
You missed a key phrase there... when we're lazy... :)

I popped open CC and saw it was possible to detect. I also lazily closed it back up again and decided to ignore due to the milk-wasting problems. :)
 
Sorry about that. I just didn't like you presenting bad code as a reason not to do something. Next time, leave out the code so that I won't trouble you by fixing it.
 
Heh. Sounds good. I was mid-lazy... ran a quick test, found it dumped the whole string, pasted that. Talked through it, including saying that I know that the "problem" has already been solved and isn't a real issue, in that post (last paragraph). It was the later posts where we came up with other good reasons to avoid implementing. :D
 
My 2c. If someone wants to limit food intake for future fortune cookie consumption, he should explicitly limit foodMax. However, this is still a good feature to allow a variable that says to always eat a fortune cookie if there isn't a current Fortune Cookie counter. Would it be hard to always add a fortune cookie to the food queue if(vars["eatdrink_eatCookie"].to_boolean() && get_counters("Fortune Cookie", 0, 200) == "")?

That would solve the one problem that a user cannot control by simply modifying EatDrink's parameters.
 
If we only care to eat a single cookie if the variable is set, and we don't care about the results (whether they make sense or if they've been spending the last 200 adventures training familiars, etc), it's relatively easy... we use special_values to set its value to MAX_MEAT, though we additionally need to realize if we're already eating one so we don't end up using 15 fortune cookies... easiest fix would be the suggestion I made above where we just recalculate after the first cookie, but that means you don't get efficient milk usage. Which sucks. Second best would be adding (or overloading) special_value to know if we're doing a speculative check, so we can know which food stack to check through. Don't want to skip fortune cookies on speculative considerations and end up skipping it entirely because we can get better results with 15 fullness and a 90% VoA than 14 fullness and 100% VoA...

If we (which means, convince fronobulax. ;)) actually want this, it could be done in a basic, non-intelligent way in ~10 minutes. I think.
 
Well I want that feature. If it doesn't make sense to eat a cookie because the user spends all his turns training familiars then he simply shouldn't instruct the script to eat a cookie. Honestly, since it only eats a cookie when vars["eatdrink_eatCookie"] is true and default is false, then he ought to know what he's doing with his own custom settings.

To get efficient milk usage I'd recommend setting the cookie's value to 20,000 meat since that's more or less the value of a semi-rare and it isn't worth the trouble to check mall prices for all semi-rares. Then when about to start choosing food to eat, have a cookie forced, regardless of value if(vars["eatdrink_eatCookie"].to_boolean() && get_counters("Fortune Cookie", 0, 200) == "" && !cookieaten). Then you set cookieaten = true; That's just to make sure you don't eat a cookie twice.
 
Looking over the code it occurs to me that a potential problem is that update_from_mafia() won't add a fortune cookie to basegrub since get_quality(it) < MINIMUM_QUALITY.
 
Yeah... that planning REALLY doesn't work with the way that EatDrink queues food and plans it. :) The food doesn't get consumed until we've fully planned everything... though we could possibly do that by hacking food to consume to requestedfullness-1 and throwing the cookie at the end of the pile instead.

But you're right... the mafia update would need to be hacked to include cookies if they're below minimum quality or average, and drop them after consumption if we included them. Since we don't want someone to end up with 15 cookies if they don't have any other choices at level 1 or 2 and they're waiting, but they wanted it to check. Which is a bit difficult, but should be doable. Probably. Expect to see at least 2-3 screwed up early ascensions though while the kinks get worked out.

If I end up with the fullness hack though, I don't really have to worry about that too much... or... yeah, I do, it still needs to have the fortune cookie loaded into a consumption record so it can use the normal eating functions, else it's all manual-hack. Meh.
 
I'm not really paying as much attention as I should but it seems to me that the core issue is whether ED is forced to eat a fortune cookie or not. If it is not forced then nothing changes. If it is forced then there should probably be a check to determine whether it makes sense to eat one based upon the counters and if it doesn't make sense then don't eat one. Otherwise (if forced and makes sense) I think the fortune cookie should just be unconditionally consumed. I don't see why it needs to be on a speculative stack because the user is really saying "eat the darn cookie, already".

If I were going to implement this I would either just consume the cookie and then do what ED normally does using the user's specified fullness (and knowing one fullness has been consumed) or I would do normal ED using one less than what the user asked for and then eat the cookie at the end. The point being, however, that ED would do the same thing whether I eat a FC manually and call it afterwards or call ED with one less and then eat FC.
 
If it's just going to eat the cookie and skip milk, then why put it into the script at all? If we're going to care about milk, it needs to be in EVERY stack, speculative and not, because that's the way that consumption works.

And no, it doesn't work the same way... calling ED, on fullness only, to 14, will try to leave you with 1 (or 9) adventures of milk remaining. This means that consuming your fortune cookie will get 2 adventures.

Eating a fortune cookie first, then calling ED for the remaining 14 fullness, will either give you 1 adventure (no manual milk first) or leave you with 9/14 adventures of milk remaining, which will be consumed as ED creates food for you. With only basic ingredients, ED would happily make you 3 painful penne pastas... though you'd be consuming them with 6/11 adventures of milk remaining, so you'll need another milk to fill up. If you're a non-sauceror without intrinsic sauciness, or you're a sauceror with intrinsic sauciness (where in either case, you'll end up with 20 total milk-points), you probably won't care too much. Anyone else... it's going to be a wasted milk.

The 'best' current solution is to use ED to consume to 14 fullness and 0 inebriety/spleen, eat your fortune cookie, then fill up the inebriety/spleen. But that isn't easy.
 
You're right about the milk, of course, but it is not something that makes a real difference to me, so I glossed over it.

But this does suggest that the feature request/debate is about fortune cookies and milk management and not just the cookies. I'd be curious to know if the folks who who care about one more adventure and the possible waste of turns of milk actually trust ED enough to let it automate the process?
 
Does for me... but then, my mQ is set to 1, and mA is set to 1.0. :) If you've changed your minimumQuality above what you want it to be, that's on you...

And for the record, the script sets mA to 1, and mQ to 0 by default. So it only skips completely useless items. Items like the Bucket of Wine would be considered if you didn't, by raising mQ, tell ED that you wanted it ignored.

tldr;
Don't blame script for settings you changed. :)
 
I was looking through here, and wondering how i could set up a pair of aliases for Eatdrink: one to eat to 13 fullness, max drunk & max spleen, and another to eat to 14 fullness, max drunk & max spleen (to save room for fortune cookies).
 
Made them dynamic so they work properly for Boris runs and the like.
alias eatdrinkm2 => ashq import <EatDrink.ash>; SIM_CONSUME=false; eatdrink((fullness_limit() - 2), inebriety_limit(), spleen_limit(), false);
alias eatdrinkm1 => ashq import <EatDrink.ash>; SIM_CONSUME=false; eatdrink((fullness_limit() - 1), inebriety_limit(), spleen_limit(), false);
Click to expand...
 
You must log in or register to reply here.
Back
Top