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

Basically, decide what level is profitable and set your VOA there. Don't be surprised when ED buys items based on what you tell it you want.
 
Code:
Considering food from inventory closet Hagnk's Coinmasters NPCs the mall. Per-item budget cap is 250000.0.
Retrieval cap is 20000. Price will be a factor if you own it already.
An adventure has the value of 4000 meat. Muscle subpoint is 0.0. Nonprime stat subpoint is 0.0.
At drunkenness of 19. Overdrinking with 50000 meat.

However, valueofadv is set to 1000. In going through various logs, I've noticed that eatdrink's quoted adventure value virtually never matches the valueofadv setting. Looks at vars_charname I don't see anything listed under eatdrink that would seem to affect this. Do the overal, step, and per item limits affect it?
 
Deathless_Assassin_prefs in the settings folder, not vars_Deathless_Assassin in the data folder. It's a mafia preference, not a zlib var.
 
Hi, for a couple of days now, EatDrink has been using an unnecessary amount of milk of magnesia (i think one for each food item).
Is that a known issue? I always use the latest daily build of mafia.

Today's log: http://pastebin.com/mpXvggpm

Greetings,
Kaffeetrinken
 
Last edited:
Nope. Any chance you were updating your mafia files while they were running? That's the only time where I personally get that sort of "mafia loses track of which effects are active and anything trying to be accurate goes a bit nuts" behaviour without a bunch of other people reporting issues as well.
 
Perhaps it's trying to use too much milk, but mafia won't let it use the extra milk anyway, so it's harmless. That doesn't mean that there isn't something to fix in the script, but your resources aren't being wasted there.
 
Nope. Any chance you were updating your mafia files while they were running? That's the only time where I personally get that sort of "mafia loses track of which effects are active and anything trying to be accurate goes a bit nuts" behaviour without a bunch of other people reporting issues as well.
My mafia folder is inside my dropbox folder. Perhaps that somehow interferes with mafia accessing its files correctly.
Tomorrow i'll try running mafia outside the dropbox.
Thanks for the hint!
 
Last edited:
Perhaps it's trying to use too much milk, but mafia won't let it use the extra milk anyway, so it's harmless. That doesn't mean that there isn't something to fix in the script, but your resources aren't being wasted there.
Actually, i had 100 turns of milk left after EatDrink finished, so it is definitely wasting it.
 
Perhaps it's trying to use too much milk, but mafia won't let it use the extra milk anyway, so it's harmless. That doesn't mean that there isn't something to fix in the script, but your resources aren't being wasted there.

Actually, i had 100 turns of milk left after EatDrink finished, so it is definitely wasting it.

This supports my theory that your mafia files are getting out of sync and providing a 'broken' execution. As soon as you notice anything odd, best thing to do is fully quit mafia and relaunch.

I do run mafia inside a Dropboxed folder, but I generally use the command prompt to control updating mafia so I know (or should) that the file is the version that I'm running at this instant.
 
Okay, so today EatDrink ran normally. What I did different from yesterday:
1. Moved KolMafia outside my Dropbox folder.
2. Removed all but the latest KolMafia-XXXXX.jar from my folder.
3. No interaction with the relay browser during the execution of EatDrink.
In the next few days I'll keep on trying to figure out what the actual cause for the weird behaviour is/was.
Also, as this does not appear to be an EatDrink issue, I probably should stop posting here. :)
Thanks for your help!
 
I have been keeping my mafia run directory in Dropbox for quite some time with no issues. I do, however, wait until Dropbox has finished synching before I run.
 
3. No interaction with the relay browser during the execution of EatDrink.

Of the things you have listed that is what I "trust" the least. Sometimes mafia multi-tasks well, sometimes it doesn't but at least blocks, but some times it will try and do things that I'd rather it didn't.
 
Let's talk about the get boxen logic. I just started a HC run. My boxen prices are non-zero. EatDrink aborts because it cannot get boxen. EatDrink also knows "You are in ronin so no shopping for you". I sense an inconsistency here and that is because I would like ED to ignore the boxen prices if it is in ronin. I would like it to ignore the prices so I don't have to edit my preferences every time I break the prism and then again every time I start a new run. Thoughts?
 
Currently there is no hardcore exception on the chef logic. The helps internally never mentioned that it was SC/out-of-ronin, so it isn't. By that reasoning, the postPrismScript could set the variable for you, and the postAscension script could clear it again. No editing the preferences each time, just easy scripted goodness.
 
But I'd have to create and use a postPrisim script and I'd have to edit NewLife, put a wrapper around it or convince Bale this was a worthy thing ;-)

Writing and using scripts doesn't bother me but having a script fail because it doesn't have Mall access and knows darn well it doesn't have access offends my sense of good implementation.
 
If you farm the items yourself, it can still be worthwhile to have it construct them... I enjoy when the script builds me a RnRL in-run. Saves a bunch of meat for 1 adventure. :)

We could make it only apply when you're non-Ronin, but if we did that, probably best to add a new preference... hardcoreBoxen maybe, defaulting to true (current behaviour). If you set it to false, it skips the boxen check entirely if you're in Ronin. Why hardcoreBoxen and not roninBoxen? Because it's less bizarre for me mentally to imagine boxes at a heavy metal show rather than as disenfranchised ninjas. :)
 
I say boxen because it echos back to the days when all the cool companies used Digital Equipment Corporation mini-computers and the cutting edge ones had a DEC Vax. My preferred solution to the plural of Vax was Vaxen which I especially loved because it confused co-workers.

To save me from reading back in the thread, what exactly do the preferences mean? I was thinking if the number was positive, the script was supposed to build boxen when needed, spending up to, but no more than the preference number to do so. If boxen cannot be made under that constraint then abort. Zero means don't make boxen.

If indeed, that is correct, then I have a Feature Request and not a Bug Report because I would like ED to not abort if it can't make boxen because Mall access is somehow prevented. If my FR requires another preference then I may be inclined to withdraw it unless and until we have a relay script with annotation for setting ED preferences :-)
 
Back
Top