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

[Theraze]

The gCLI output would be a good start...

 

[redwulf25_ci]

Edit2: Using ED for the first time with full consumption in aftercore and yes... it does take freaking forever. Was around a minute trying to decide on food, and it's been waiting for drink for the time I've been writing this update. I think disabling accurateMake if get_ronin is false would be a worthwhile choice, since you're much more likely to buy than create. Does that work for everyone?

I prefer to create, as long as I can do it without using turns (having a *-in-a-box or inigos) as it can be cheaper.

 

[roippi]

Oh, didn't see that edit.

Edit2: Using ED for the first time with full consumption in aftercore and yes... it does take freaking forever. Was around a minute trying to decide on food, and it's been waiting for drink for the time I've been writing this update. I think disabling accurateMake if get_ronin is false would be a worthwhile choice, since you're much more likely to buy than create. Does that work for everyone?

Aha. My computer doesn't suck that much!

I think that's a good compromise. If you have mall access, you're not going to run out of ingredients, so accurateMake isn't really necessary. I mean, I guess you could buy out a cheaper store and bump it up into a higher-priced one, but that's so marginal it's not even worth talking about.

 

[Theraze]

It would still create, it just wouldn't be as accurate. Disabling ACCURATE_MAKE doesn't make creation stop, it means it won't be checking each item against available ingredients on every step...

 

[Banana Lord]

eatdrink has been over drinking, making me drunk. anyone else have this problem? just started yesterday, been using the script long time before that. Using it with the new harvest farming script if that matters.

Thanks if you can help!

I highly doubt that has anything to do with Harvest (on the other hand, if it did I'd very much want to know about it). When you run EatDrink (by typing a command or by selecting it from the Scripts menu, as opposed to ED being called automatically when you run Harvest) it will ask you to input information before it runs. It asks you how much you want to fill each organ, whether you want to overdrink (if you choose true for this it will overdrink, if you choose false it won't) and whether you want to the script to actually feed you on this run or just simulate what it would do (true for simulation, false for an actual run).

If you're giving ED the correct information and it's STILL not behaving as you expect it to then you should do as Theraze suggested and copy/paste the relevant gCLI output here.

 

[Theraze]

It will also overdrink if you fail to give it the right stopping point... that's why I said we'd need to see the gCLI output, since that says what its goal is, as well as what it ate to try to reach that.

 

[Satns_sphnctr]

I highly doubt that has anything to do with Harvest (on the other hand, if it did I'd very much want to know about it). When you run EatDrink (by typing a command or by selecting it from the Scripts menu, as opposed to ED being called automatically when you run Harvest) it will ask you to input information before it runs. It asks you how much you want to fill each organ, whether you want to overdrink (if you choose true for this it will overdrink, if you choose false it won't) and whether you want to the script to actually feed you on this run or just simulate what it would do (true for simulation, false for an actual run).

If you're giving ED the correct information and it's STILL not behaving as you expect it to then you should do as Theraze suggested and copy/paste the relevant gCLI output here.

Hi there, thanks for the responses guys. I will have to try them out, and post more details if I still have problems.

Just fyi, idk if it has anything to do with harvest, but I was using neocow farm for quite a while with no problems. The problem happened after I started using harvest, but maybe not right away.

Thanks again, I will try out some things and report back.

Edit: oh, I forgot to say. Mafia may be the problem too, because the mafia window says 19/19 drunkeness, but when I open the relay browser, I am falling down drunk. This happens before any adventuring takes place, so its definitely not from the tip over drink that you get at the end.

edit again: ah soryy forgot to ask, how do I output the gcli info? after so many actions, some of it disappears from the window.

 

[Theraze]

Yeah... most likely, you had lag while you were drinking and so ended drinking one too many of something. Very little we can do to fix it, though the version of EatDrink we're working on developing should alleviate some of those issues by planning how much it's going to drink outside of the actual consumption phase...

Edit: New version of EatDrink, though I don't think there's been any feedback on the last version... This one should have the (EAT_ACCURATE && get_ronin()) change, where accurateMake is only active while get_ronin is still true. Besides that, it has another more-different change... is_tradable only applies while npc_price == 0. This allows it to use mugcakes for newbie food instead of fortune cookies, saving 20 meat per eaten item. As well, if npc_price > 0, it will use the NPC price instead of doing historic/mall pricing. This should speed up checks for aftercore a bit as well. The thinking behind this is that while non-tradable items should still be protected, if you can buy an infinite amount, they should be considered as a 'standard' available item.

 

[Satns_sphnctr]

ok, well who know but I went back to neocowfarm and the problem (overdrink before spending any adventures to farm) went away.

Not really sure how to export a log, but since I am just farting around on my multi with this one, I dont mind trying to replicate the problem. However I am not so good at all this programming mumbo jumbo, so if someone could use small words and say how to export the log you want

 

[Theraze]

When I ask for the gCLI, I mean something like the examples from post 875. The {quote} tag helps make it easier to read too, though use [] instead of {} on that. Basically, switch to the gCLI tab after you run EatDrink and give us the summary... everything from "Now, to recap" to the end. The important part is the part like

drink: At 0, consuming to 19.

and then it says what it tried to drink to get there... if for some reason, it's trying to go higher than your max, or the specifics of what it consumed don't go up to 14/19, or...

But yeah, working without any actual data to debug? Very difficult.

 

[redwulf25_ci]

Is it possible for eatdrink to make intelligent use of distention/synthetic dog hair pills?

 

[Theraze]

You mean to use them if the cost is under that of VALUE_OF_ADVENTURE and skip otherwise, since unless their price is under 500 (or whatever you've set it to), it should skip them based on using them "intelligently"? Probably.

Edit: Since they're non-tradable, their 'standard' price is 999999999 meat each adventure... intelligently using those means... never?

 

[Winterbay]

Well, they are both untradable so I'm not sure how you would value them if you had them.

 

[Theraze]

EatDrink already has untradable handling... they all use the same value, which the player can set. If you set it to 500 meat, it would use them, but it would also use your priceless irreplacable items as well...

The exception to this rule is items that can currently (by you) be purchased from npc stores, since you can replace those easily and immediately.

 

[Winterbay]

Which would mean that in order to use the two types of pills intelligently you would need to add special code for them since they would otherwise either never get used or would make things you really don't want to get used automatically get used.

 

[Theraze]

Well, the question is, what would be considered 'intelligently' on those? It could be argued that the most intelligent use it to save them for special events, when you really need that extra point of appetite...

I mean, we could just have a zlib variable we save that means we're going to try to use those if we have them, and increase consumption total by 1 if so... but it could be argued that a good alias could handle that just as easily... I mean, this:

eatdrink ashq import <EatDrink.ash>; SIM_CONSUME=false; eatdrink(fullness_limit(), inebriety_limit(), spleen_limit(), false);

could go to this:

eatdrink ashq import <EatDrink.ash>; int flimit = fullness_limit(); int ilimit = inebriety_limit(); if (available_amount($item[distention pill]) > 0) {use(1, $item[distention pill]); flimit = flimit + 1;} if (available_amount($item[synthetic dog hair pill]) > 0) {use(1, $item[synthetic dog hair pill]); ilimit = ilimit + 1;} SIM_CONSUME=false; eatdrink(flimit, ilimit, spleen_limit(), false);

Not sure... it's possible that the SDHP might realize that inebriety is still 1 low and end up overdrinking, but at least with the DP, that should work 100%...

Bottom line is that I won't be using either for quite a while, if ever. So if you want something coded I'm not going to use, you'll have to give me step by step what you want... always using your stock, only using it if your preference is set, only using it above level 5, what?

 

[roippi]

There's unfortunately an outstanding bug with distention pills where if you eat a distention pill and queue up multiple food items to take you to fullness_limit + 1 (which is just fullness_limit after the pill takes 1 full off the first item), the limiter will kick in and not let you eat the last item. It's kinda low on my priority list but I plan on taking a look at it eventually.

 

[Theraze]

Yes/no. The way EatDrink works, it eats one at a time... so it wouldn't have that bug.

 

[roippi]

Right. Yeah, that would be fine then.

 

[Theraze]

Yeah... the possible bug/problem is if you use TPS drinks or KLP food, since those make it recalculate part way through the consumption. Based on updated information... which includes having already taken your DP or SHDP into account, so it will try to over eat/drink. Being said, it should only apply when mixing KLP or TPS and the helpers.

For that matter, would probably eventually make sense to include other helpers into account for EatDrink...

Edit: Would we want to just have a consideration of helpers? I wouldn't be coding them for a while... until after the rest of the stacking EatDrink is stable and working in a logical sort of way, but I'd add them after that.

For non-tradable helpers, should we use twice their autosell price as their 'value', which would make DP and SHDP have a value of 500, and be used by default if it can actually gain adventures at the standard cost? By that, if you had a VoA at or above 520, it would use the DP expecting to eat a mugcake, if nothing else. If you have real food you can eat, it should find something that will make your 16 appetite turn out better than 15...

Edit2: Meh, the other helpers are all significantly more expensive and generally don't have autosell, so guess that knocks out adding anything else. Probably end up using something similar to the mojo filtering code for them... maybe reuse that variable to work on all 3 types using the 2*autosell thing.

Edit3: Meh again. Mojo filter doesn't actually have a variable, it's just considered for price since it's a standard item. So... what exactly do we want to use as our pill price?

Edit4: Well, no update for pill price, so... that's a maybe someday thing. Here's something I've added to my working copy of EatDrink as of 9599...

int get_quality(item checking)
{
  int level = -1;
  switch (checking.quality)
  {
    case "crappy":
      level = 0;
      break;
    case "decent":
      level = 1;
      break;
    case "good":
      level = 2;
      break;
    case "awesome":
      level = 3;
      break;
    case "epic":
      level = 4;
      break;
  }
  return level;
}

Planning on allowing a minimum quality value similar to the minimum average, so you can set to filter out all items that aren't at least the desired quality or higher... probably call it minimum_quality and it should be in the next upload.